https://wiki.archlinux.org/api.php?action=feedcontributions&user=RaZorr&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:38:05ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:PRIME&diff=803654Talk:PRIME2024-03-16T17:36:00Z<p>RaZorr: /* Configure applications to render using GPU */ new section</p>
<hr />
<div>== PRIME GPU OFFLOADING ==<br />
<br />
The section "PRIME GPU OFFLOADING" is in my opinion a collection of solutions outdating each other. I came from bumblebee and optirun, that stopped working with nvidia 440.31 and tried my luck using the approach here. Following the linked hints in the Notes of this section were already outdated and I found help in the readme of the current nvidia driver version: https://download.nvidia.com/XFree86/Linux-x86_64/440.31/README/primerenderoffload.html<br />
<br />
How about either linking to that article or putting a snippet of working xorg-config plus which pkgs to use in that section?<br />
<br />
{{Unsigned|09:25, 26 November 2019 (UTC)|Bollie}}<br />
<br />
The ''--provideroffloadsink'' option is still accurate for Mesa drivers. Not sure about the proprietary driver, but feel free to add more informations with links to the sources. [[User:Lekensteyn|Lekensteyn]] ([[User talk:Lekensteyn|talk]]) 23:08, 1 December 2019 (UTC)<br />
<br />
=== PRIME render offload ===<br />
<br />
It's true that editing files under {{ic|/usr/share/}} will not survive package upgrades, but I didn't find any means to make it work that doesn't involve editing the file {{ic|usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf}} to remove the {{ic|PrimaryGPU}} option. Either I could come up with a pacman hook (hacky as hell) or make a warning about it in the wiki. Right now it seems that depends on configuration alone and forcing that default configuration from the package doesn't seem sane. A minimum correct ''10-nvidia-drm-outputclass.conf'' file should look like this:<br />
{{hc|usr/share/X11/xorg.conf.d/10-nvidia-drm-outputclass.conf|<br />
Section "OutputClass"<br />
Identifier "nvidia"<br />
MatchDriver "nvidia-drm"<br />
Driver "nvidia"<br />
ModulePath "/usr/lib/nvidia/xorg"<br />
ModulePath "/usr/lib/xorg/modules"<br />
EndSection<br />
}}<br />
[[User:Samsagax|Samsagax]] ([[User talk:Samsagax|talk]]) 19:45, 9 December 2019 (UTC)<br />
<br />
:Either a xorg.conf file or a /etc/X11/xorg.conf.d snippet have precedence over /usr/share/X11/xorg.conf.d. Please remove that section from the prime render offload, it's not necessary. I'll make some changes later this week too, and I might remove that. {{unsigned|17:22, 10 December 2019|Grazzolini}}<br />
<br />
<br />
::I have created a package for this setup called {{Pkg|nvidia-prime}}. It comes with a script and a xorg.conf.d snippet. During my tests, I have found out that using it and without commenting the PrimaryGPU option on the 10-nvidia-drm-outputclass.conf, I got a reverse prime setup by default, without any /etc/X11/xorg.conf or /etc/X11/xorg.conf.d snippet, which means that, because of the PrimaryGPU option, X would use the NVIDIA card for everything. If I comment out that option, I get the prime render offload setup. I'm going to discuss this with the {{Pkg|nvidia-utils}} maintainer and see if we can either remove that snippet entirely, or at least remove the PrimaryGPU option. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 00:08, 11 December 2019 (UTC)<br />
<br />
:::I think removing the option and every other that doesn't add or impose a setting to the user is the way to go. As general rule, there should only be a sane default that won't interfere with user coniguration or at least back it up. About the precedence, if what you say it's true, then adding a snippet under {{ic|/etc/X11/xorg.conf.d}} with the option {{ic|PrimaryGPU}} set to "no" should do the trick something like:<br />
{{hc|etc/X11/xorg.conf.d/10-nvidia-drm-outputclass-primary-no.conf|<br />
Section "OutputClass"<br />
Identifier "nvidia"<br />
Option "PrimaryGPU" "no"<br />
EndSection<br />
}}<br />
:::I'll try to test this tonight. Aside from this, I think the whole section about PRIME offload should be rewritten. I can help with that and my findings on setting up NVIDIA proprietary driver specifically. [[User:Samsagax|Samsagax]] ([[User talk:Samsagax|talk]]) 17:01, 11 December 2019 (UTC)<br />
<br />
:::: Yes, setting it up on /etc/X11/xorg.conf or /etc/X11/xorg.conf.d should have precedence over /usr/share/X11/xorg.conf.d. I have opened {{Bug|64805}} for tracking this and I'm talking with the current maintainers, [[User:svenstaro|svenstaro]] and [[User:felixonmars|felixonmars]]. In addition to dropping the PrimaryGPU option, we should also drop the modesetting configuration for the intel card from that file also, because it means that even if you have {{Pkg|xf86-video-intel}} installed, it won't be used unless you force it with a xorg.conf or xorg.conf.d snippet. Basically it's interfering with normal Xorg autodetection. It also makes Xorg.wrap to fail and start X as root by default. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 20:08, 11 December 2019 (UTC)<br />
<br />
::::: I just tested my theory and adding the snippet above didn't help as long as {{ic|PrimaryGPU}} is set on the file under {{ic|/usr/share/X11/xorg.conf.d}} so removing it or commenting it out is the way to go. {{unsigned|22:43, 11 December 2019|Samsagax}}<br />
<br />
<br />
:::::: I have tested this as well, by copying the 10-nvidia-drm-outputclass.conf from /usr/share/X11/xorg.conf.d to /etc/X11/xorg.conf.d and both removing the PrimaryGPU option and setting it to "no" as well. Neither worked. The only solution is for that file to drop the PrimaryGPU option, indeed. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 02:31, 13 December 2019 (UTC)<br />
<br />
Hi, new here, proposing an edit to: "As per the official documentation, it only works with the modesetting driver over Intel graphics card." I have a working setup with an Intel HD Graphics 620 using the Intel driver and Nvidia Geforce 940MX using the Nvidia driver (in an ASUS S510UQ laptop); I've confirmed this with xrandr --listproviders. Perhaps change to "...it only works with the modesetting driver, but success has been had with the Intel driver instead..."? [[User:Irradium|Irradium]] ([[User talk:Irradium|talk]]) 01:20, 12 January 2020 (UTC)<br />
<br />
: Edited as appropriate to previous statement. [[User:Irradium|Irradium]] ([[User talk:Irradium|talk]]) 22:10, 14 January 2020 (UTC)<br />
<br />
== Official PRIME solution ==<br />
<br />
I have found the solution [http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/dynamicpowermanagement.html here] to work pretty well when applied, and {{AUR|optimus-manager}} with default config and hybrid mode fixes the lack of a video output in configs that exhibit it.<br />
<br />
I wonder if the wiki page could be updated to reflect that? --[[User:TheSola10|TheSola10]] ([[User talk:TheSola10|talk]]) 12:01, 18 December 2019 (UTC)<br />
<br />
: The documentation states that: This feature requires a Turing or newer GPU. It can't really be used for all cards. You are welcome to edit the page to add info about this dynamic power management, but there's nothing "Official" about using optimusmanager. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 12:23, 18 December 2019 (UTC)<br />
<br />
== Prime and Wayland ==<br />
<br />
I might be mistaken, but I believe that Reverse Prime is not possible with the current (470.57.02-1) driver.<br />
<br />
I think that it would be nice to clarify the situation regarding Prime and Wayland globally<br />
<br />
[[User:Pums974|Pums974]] ([[User talk:Pums974|talk]]) 10:04, 21 July 2021 (UTC)<br />
<br />
== Configure applications to render using GPU ==<br />
<br />
This section has examples to run an application offloaded to the NVIDIA GPU with Dynamic Power Management enabled using the environment variables {{ic|__NV_PRIME_RENDER_OFFLOAD{{=}}1 __GLX_VENDOR_LIBRARY_NAME{{=}}nvidia}}. {{ic|prime-run}} can also be used for this purpose and is a convenient wrapper around the provided command (can be verified by running {{ic|cat $(which prime-run)}}). So, that command can also be mentioned as can be seen in the section [[External GPU#Xorg rendered on iGPU, PRIME render offload to eGPU]], where both commands are mentioned [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 17:36, 16 March 2024 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=AMDGPU&diff=740084AMDGPU2022-08-05T03:34:40Z<p>RaZorr: Make graphics card's driver/module checking command uniform in wiki (amdgpu)</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[de:AMDGPU]]<br />
[[ja:AMDGPU]]<br />
[[zh-hans:AMDGPU]]<br />
{{Related articles start}}<br />
{{Related|ATI}}<br />
{{Related|Xorg}}<br />
{{Related|Vulkan}}<br />
{{Related|AMDGPU PRO}}<br />
{{Related articles end}}<br />
<br />
[[Wikipedia:AMDGPU|AMDGPU]] is the open source graphics driver for AMD Radeon graphics cards from the [[wikipedia:Graphics_Core_Next|Graphics Core Next]] family.<br />
<br />
== Selecting the right driver ==<br />
<br />
Depending on the card you have, find the right driver in [[Xorg#AMD]].<br />
At the moment there is Xorg [[radeon]] driver support for [https://www.x.org/wiki/RadeonFeature/ Southern Islands (SI)] through Arctic Islands (AI) cards. AMD has no plans to support pre-GCN GPUs.<br />
Owners of unsupported GPUs may use the open source [[radeon]] driver.<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]] repostory.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), install the {{Pkg|xf86-video-amdgpu}} package.<br />
* For [[Vulkan]] support, install the {{Pkg|vulkan-radeon}} or {{Pkg|amdvlk}} package. Optionally install the {{Pkg|lib32-vulkan-radeon}} or {{Pkg|lib32-amdvlk}} package for 32-bit application support. Prefer {{Pkg|vulkan-radeon}} for running DirectX12 games through wine/proton, as {{Pkg|amdvlk}} is broken for that purpose.<br />
<br />
Support for [[#Video acceleration|accelerated video decoding]] is provided by {{Pkg|libva-mesa-driver}} and {{Pkg|lib32-libva-mesa-driver}} for VA-API and {{Pkg|mesa-vdpau}} and {{Pkg|lib32-mesa-vdpau}} packages for VDPAU.<br />
<br />
=== Experimental ===<br />
<br />
It may be worthwhile for some users to use the upstream experimental build of mesa, to enable features such as AMD Navi improvements that have not landed in the standard mesa packages.<br />
<br />
Install the {{AUR|mesa-git}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{AUR|lib32-mesa-git}} package from the ''mesa-git'' repository or the [[AUR]].<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), install the {{AUR|xf86-video-amdgpu-git}} package.<br />
* For [[Vulkan]] support using the ''mesa-git'' repository below, install the ''vulkan-radeon-git'' package. Optionally install the ''lib32-vulkan-radeon-git'' package for 32-bit application support. This should not be required if building {{AUR|mesa-git}} from the AUR.<br />
<br />
{{Note|It may be necessary to symlink LibLLVM for X to start. For example, {{ic|ln -s /usr/lib/libLLVM-10git.so /usr/lib/libLLVM-10svn.so}}}}<br />
<br />
{{Tip|Users who do not wish to go through the process of compiling the {{AUR|mesa-git}} package can use the [[Unofficial user repositories#mesa-git|mesa-git]] unofficial repository.}}<br />
<br />
=== Enable Southern Islands (SI) and Sea Islands (CIK) support ===<br />
<br />
The {{Pkg|linux}} package enables AMDGPU support for cards of the Southern Islands (HD 7000 Series, SI, ie. GCN 1) and Sea Islands (HD 8000 Series, CIK, ie. GCN 2). The {{ic|amdgpu}} kernel driver needs to be loaded before the [[radeon]]. You can check which kernel driver is loaded by running {{ic|lspci -k}}. It should be like this:<br />
<br />
{{hc|$ lspci -k {{!}} grep -A 4 -E "(VGA{{!}}3D)"|<br />
...<br />
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]<br />
Subsystem: Gigabyte Technology Co., Ltd Device 226c<br />
Kernel driver in use: amdgpu<br />
Kernel modules: radeon, amdgpu<br />
...<br />
}}<br />
<br />
If the {{ic|amdgpu}} driver is not in use, follow instructions in the next section.<br />
<br />
==== Load amdgpu driver ====<br />
<br />
The [[module parameters]] of both {{ic|amdgpu}} and {{ic|radeon}} modules are {{ic|1=cik_support=}} and {{ic|1=si_support=}}. <br />
<br />
They need to be set as kernel parameters or in a ''modprobe'' configuration file, and depend on the cards GCN version.<br />
<br />
You can use both parameters if you are unsure which kernel card you have.<br />
<br />
{{Tip|[[dmesg]] may indicate the correct kernel parameter to use: {{ic|1=[..] amdgpu 0000:01:00.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override}}.}}<br />
<br />
===== Set module parameters in kernel command line =====<br />
<br />
Set one of the following [[kernel parameters]]:<br />
<br />
* Southern Islands (SI): {{ic|1=radeon.si_support=0 amdgpu.si_support=1}}<br />
* Sea Islands (CIK): {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1}}<br />
<br />
==== Specify the correct module order ====<br />
<br />
Make sure {{ic|amdgpu}} has been set as first module in the [[Mkinitcpio#MODULES]] array, e.g. {{ic|1=MODULES=(amdgpu radeon)}}.<br />
<br />
===== Set module parameters in modprobe.d =====<br />
<br />
Create the configuration [[modprobe]] files in {{ic|/etc/modprobe.d/}}, see {{man|5|modprobe.d}} for syntax details.<br />
<br />
For Southern Islands (SI) use option {{ic|1=si_support=1}}, for Sea Islands (CIK) use option {{ic|1=cik_support=1}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/amdgpu.conf|2=<br />
options amdgpu si_support=1<br />
options amdgpu cik_support=1<br />
}}<br />
<br />
{{hc|/etc/modprobe.d/radeon.conf|2=<br />
options radeon si_support=0<br />
options radeon cik_support=0<br />
}}<br />
<br />
Make sure {{ic|modconf}} is in the the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} and [[regenerate the initramfs]].<br />
<br />
===== Compile kernel which supports amdgpu driver =====<br />
When building or compiling a [[kernel]], {{ic|1=CONFIG_DRM_AMDGPU_SI=Y}} and/or {{ic|1=CONFIG_DRM_AMDGPU_CIK=Y}} should be set in the config.<br />
<br />
==== Disable loading radeon completely at boot ====<br />
<br />
The kernel may still probe and load the {{ic|radeon}} module depending on the specific graphics chip involved, but the module is unnecessary to have loaded after confirming {{ic|amdgpu}} works as expected. Reboot between each step to confirm it works before moving to the next step:<br />
<br />
# Use the module parameters on the kernel commandline method to ensure {{ic|amdgpu}} works as expected<br />
# Use the {{ic|1=MODULES=(amdgpu)}} mkinitcpio method but do '''not''' add {{ic|radeon}} to the configuration<br />
# Test that {{ic|1=modprobe -r radeon}} will remove the kernel module cleanly after logged into the desktop<br />
# Blacklist the {{ic|radeon}} module from being probed by the kernel during second stage boot:<br />
<br />
{{hc|/etc/modprobe.d/radeon.conf|2=<br />
blacklist radeon<br />
}}<br />
<br />
The output of {{ic|lsmod}} and {{ic|dmesg}} should now only show the amdgpu driver loading, radeon should not be present. The directory {{ic|1=/sys/modules/radeon}} should not exist.<br />
<br />
=== ACO compiler ===<br />
<br />
The [https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 ACO compiler] is an open source shader compiler created and developed by [[wikipedia:Valve_Corporation|Valve Corporation]] to directly compete with the [https://llvm.org/ LLVM compiler], the [https://github.com/GPUOpen-Drivers/AMDVLK AMDVLK drivers], as well as [[wikipedia:Windows_10|Windows 10]]. It offers lesser compilation time and also performs better while gaming than LLVM and AMDVLK.<br />
<br />
Some benchmarks can be seen in [https://itsfoss.com/linux-games-performance-boost-amd-gpu/ It's FOSS] and Phoronix [https://www.phoronix.com/scan.php?page=article&item=radv-aco-llvm&num=1 (1)] [https://www.phoronix.com/scan.php?page=article&item=radv-aco-gcn10&num=1 (2)] [https://www.phoronix.com/scan.php?page=article&item=mesa20radv-aco-amdvlk&num=1 (3)].<br />
<br />
Since {{Pkg|mesa}} version 20.2, the ACO compiler is enabled by default.<br />
<br />
== Loading ==<br />
<br />
The {{ic|amdgpu}} kernel module is supposed to load automatically on system boot.<br />
<br />
If it does not:<br />
<br />
* Make sure to [[#Enable Southern Islands (SI) and Sea Islands (CIK) support]] when needed.<br />
* Make sure you have the latest {{Pkg|linux-firmware}} package installed. This driver requires the latest firmware for each model to successfully boot.<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since {{ic|amdgpu}} requires [[KMS]].<br />
* Check that you have not disabled {{ic|amdgpu}} by using any [[Kernel_modules#Blacklisting|kernel module blacklisting]].<br />
<br />
It is possible it loads, but late, after the X server requires it. In this case:<br />
<br />
* See [[Kernel mode setting#Early KMS start]].<br />
<br />
== Xorg configuration ==<br />
<br />
[[Xorg]] will automatically load the driver and it will use your monitor's EDID to set the native resolution. Configuration is only required for tuning the driver.<br />
<br />
If you want manual configuration, create {{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}}, and add the following:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
EndSection<br />
}}<br />
<br />
Using this section, you can enable features and tweak the driver settings, see {{man|4|amdgpu}} first before setting driver options.<br />
<br />
=== Tear free rendering ===<br />
<br />
''TearFree'' controls tearing prevention using the hardware page flipping mechanism. If this option is set, the default value of the property is 'on' or 'off' accordingly. If this option is not set, the default value of the property is auto, which means that TearFree is on for rotated outputs, outputs with RandR transforms applied and for RandR 1.4 slave outputs, otherwise off:<br />
<br />
Option "TearFree" "true"<br />
<br />
You can also enable TearFree temporarily with [[xrandr]]: <br />
<br />
$ xrandr --output ''output'' --set TearFree on<br />
<br />
Where {{ic|''output''}} should look like {{ic|DisplayPort-0}} or {{ic|HDMI-A-0}} and can be acquired by running {{ic|xrandr -q}}.<br />
<br />
=== DRI level ===<br />
<br />
''DRI'' sets the maximum level of DRI to enable. Valid values are ''2'' for DRI2 or ''3'' for DRI3. The default is ''3'' for DRI3 if the [[Xorg]] version is >= 1.18.3, otherwise DRI2 is used:<br />
<br />
Option "DRI" "3"<br />
<br />
=== Variable refresh rate ===<br />
<br />
See [[Variable refresh rate]].<br />
<br />
=== 10-bit color ===<br />
<br />
{{Warning|Many applications may have graphical artifacts or crash when 10-bit color is enabled. This notably includes [[Steam/Troubleshooting#Steam:_An_X_Error_occurred|Steam]], which crashes with an X Error.}}<br />
<br />
Newer AMD cards support 10bpc color, but the default is 24-bit color and 30-bit color must be explicitly enabled. Enabling it can reduce visible banding/artifacts in gradients, if the applications support this too. To check if your monitor supports it search for "EDID" in your [[Xorg#General|Xorg log file]] (e.g. {{ic|/var/log/Xorg.0.log}} or {{ic|~/.local/share/xorg/Xorg.0.log}}):<br />
<br />
[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-0<br />
[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-1<br />
[ 336.695] (II) AMDGPU(0): Manufacturer: DEL Model: a0ec Serial#: 123456789<br />
[ 336.695] (II) AMDGPU(0): Year: 2018 Week: 23<br />
[ 336.695] (II) AMDGPU(0): EDID Version: 1.4<br />
[ 336.695] (II) AMDGPU(0): Digital Display Input<br />
'''[ 336.695] (II) AMDGPU(0): 10 bits per channel'''<br />
<br />
To check whether it is currently enabled search for "Depth"):<br />
<br />
[ 336.618] (**) AMDGPU(0): Depth 30, (--) framebuffer bpp 32<br />
[ 336.618] (II) AMDGPU(0): Pixel depth = 30 bits stored in 4 bytes (32 bpp pixmaps)<br />
<br />
With the default configuration it will instead say the depth is 24, with 24 bits stored in 4 bytes.<br />
<br />
To check whether 10-bit works, exit Xorg if you have it running and run {{ic|Xorg -retro}} which will display a black and white grid, then press {{ic|Ctrl-Alt-F1}} and {{ic|Ctrl-C}} to exit X, and run {{ic|Xorg -depth 30 -retro}}. If this works fine, then 10-bit is working.<br />
<br />
To launch in 10-bit via {{ic|startx}}, use {{ic|startx -- -depth 30}}. To permanently enable it, create or add to:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=<br />
Section "Screen"<br />
Identifier "asdf"<br />
DefaultDepth 30<br />
EndSection<br />
}}<br />
<br />
=== Reduce output latency ===<br />
<br />
If you want to minimize latency you can disable page flipping and tear free:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
Option "EnablePageFlip" "off"<br />
Option "TearFree" "false"<br />
EndSection<br />
}}<br />
<br />
See [[Gaming#Reducing DRI latency]] to further reduce latency.<br />
<br />
{{Note|Setting these options may cause tearing and short-lived artifacts to appear.}}<br />
<br />
== Features ==<br />
<br />
=== Video acceleration ===<br />
<br />
See [[Hardware video acceleration]].<br />
<br />
=== Monitoring ===<br />
<br />
Monitoring your GPU is often used to check the temperature and also the P-states of your GPU.<br />
<br />
==== CLI (default) ====<br />
<br />
To check your GPU's P-states, execute:<br />
$ cat /sys/class/drm/card0/device/pp_od_clk_voltage<br />
To monitor your GPU, execute:<br />
$ watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info<br />
To check your GPU utilization, execute:<br />
$ cat /sys/class/drm/card0/device/gpu_busy_percent<br />
To check your GPU frequency, execute:<br />
$ cat /sys/class/drm/card0/device/pp_dpm_sclk<br />
To check your GPU temperature, execute:<br />
$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input<br />
To check your VRAM frequency, execute:<br />
$ cat /sys/class/drm/card0/device/pp_dpm_mclk<br />
To check your VRAM usage, execute:<br />
$ cat /sys/class/drm/card0/device/mem_info_vram_used<br />
To check your VRAM size, execute:<br />
$ cat /sys/class/drm/card0/device/mem_info_vram_total<br />
<br />
With [https://github.com/clbr/radeontop radeontop] utility you can view your GPU utilization, both for the total activity percent and individual blocks. Install it with {{Pkg|radeontop}} package. If it does not recognize your GPU, try {{AUR|radeontop-git}}.<br />
<br />
==== GUI ====<br />
<br />
* {{App|WattmanGTK|A GTK GUI tool to monitor your GPU's temperatures P-states|https://github.com/BoukeHaarsma23/WattmanGTK|{{AUR|wattman-gtk-git}}}}.<br />
* {{App|TuxClocker|A Qt5 monitoring and overclocking tool.|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}<br />
* {{App|AmdGuid|A basic fan control GUI fully written in Rust.|https://github.com/Eraden/amdgpud|{{AUR|amdguid-wayland-bin}}, {{AUR|amdguid-glow-bin}}}}<br />
<br />
=== Overclocking ===<br />
<br />
Since Linux 4.17, it is possible to adjust clocks and voltages of the graphics card via {{Ic|1=/sys/class/drm/card0/device/pp_od_clk_voltage}}.<br />
<br />
==== Boot parameter ====<br />
<br />
It is required to unlock access to adjust clocks and voltages in sysfs by appending the [[Kernel parameter]] {{Ic|1=amdgpu.ppfeaturemask=0xffffffff}}.<br />
<br />
==== Manual (default) ====<br />
<br />
{{Note|In sysfs, paths like {{Ic|1=/sys/class/drm/...}} are just symlinks and may change between reboots. Persistent locations can be found in {{Ic|1=/sys/devices/}}, e.g. {{Ic|1=/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/}}. Adjust the commands accordingly for a reliable result.}}<br />
<br />
To set the GPU clock for the maximum P-state 7 on e.g. a Polaris GPU to 1209MHz and 900mV voltage, run:<br />
# echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage<br />
The same procedure can be applied to the VRAM, e.g. maximum P-state 2 on Polaris 5xx series cards:<br />
# echo "m 2 1850 850" > /sys/class/drm/card0/device/pp_od_clk_voltage<br />
{{Warning|1=Double check the entered values, as mistakes might instantly cause fatal hardware damage!}}<br />
To apply, run<br />
# echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage<br />
To check if it worked out, read out clocks and voltage under 3D load:<br />
# watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info<br />
You can reset to the default values using this:<br />
# echo "r" > /sys/class/drm/card0/device/pp_od_clk_voltage<br />
<br />
It is also possible to forbid the driver so switch to certain P-states, e.g. to workaround problems with deep powersaving P-states like flickering artifacts or stutter. To force the highest VRAM P-state on a Polaris RX 5xx card, while still allowing the GPU itself to run with lower clocks, run:<br />
# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level<br />
# echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk<br />
Allow only the three highest GPU P-states:<br />
# echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk<br />
<br />
To set the allowed maximum power consumption of the GPU to e.g. 50 Watts, run<br />
# echo 50000000 > /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap<br />
<br />
Until Linux kernel 4.20, it will only be possible to decrease the value, not increase.<br />
<br />
{{Note|The above procedure was tested with a Polaris RX 560 card. There may be different behavior or bugs with different GPUs.}}<br />
<br />
==== Assisted ====<br />
<br />
If you are not inclined to fully manually overclock your GPU, there are some overclocking tools that are offered by the community to assist you to overclock and monitor your AMD GPU.<br />
<br />
===== CLI tools =====<br />
<br />
* {{App|amdgpu-clocks|A script that can be used to monitor and set custom power states for AMD GPUs. It also offers a Systemd service to apply the settings automatically upon boot.|https://github.com/sibradzic/amdgpu-clocks|{{AUR|amdgpu-clocks-git}}}}<br />
<br />
===== GUI tools =====<br />
<br />
* {{App|TuxClocker|A Qt5 monitoring and overclocking tool.|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}<br />
* {{App|CoreCtrl|A GUI overclocking tool with a WattMan-like UI that supports per-application profiles.|https://gitlab.com/corectrl/corectrl|{{Pkg|corectrl}}}}<br />
<br />
==== Startup on boot ====<br />
<br />
If you want your settings to apply automatically upon boot, consider looking at this [https://www.reddit.com/r/Amd/comments/agwroj/how_to_overclock_your_amd_gpu_on_linux/ Reddit thread] to configure and apply your settings on boot.<br />
<br />
=== Power profiles ===<br />
<br />
AMDGPU offers several optimizations via power profiles, one of the most commonly used is the compute mode for OpenCL intensive applications. Available power profiles can be listed with:<br />
{{hc|cat /sys/class/drm/card0/device/pp_power_profile_mode|<br />
NUM MODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL<br />
0 BOOTUP_DEFAULT: - - - - - -<br />
1 3D_FULL_SCREEN: 0 100 30 0 100 10<br />
2 POWER_SAVING: 10 0 30 - - -<br />
3 VIDEO: - - - 10 16 31<br />
4 VR: 0 11 50 0 100 10<br />
5 COMPUTE *: 0 5 30 10 60 25<br />
6 CUSTOM: - - - - - -<br />
}}<br />
<br />
{{Note|{{ic|card0}} identifies a specific GPU in your machine, in case of multiple GPUs be sure to address the right one.}}<br />
<br />
To use a specific power profile you should first enable manual control over them with:<br />
# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level<br />
<br />
Then to select a power profile by writing the NUM field associated with it, e.g. to enable COMPUTE run:<br />
# echo "5" > /sys/class/drm/card0/device/pp_power_profile_mode<br />
<br />
{{Note|Power profile changes should be reapplied at every boot, see [[#Startup on boot]] to automate this.}}<br />
<br />
=== Enable GPU display scaling ===<br />
<br />
{{Merge|xrandr|Not specific to AMDGPU.|section=Moving "Enable GPU display scaling" to xrandr}}<br />
<br />
To avoid the usage of the scaler which is built in the display, and use the GPU own scaler instead, when not using the native resolution of the monitor, execute:<br />
$ xrandr --output ''output'' --set "scaling mode" ''scaling_mode''<br />
Possible values for {{ic|"scaling mode"}} are: {{ic|None}}, {{ic|Full}}, {{ic|Center}}, {{ic|Full aspect}}.<br />
<br />
* To show the available outputs and settings, execute:<br />
$ xrandr --prop<br />
<br />
* To set {{ic|1=scaling mode = Full aspect}} for just every available output, execute:<br />
$ for output in $(xrandr --prop | grep -E -o -i "^[A-Z\-]+-[0-9]+"); do xrandr --output "$output" --set "scaling mode" "Full aspect"; done<br />
<br />
== Troubleshooting ==<br />
<br />
=== Xorg or applications will not start ===<br />
<br />
* "(EE) AMDGPU(0): [DRI2] DRI2SwapBuffers: drawable has no back or front?" error after opening ''glxgears'', can open Xorg server but OpenGL applications crash.<br />
* "(EE) AMDGPU(0): Given depth (32) is not supported by amdgpu driver" error, Xorg will not start.<br />
<br />
Setting the screen's depth under Xorg to 16 or 32 will cause problems/crash. To avoid that, you should use a standard screen depth of 24 by adding this to your "screen" section:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-screen.conf|<br />
Section "Screen"<br />
Identifier "Screen"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
=== Screen artifacts and frequency problem ===<br />
<br />
[[ATI#Dynamic power management|Dynamic power management]] may cause screen artifacts to appear when displaying to monitors at higher frequencies (anything above 60Hz) due to issues in the way GPU clock speeds are managed[https://bugs.freedesktop.org/show_bug.cgi?id=96868][https://gitlab.freedesktop.org/drm/amd/-/issues/234].<br />
<br />
A workaround [https://bugs.freedesktop.org/show_bug.cgi?id=96868#c13] is saving {{ic|high}} or {{ic|low}} in {{ic|/sys/class/drm/card0/device/power_dpm_force_performance_level}}.<br />
<br />
To make it persistent, you may create a [[udev]] rule:<br />
<br />
{{hc|/etc/udev/rules.d/30-amdgpu-pm.rules|<nowiki><br />
KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="high"<br />
</nowiki>}}<br />
<br />
To determine the {{ic|KERNEL}} name execute: <br />
<br />
$ udevadm info --attribute-walk /sys/class/drm/card0 | grep "KERNEL="<br />
<br />
There is also a GUI solution [https://github.com/marazmista/radeon-profile] where you can manage the "power_dpm" with {{aur|radeon-profile-git}} and {{aur|radeon-profile-daemon-git}}.<br />
<br />
==== Artifacts in Chromium ====<br />
<br />
If you see artifacts in [[Chromium]], try to force the vulkan based backend. Go to {{ic|chrome://flags}} and ''enable'' {{ic|#ignore-gpu-blacklist}} and {{ic|#enable-vulkan}}.<br />
<br />
=== R9 390 series poor performance and/or instability ===<br />
<br />
If you experience issues [https://gitlab.freedesktop.org/mesa/mesa/-/issues/1222] with a AMD R9 390 series graphics card, set {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dc=1}} as [[kernel parameters]] to force the use of amdgpu driver instead of radeon.<br />
<br />
If it still does not work, try disabling DPM, by setting the [[kernel parameters]] to: {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1}}<br />
<br />
=== Freezes with "[drm] IP block:gmc_v8_0 is hung!" kernel error ===<br />
<br />
If you experience freezes and kernel crashes during a GPU intensive task with the kernel error " [drm] IP block:gmc_v8_0 is hung!" [https://gitlab.freedesktop.org/drm/amd/issues/226], a workaround is to set {{ic|1=amdgpu.vm_update_mode=3}} as [[kernel parameters]] to force the GPUVM page tables update to be done using the CPU. Downsides are listed here [https://gitlab.freedesktop.org/drm/amd/-/issues/226#note_308665].<br />
<br />
=== Cursor corruption ===<br />
<br />
If you experience issues with the mouse cursor sometimes not rendering properly, set {{ic|Option "SWCursor" "True"}} in the {{ic|"Device"}} section of the {{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}} configuration file.<br />
<br />
If you are using {{ic|xrandr}} for scaling and the cursor is flickering or disappearing, you may be able to fix it by setting the {{ic|TearFree}} property: {{ic|xrandr --output HDMI-A-0 --set TearFree on}}.<br />
<br />
=== System freeze or crash when gaming on Vega cards ===<br />
<br />
[[ATI#Dynamic power management|Dynamic power management]] may cause a complete system freeze whilst gaming due to issues in the way GPU clock speeds are managed. [https://gitlab.freedesktop.org/drm/amd/-/issues/716] A workaround is to disable dynamic power management, see [[ATI#Dynamic power management]] for details.<br />
<br />
=== WebRenderer (Firefox) corruption ===<br />
<br />
Artifacts and other anomalies may present themselves (e.g. inability to select extension options) when [[Firefox/Tweaks#WebRender|WebRenderer]] is force enabled by the user. Workaround is to fall back to OpenGL compositing.<br />
<br />
=== Double-speed or "chipmunk" audio, or no audio when a 4K@60Hz device is connected ===<br />
<br />
This is sometimes caused by a communication issue between an AMDGPU device and a 4K display connected over HDMI. A possible workaround is to enable HDR or "Ultra HD Deep Color" via the display's built-in settings. On many Android based TVs, this means setting this to "Standard" instead of "Optimal".<br />
<br />
=== Issues with power management / dynamic re-activation of a discrete amdgpu graphics card ===<br />
<br />
If you encounter issues similar to [https://gitlab.freedesktop.org/drm/amd/-/issues/1820], you can workaround the issue by setting the [[kernel parameter]] {{ic|1=amdgpu.runpm=0}}, which prevents the dGPU from being powered down dynamically at runtime.<br />
<br />
== See also ==<br />
<br />
* [[Gentoo:AMDGPU]]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User:RaZorr&diff=729171User:RaZorr2022-05-11T08:00:32Z<p>RaZorr: </p>
<hr />
<div>{| style="text-align: left;"<br />
! Name:<br />
| Razorr<br />
|-<br />
! Role:<br />
| Arch fan<br />
|-<br />
! Email:<br />
| rayz0rr@protonmail.com &nbsp;<br />
|-<br />
! Languages: <br />
| English.<br />
|-<br />
! Programming Languages: <br />
| Python, C++, Bash.<br />
|-<br />
! style="padding: 0em 1em 0em 0em" | Other profiles:<br />
| [https://bbs.archlinux.org/profile.php?id=140316 BBS] :: [https://github.com/RayZ0rr Github]<br />
|}</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Session_lock&diff=729170Session lock2022-05-11T07:59:29Z<p>RaZorr: Mention about dpms interfering with xss-lock at 600 seconds.</p>
<hr />
<div>[[Category:Security]]<br />
[[ru:Session lock]]<br />
There are numerous utilities to lock the screen of a session. But it is important to note that the utility to use is highly dependent on the environment you are in, either the virtual console, or a specific display server (Xorg or Wayland).<br />
<br />
See [[List of applications#Screen lockers]].<br />
<br />
== By environment ==<br />
<br />
{{Merge|List of applications#Screen lockers|Same purpose, only split into categories.}}<br />
<br />
=== Virtual console ===<br />
<br />
You can use {{ic|vlock}} or {{Pkg|physlock}} to lock a virtual console.<br />
<br />
=== Xorg ===<br />
<br />
There are many ways to lock the session under Xorg, so this section is likely to be incomplete. Some methods however include:<br />
* {{ic|xlock}}, in the {{Pkg|xlockmore}} package - <br />
* {{ic|xsecurelock}}, in the {{Pkg|xsecurelock}} package<br />
* {{ic|xscreensaver-command -lock}} in the {{Pkg|xscreensaver}} package<br />
* {{Pkg|xss-lock}}<br />
* {{ic|slock}} in the {{Pkg|slock}} package<br />
* {{Pkg|kscreenlocker}}<br />
* {{Pkg|i3lock}}<br />
* {{AUR|i3lock-color}}<br />
<br />
Most desktop environments come with some way to lock the session.<br />
<br />
=== Wayland ===<br />
<br />
You can lock the session with {{Pkg|swaylock}} or {{Pkg|waylock}}.<br />
<br />
== Triggering the lock ==<br />
<br />
You can lock a session using different methods:<br />
* from a terminal<br />
* using a GUI:<br />
** from a desktop icon<br />
** using hot corners<br />
** from a menu (mouse or keyboard driven)<br />
* from a [[Keyboard shortcuts|shortcut]]<br />
* from an event:<br />
** inactivity (using [[#Inactivity|systemd]], [[#xss-lock|xss-lock]] or [[#xautolock|xautolock]])<br />
** [[#systemd events|systemd events]] (suspend, hibernate, etc.)<br />
<br />
The last point (triggering a lock from an event) is the trickiest, because you can do it in one of two ways:<br />
* get the action trigger to execute your lock, then to execute the initial action.<br />
* from the event trigger, add the lock to the event chain. So far this can only be done using systemd.<br />
<br />
=== Shell triggers ===<br />
<br />
==== Zsh ====<br />
<br />
To execute a command after terminal inactivity, you can use the TMOUT environment variable.<br />
<br />
You can combine it with a trap on the ALARM signal to execute the lock. Without a trap, it will just terminate the shell.<br />
<br />
You might want to detect if you are in a graphical environment, otherwise your GUI terminals might start disappearing without you understanding why.<br />
<br />
=== Xorg triggers ===<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} is triggered by one of two things:<br />
* systemd events<br />
* [[DPMS]]<br />
<br />
The advantage of this is that you can control a lock issued manually, by inactivity, and by a suspend command at the same place.<br />
<br />
To execute an action on one of those events:<br />
$ xss-lock <locker-utility><br />
<br />
===== systemd events =====<br />
<br />
By default, xss-lock subscribes to {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker).<br />
<br />
You can prevent xss-lock from being triggered by {{ic|suspend}} and {{ic|hibernate}} using {{ic|--ignore-sleep}}.<br />
<br />
You can trigger a manual lock using {{ic|loginctl lock-session}}.<br />
<br />
===== DPMS =====<br />
<br />
To configure DPMS signaling timeout:<br />
<br />
# Trigger screensaver after 10 minutes of inactivity<br />
xset s on<br />
xset s 600<br />
<br />
DPMS signaling can also be configured in {{ic|/etc/X11/xorg.conf.d/}} in the {{ic|Monitor}} section.<br />
<br />
Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen. For example (from {{man|1|xss-lock}}):<br />
<br />
# Dim the screen after three minutes of inactivity, lock the screen two minutes later using i3lock:<br />
xset s 180 120<br />
xss-lock -n dim-screen.sh -- i3lock -n<br />
<br />
An example {{ic|dim-screen.sh}} script can be found in {{ic|/usr/share/doc/xss-lock}}.<br />
<br />
{{Note|1=-<br />
When using xss-lock with [[DPMS]], you will have to blank the screen yourself. It will not be triggered when looking at videos.<br />
If using {{ic|xss-lock}} with timer at '600' seconds like eg, {{ic|xss-lock s 300 600}} the locker utilities may not work if dpms is enabled to dim screen at '600' seconds too. Use {{ic|xset q}} to check dpms settings and either disable dpms( [[Display_Power_Management_Signaling#Disabling_DPMS]] ) or change timer to values lower than '600'.<br />
}}<br />
<br />
==== xautolock ====<br />
<br />
$ xautolock -time 12 -locker "systemctl suspend" -detectsleep<br />
<br />
{{Note|1=<br />
xautolock has restrictive timer limits:<br />
<br />
* 1 min to 1 hour for {{ic|time}}<br />
* 10 min to 2 hour for {{ic|killtime}}<br />
<br />
It might be necessary to add {{ic|-detectsleep}} to prevent xautolock from locking the session after resuming. One nice feature of xautolock is the {{ic|corners}}.<br />
}}<br />
<br />
=== Wayland triggers ===<br />
<br />
==== swayidle ====<br />
<br />
{{Pkg|swayidle}} listens for idle activity from the Wayland compositor, as well as systemd events, and executes commands accordingly. See [[Sway#Idle]].<br />
<br />
==== D-Bus notification ====<br />
<br />
Using {{ic|loginctl lock-session}}, or the {{ic|lock}} action in {{man|5|logind.conf}}, you can notify the system through DBUS that you want to lock. This notification can then be processed, for example by xss-lock.<br />
<br />
==== Inactivity ====<br />
<br />
In {{man|5|logind.conf}}, you can configure the {{ic|IdleAction}} to {{ic|lock}}. This will trigger a DBUS notification, that will have to be processed (for example by xsslock) to lock the session.<br />
<br />
Note that this is for a global system (so this is not ideal for a multi user environment).<br />
<br />
Note also that "this requires that user sessions correctly report the idle status to the system".<br />
<br />
==== Units ====<br />
<br />
===== Before suspend or hibernate =====<br />
<br />
You can use a [[Power management#Sleep hooks|Sleep hook]].<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Lock the screen<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/i3lock -c 000000<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
To enable it for a certain user, [[enable]] {{ic|sleep@''Username''.service}}.<br />
<br />
===== Lid closing =====<br />
<br />
You can use the {{ic|lock}} action using the related [[Power management#ACPI events|ACPI event]].<br />
<br />
== See also ==<br />
<br />
* [https://geoff.greer.fm/2018/01/02/linux-laptop-locking/ Geoff Greer's site: Linux Laptop Locking]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Thawn&diff=729131User talk:Thawn2022-05-11T05:17:38Z<p>RaZorr: Suggest encrypt hook option.</p>
<hr />
<div>In '''configure and install bootloader''' secction you are mixing options for ''encrypt'' hook and ''sd-encrypt'' hook.<br />
<br />
There is also inconsistency with the mount point for ''esp''. In some notes it is referred to as {{ic|/efi}} but in commands it is {{ic|/esp}}. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:17, 11 May 2022 (UTC)<br />
<br />
<br />
Thank you very much for your feedback!<br />
<br />
I am aware that using {{ic|1=rd.luks.options=discard}} together with the cryptdevice option {{ic|enable-discards}} is a bit of a hack, but the former was the only way, I could get trim to actually work. See also the note below that part in the text. I am open for suggestions on how to fix this (both here in the docs as well as on my machine ;-) )<br />
<br />
I fixed the {{ic|/efi}} {{ic|/esp}} inconsistencies.<br />
<br />
[[User:Thawn|Thawn]] ([[User talk:Thawn|talk]]) 06:36, 10 May 2022 (UTC)<br />
<br />
::Have you tried the {{ic|1=cryptdevice=/dev/sdaX:root:allow-discards}} option? From here [[Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)]] --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:17, 11 May 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:ZFS&diff=728975Talk:ZFS2022-05-10T00:57:38Z<p>RaZorr: /* Add instructions on mounting using fstab */ new section</p>
<hr />
<div>== Bindmount ==<br />
Where does this file go and what other steps are required?<br />
<br />
I would expect: /etc/systemd/system/<br />
<br />
Then: systemctl enable srv-nfs4-media.mount<br />
<br />
[[User:Msalerno|Msalerno]] ([[User talk:Msalerno|talk]]) 02:36, 22 October 2015 (UTC)<br />
<br />
== resume hook ==<br />
In think in the page is a typo, the page should state ''resume hook'' instead of hibernate, but the limitation still applies. Can anyone confirm that the resume hook must appear before filesystems? [[User:Ezzetabi|Ezzetabi]] ([[User talk:Ezzetabi|talk]]) 09:49, 18 August 2015 (UTC)<br />
<br />
== Automatic build script ==<br />
<br />
I'm fine with deleting the scripts. I only posted it because graysky's script never worked for me. Long stuff like this would be useful if the ArchWiki featured roll-up text. [[User:Severach|Severach]] ([[User talk:Severach|talk]]) 10:07, 9 August 2015 (UTC)<br />
<br />
:I'd suggest to maintain it in a github repo. You get better versioning, syntax highlighting, cloning, etc. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:46, 9 August 2015 (UTC)<br />
<br />
::...or an [https://help.github.com/articles/about-gists/#anonymous-gists anonymous gist] if you don't have nor want to create a GitHub account. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:40, 10 August 2015 (UTC)<br />
<br />
:Isn't that exactly what DKMS is doing? There DKMS packages in the AUR. [[User:Das j|Das j]] ([[User talk:Das j|talk]]) 20:01, 10 January 2016 (UTC)<br />
<br />
== Automatic snapshots ==<br />
{{AUR|zfs-auto-snapshot-git}} seems to have disappeared from the AUR. I haven't been able to find any information on why it was deleted; does anyone know? In any case, it should probably be removed from this page.<br />
[[User:Warai otoko|warai otoko]] ([[User talk:Warai otoko|talk]]) 03:21, 2 September 2015 (UTC)<br />
<br />
:On further inspection, looks like it may have gotten lost in the transition to AUR4. It should be resubmitted if we want to continue recommending it here; I've found it useful, at any rate. [[User:Warai otoko|Warai otoko]] ([[User talk:Warai otoko|talk]]) 04:43, 2 September 2015 (UTC)<br />
<br />
:: I've recreated it. I use this script as well. --[[User:Chungy|Chungy]] ([[User talk:Chungy|talk]]) 02:49, 3 September 2015 (UTC)<br />
<br />
== Configuration ==<br />
<br />
The configuration section has WAY to few infos about what systemd unit(s) to enable. Thanks to @kerberizer I finally managed to get the mounts working with the command <br />
<br />
# systemctl preset $(tail -n +2 /usr/lib/systemd/system-preset/50-zfs.preset | cut -d ' ' -f 2)<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 15:21, 27 October 2016 (UTC)<br />
<br />
<br />
@Z3ntu I have ZFS running on a few systems and never had to enable any services, it should work by default, if not then file a bug on the package<br />
<br />
[[User:Justin8|Justin8]] ([[User talk:Justin8|talk]]) 22:04, 27 October 2016 (UTC)<br />
<br />
@Justin8 I tried it both in a virtual machine and on a physical computer that when you don't enable any services (I use "zfs-linux" from the archzfs repo), create a pool and reboot, it doesn't exist anymore (zpool status) and the pools don't get mounted without the zfs-mount service (or whatever it is called). I found a related issue on github: https://github.com/archzfs/archzfs/issues/61<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 08:34, 28 October 2016 (UTC)<br />
<br />
<br />
There seems to be a new systemd target ''zfs-import.target'' which must be enabled in order to auto-mount? Otherwise ''zfs-mount.service'' will be executed before ''zfs-import-cache.service'' on my machine and nothing will be mounted. --[[User:Swordfeng|Swordfeng]] ([[User talk:Swordfeng|talk]]) 12:55, 8 November 2017 (UTC)<br />
<br />
I think the section about systemd units should be rewritten to remove the old stale information and bring the required command-line to the fore. As mentioned on the github issue linked from the page and also repeated above by @Z3ntu. I've just been experimenting with ZFS and wasted a little time on this that could have been avoided if the page had been updated back in 2016. I haven't cahnged the page except to add the required command line there in case there is still relevance to the other text that I don't realise. I have just started using ZFS myself.<br />
[[User:starfry|starfry]] ([[User talk:starfry|talk]]) 16:07, 31 May 2018 (UTC)<br />
: I’ve set up ZFS recently and the ''systemctl enable'' commands from the Wiki page have worked fine for me so far. What do you mean by “old stale information,” and why is ''systemctl preset […]'' a “required command line?” —[[User:Auerhuhn|Auerhuhn]] ([[User talk:Auerhuhn|talk]]) 16:33, 31 May 2018 (UTC)<br />
<br />
That's why I never deleted anything from the page. I found that the ''systemctl enable'' commands worked up to the point that I rebooted. I discovered that the zpools were not imported on boot. Searching for information led me to the command-line on the github post and that did work for me. I thought I should raise its profile a little because I wasted a few hours on it. Actually I realised also I didn't enable the 3 services listed separately - just the ones at the top of the section (there are 6 services referenced by the github issue). But that probably is why I had the problem! Like I said, I have only just started with ZFS (I am testing in a VM with files rather than real devices) and it is possible that doing it in the small hours of the morning wasn't a good idea. The info on the page as it was left me asking more questions which were answered by the github issue and, in particular, that command line sequence. You don't need that command-line but you do need the systemd services that it enables (you could enable them by hand if you preferred). Maybe you don't need all six of them. But, as it was, it wasn't clear (to me).<br />
[[User:starfry|starfry]] ([[User talk:starfry|talk]]) 16:07, 31 May 2018 (UTC)<br />
<br />
== Scrub ==<br />
<br />
The advise to scrub at least once a week is completely unsubstantiated and probably incorrect in almost all situations. Advise should be acompanied by some argumentation and preferably links to support the claim.<br />
<br />
There is a good blog from Oracle about when and why (or not), to scrub:<br />
https://blogs.oracle.com/wonders-of-zfs-storage/disk-scrub-why-and-when-v2<br />
<br />
I wanted to edit the page to include the most important bits about scrubbing, but figured I'd throw it up for discussion first, what do people think about this?<br />
[[User:Mouseman|Mouseman]] — ([[User talk:Mouseman|talk]]) 13:15, 21 October 2018 (UTC)<br />
<br />
: I have no strong opinion but the most pragmatic/helpful part of Oracle’s article appears to be the list of three tips near the end. I feel paraphrasing those three points in the wiki would be a good thing, together with an external link to Oracle’s article (which is pretty good) to cover the details. — [[User:Auerhuhn|Auerhuhn]] ([[User talk:Auerhuhn|talk]]) 13:51, 21 October 2018 (UTC)<br />
<br />
:: Thanks for the reply. I agree, although I was thinking to include the 'Should I do this' too. I'll let this sit here for a few days and see what else turns up and edit the page next week or weekend. — [[User:Mouseman|Mouseman]] ([[User talk:Mouseman|talk]]) 17:38, 21 October 2018 (UTC)<br />
<br />
: I was curious when I saw the factual accuracy banner. I've been reading [https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ Aaron Toponce's guide to ZFS administration] which is an extremely thorough walkthrough. In his [https://pthree.org/2012/12/11/zfs-administration-part-vi-scrub-and-resilver/ chapter on scrubbing and resilvering] he lists two heuristics. He suggests, "[t]he recommended frequency at which you should scrub the data depends on the quality of the underlying disks. If you have SAS or FC disks, then once per month should be sufficient. If you have consumer grade SATA or SCSI, you should do once per week." That might be the source of the suggestion? I'd love to hear more from people who have more experience with ZFS. --[[User:Metatinara|Metatinara]] ([[User talk:Metatinara|talk]]) 04:43, 23 November 2018 (UTC)<br />
<br />
:: Your reply reminded me that I wanted to edit the page as discussed above. I agree that guide is very good, it has helped me greatly when I got started with ZFS. But again, I have to challenge the advise. On what basis should consumer grade harddisks be scrubbed once a week? As far as I am concerned, there is no evidence, no data to support such a claim. How likely is bitrot to occur due to degradation or solar flares? EMP? How many bits can flip before data becomes irrepairable? If we have those numbers from different vendors in different situations, we can actually make an educated guess at how often scrubs should take place. I don't know of any such data or research. I know I am only one guy with limited experience but here it is: I have been using ZFS for about 6 years in three different configurations, all consumer or prosumer hardware. Before that, I used parchive and later par2 for I don't know, 20 odd years, to create 10% parity sets on important live data and offline backups, so that I could repair corruption. I would stash away old harddisks as backups like this. In my time, I had to use par2 only once because a hard drive went bad and ran out of realocated sectors. And it wasn't even a old disk, it was still in warranty. Not once did a scrub actually have to repair something. Not once did I ever find evidence of bitrot. Doesn't mean it doesn't exist because I know it does, but based on my own experience, I think it is extremely unlikely to occur and when it does, ZFS can fix it unless it's too much; but how long does that take? So based on my own experience, I am running it once every few months and I'll likely decrease the frequency to once every 6 months or so.[[User:Mouseman|Mouseman]] ([[User talk:Mouseman|talk]])<br />
<br />
::: Those are some great thoughts and anecdotes; thank you for sharing them! I think the way you went about your edit is good. Giving some resources to help you make the decision seems like a better approach than "do this without any justification." I appreciate the direct approach that most of the Arch Wiki articles take, but in this case, it seems like more information and less prescription is the better approach. — [[User:Metatinara|Metatinara]] ([[User talk:Metatinara|talk]]) 17:36, 24 November 2018 (UTC)<br />
<br />
== xattr=sa under tuning? ==<br />
<br />
I've seen a lot of people setting xattr=sa which disables the creation of hidden subdirectories for storing extended attributes and stores them directly in inodes instead. This has performance advantages and makes the output of snapshot diffs cleaner. Should we add it to the Tuning section?<br />
[[User:Hinzundcode|Hinzundcode]] ([[User talk:Hinzundcode|talk]]) 22:12, 20 March 2019 (UTC)<br />
<br />
== Why use partition labels? ==<br />
<br />
The page mentions creating a pool using partition labels, why? It shouldn't be recommended/needed to create partitions as ZFS will create/overwrite the partition table. Should this section be removed?<br />
[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 10:35, 31 March 2019 (UTC)<br />
<br />
== Unlock encrypted home at boot time ==<br />
<br />
There is an example /etc/systemd/system/zfskey-tank@.service but systemd can't deal with services with slashes in them:<br />
systemctl enable zfskey-zroot@zroot/data/home<br />
Failed to enable unit: File zfskey-zroot@zroot/data/home: Invalid argument<br />
<br />
There is a second example /etc/systemd/system/zfs-load-key.service that has <br />
ExecStart=/usr/bin/bash -c '/usr/bin/zfs load-key -a'<br />
<br />
That also does not work in the case that a password is needed: it doesn't prompt, it just fails at startup. So I seem to be stuck with having one password for "all" encrypted datasets (ok since there's only one) and explicitly prompting for it. At least I got that working on one system recently, but forgot the details, and now it's down with a hardware failure and I'm trying to solve it again on another system.<br />
<br />
I would like to have a way to log in as a particular user and then unlock that user's home directory (which should be a separate dataset) with the same password. From the command line as part of the normal login process. Any ideas?<br />
<br />
{{Unsigned|07:26, 13 December 2019 (UTC)|Ecloud}}<br />
<br />
:Please sign your comments. You should use dashes instead, {{ic|zfskey-tank@my-dataset.service}}. If you want to load all keys just use {{ic|zfs-load-key.service}}. Make sure the datasets are mounted at boot.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 12:54, 14 December 2019 (UTC)<br />
<br />
== Actual implication? ==<br />
<br />
{{Note|This situation sometimes locks down the normal rolling update process by unsatisfied dependencies because the new kernel version, proposed by update, is unsupported by ZFSonLinux.}}<br />
<br />
What does this actually mean in practice? Does it mean that updates block for everyone using Arch? Or that updates for zfs users are blocked? Or that updates for zfs users go ahead but things break, and if so, what? Or something else? [[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 10:39, 22 March 2020 (UTC)<br />
<br />
So it appears with the dkms method at least, upgrades of package linux always succeeds, assuming non-root filesystems, but zfs modules won't load until the dkms package supports the version of kernel. This means that you'll boot, but zfs list etc will fail. [[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]])<br />
<br />
== IgnorePkg? ==<br />
<br />
Tip: Add an IgnorePkg entry to pacman.conf to prevent these packages from upgrading when doing a regular update.<br />
<br />
Why would this be useful? I.e. why wouldn't we want these packages upgrading?<br />
<br />
Clicking on IgnorePkg says that adding entries isn't a good idea. <br />
If this is set, should it be set forever or just for a while?[[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 12:40, 22 March 2020 (UTC)<br />
<br />
== Too much memory section ==<br />
<br />
I think the entry on too much memory could do with being revised.<br />
E.g. should the entries (min/max) really be added as kernel parameters (e.g. grub) or via options entries in /etc/modprobe.d?<br />
<br />
At least for the dkms version, mine are set via a file I created in /etc/modprobe.d<br />
[[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 11:56, 27 March 2020 (UTC)<br />
<br />
== aclinherit=passthrough? ==<br />
<br />
Is it really beneficial to set {{ic|1=aclinherit=passthrough}} on top of {{ic|1=acltype=posixacl}} and {{ic|1=xattr=sa}}?<br />
<br />
Here's the explanation of the attribute from the latest ZFS (0.8.3) manual:<br />
<br />
{{bc|1=aclinherit=discard{{!}}noallow{{!}}restricted{{!}}passthrough{{!}}passthrough-x<br />
Controls how ACEs are inherited when files and directories are created.<br />
discard does not inherit any ACEs.<br />
noallow only inherits inheritable ACEs that specify "deny" permissions.<br />
restricted default, removes the write_acl and write_owner permissions when the ACE is inherited.<br />
passthrough inherits all inheritable ACEs without any modifications.<br />
passthrough-x same meaning as passthrough, except that the owner@, group@, and everyone@ ACEs inherit the execute permission only if the file creation mode also requests the execute bit.<br />
<br />
When the property value is set to passthrough, files are created with a mode determined by the inheritable ACEs. If no inheritable ACEs exist that affect the mode, then the mode is set in accordance to the requested mode from the application.<br />
<br />
The aclinherit property does not apply to POSIX ACLs.}}<br />
<br />
So the difference between {{ic|restricted}} and {{ic|passthrough}} is that the latter preserves {{ic|write_acl}} and {{ic|write_owner}}, which seem to be Solaris standards. And it explicitly says 'The aclinherit property does not apply to POSIX ACLs'.<br />
<br />
[[User:FrederickZh|FrederickZh]] ([[User talk:FrederickZh|talk]]) 06:44, 2 May 2020 (UTC)<br />
<br />
== zfs_vdev_scheduler deprecation? ==<br />
<br />
It seems that the effect of this kernel module option was deprecated and then removed by this PR: https://github.com/openzfs/zfs/pull/9609/files<br />
<br />
From the documentation/comment bit (which has been also removed by that commit) I assume that now the kernel module respects block device level settings for system itself.<br />
<br />
[[User:Thaewrapt|Thaewrapt]] ([[User talk:Thaewrapt|talk]]) 11:22, 19 September 2020 (UTC)<br />
<br />
== Setting options for sharenfs ==<br />
<br />
I'm not sure where would be an appropriate place to add this information, but I struggled for a little while trying to find out how I could pass additional options to export since we don't use /etc/exports. After looking at the manpage [https://zfsonlinux.org/manpages/0.7.13/man8/zfs.8.html] I figured out that any options set in the sharenfs property would be used - I think this alone would be useful to put in, even as a blurb.<br />
<br />
Also, it looks like there's a bug in the sharenfs handling code. Per this issue [https://zfsonlinux.org/manpages/0.7.13/man8/zfs.8.html], you have to specify the "rw" or "ro" option at the end of others (sec=krb5 in my case) for them to take effect at all. That is, my sharenfs property ends up being 'sharenfs="sec=krb5,rw=@10.69.69.0/24"'.<br />
<br />
[[User:Jadelclemens|Jadelclemens]] ([[User talk:Jadelclemens|talk]]) 07:26, 6 May 2021 (UTC)<br />
<br />
== unlock at boot time service with passphrase doesn't work with automount ==<br />
<br />
The systemd service provided does not work with automount when using a passphrase since there is no ordering dependency between it and {{ic|zfs-mount.service}}. The only dependency specified is via {{ic|WantedBy}} which makes it so that it starts in parallel with {{ic|zfs-mount}}. I propose the following systemd unit instead, based on the following issue from the zfs github https://github.com/openzfs/zfs/issues/8750:<br />
<br />
{{hc|1=/etc/systemd/system/zfs-load-key@.service|2=<nowiki>[Unit]<br />
Description=Load %I encryption keys<br />
After=zfs-import.target<br />
Before=systemd-user-sessions.service zfs-mount.service<br />
Requires=zfs-import.target<br />
DefaultDependencies=no<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/usr/bin/bash -c 'until (systemd-ask-password "Encrypted ZFS password for %I" --no-tty | zfs load-key %I); do echo "Try again!"; done'<br />
<br />
[Install]<br />
WantedBy=zfs-mount.service<br />
</nowiki><br />
}}<br />
<br />
It uses {{ic|1=DefaultDependencies=no}} to prevent a cycle which would be introduced by simply using {{ic|Before}}.<br />
<br />
[[User:Nikitau|Nikitau]] ([[User talk:Nikitau|talk]]) 16:53, 20 May 2021 (UTC)<br />
<br />
== Is the parameter {{ic|ashift}} really uneditable after pool creation? ==<br />
<br />
When I run {{ic|zpool}}:<br />
<br />
{{bc|1=<nowiki/><br />
the following properties are supported:<br />
PROPERTY EDIT VALUES<br />
ashift YES <ashift, 9-16, or 0=default><br />
}}<br />
<br />
Also, in {{man|8|zpoolprops|DESCRIPTION}}:<br />
<br />
{{bc|1=<nowiki/><br />
The following properties can be set at creation time and import time, and later changed with the zpool set command:<br />
ashift=ashift<br />
}}<br />
<br />
[[User:Chuang|Chuang]] ([[User talk:Chuang|talk]]) 04:33, 20 June 2021 (UTC)<br />
<br />
== Any good references how to enable zstd compression? ==<br />
<br />
I would like to add this information to the Wiki, however I don't seem to find any good references how to use/enable zstd on zfs 2.0.4. If someone has good guides, please let me know. :)<br />
[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 06:04, 23 June 2021 (UTC)<br />
<br />
== Problematic implications of zfs-mount.service with ZFS on root ==<br />
<br />
I've had a system running with ZFS on root and today I finally switched to zfs-mount-generator and suggest you do the same if you have anything important for/during the boot process on ZFS.<br />
In my case, it was /var/log/journal, as I have /var on a non-root dataset. The problem is that systemd-journal-flush.service uses {{ic|1=RequiresMountsFor=/var/log/journal}}, except var.mount doesn't exist until zfs-mount.service runs because systemd doesn't know there's supposed to be a mountpoint there. With the default of {{ic|1=Storage=auto}} in {{man|5|journald.conf}}, this presumably resulted in journald never switching from /run to /var, culminating in a couple months of lost logs, as well as boot history under {{ic|journalctl --list-boots}} being completely broken. I only noticed because I compared the output to {{ic|last reboot}} on a whim because it didn't feel right, only to find severe discrepancies between the two. I can only assume other services with similar mount dependencies are equally at risk of breakage.<br />
<br />
[[User:FallenWarrior2k|FallenWarrior2k]] ([[User talk:FallenWarrior2k|talk]]) 14:44, 23 September 2021 (UTC)<br />
<br />
:I'd agree with using zfs-mount-generator over zfs-mount for boot logs. I managed to get it to save logs with an override file but it doesn't start logging until after zfs-mount is completed.<br />
:{{bc|<nowiki>#/etc/systemd/system/systemd-journald.service.d/override.conf<br />
<br />
[Unit]<br />
Requires=zfs-mount.service<br />
After=zfs-mount.service</nowiki>}}<br />
:[[User:Echo-84|Echo-84]] ([[User talk:Echo-84|talk]]) 16:33, 3 January 2022 (UTC)<br />
<br />
::If you want to solve this with overrides, you need to put the dependency on systemd-journal-flush.service, not systemd-journald.service itself. Journald normally starts at early boot and initially logs to {{ic|/run/log/journal}}. Then, once necessary file systems are mounted (usually ordered with {{ic|RequiresMountsFor}}), systemd-journal-flush.services issues a {{ic|journalctl --flush}}, which makes journald switch to {{ic|/var/log/journal}}. The way you have done it, however, prevents journald from starting at all until ZFS mounting is complete.<br />
::In any case, even if you do fix that, it is a workaround, yes, but not a solution. After all, the point of {{ic|RequiresMountsFor}} is that you don't have to manually create dependencies for every unit that depends on a mount point, i.e. units declare what directories they need and systemd ensures those are mounted before the unit is started. Journald was just an example; this applies to any unit that will misbehave if its mount dependencies are not honored. This means you'd have to manually inspect every unit file that uses {{ic|RequiresMountsFor}} to see if it's affected and add an appropriate override. With zfs-mount-generator all of this works as intended and setup was effortless by just following the steps that already exist in the wiki.<br />
::[[User:FallenWarrior2k|FallenWarrior2k]] ([[User talk:FallenWarrior2k|talk]]) 17:02, 3 January 2022 (UTC)<br />
<br />
== Add instructions on mounting using fstab ==<br />
<br />
[https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Root%20on%20ZFS/3-system-configuration.html| openzfs guide] uses {{ic|/etc/fstab}} instead of {{ic|zfs-mount}} service reasoning that it provides ''precise control'' than the service. Can another section in [[ZFS#Configuration]] be added for instructions with {{ic|/etc/fstab}}?</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Thawn&diff=728973User talk:Thawn2022-05-10T00:40:44Z<p>RaZorr: Small inconsistencies in commands</p>
<hr />
<div>In '''configure and install bootloader''' secction you are mixing options for ''encrypt'' hook and ''sd-encrypt'' hook.<br />
<br />
There is also inconsistency with the mount point for ''esp''. In some notes it is referred to as {{ic|/efi}} but in commands it is {{ic|/esp}}.</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=724287User talk:Scimmia2022-03-25T12:28:14Z<p>RaZorr: Provide correct links</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned? Ic ouldn't find it.<br />
<br />
:As I said, it's when you 'set root='. Specifically when it says "set root=(hdX,Y) sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition (/)" As that's the partition you're working on, paths are pretty much common sense from there.<br />
<br />
::If common sense is considered, the Arch wiki would be much shorter. But then again what seems like commmon sense to us might not be for new users. In the GRUB wiki page itself under, [[GRUB#Encrypted_/boot|Encrypted_/boot]], the tip I mentioned regarding {{ic|/boot}} in path is mentioned. But I suggest to add it in more places especially tthe [https://wiki.archlinux.org/title/GRUB#Custom_grub.cfg Custom_grub.cfg] section becuase incorrect configuration will lead to unbootable systems. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:40, 25 March 2022 (UTC)<br />
<br />
:::No, the tip you mentioned regarding /boot is NOT in the Encrypted_/boot section.<br />
:::You keep saying how this could lead to an unbootable system; yeah, so what? If you screw up a config, it doesn't work, that's pretty normal and this situation is not special.<br />
:::If you want to expand the 'set root=' part a bit and say that all paths are relative to this, that can make sense. The tip as you had it did not.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 12:11, 25 March 2022 (UTC)<br />
::::The section I was talking about was wrong. Sorry for that. The actual one is this [[GRUB#Using_the_rescue_console]]. This has multiple notes on the {{ic|/boot}} prefix. Expanding the 'set root=' part and saying about relative paths is a relatively complicated way of saying the same thing as the tip/note I had provided. So, it doesn't really make any sense and I would rather avoid that. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 12:27, 25 March 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Session_lock&diff=724264Session lock2022-03-25T07:53:04Z<p>RaZorr: Add location example dim-screen script for xss-lock.</p>
<hr />
<div>[[Category:Security]]<br />
[[ru:Session lock]]<br />
There are numerous utilities to lock the screen of a session. But it is important to note that the utility to use is highly dependent on the environment you are in, either the virtual console, or a specific display server (Xorg or Wayland).<br />
<br />
See [[List of applications#Screen lockers]].<br />
<br />
== By environment ==<br />
<br />
{{Merge|List of applications#Screen lockers|Same purpose, only split into categories.}}<br />
<br />
=== Virtual console ===<br />
<br />
You can use {{ic|vlock}} or {{Pkg|physlock}} to lock a virtual console.<br />
<br />
=== Xorg ===<br />
<br />
There are many ways to lock the session under Xorg, so this section is likely to be incomplete. Some methods however include:<br />
* {{ic|xlock}}, in the {{Pkg|xlockmore}} package - <br />
* {{ic|xsecurelock}}, in the {{Pkg|xsecurelock}} package<br />
* {{ic|xscreensaver-command -lock}} in the {{Pkg|xscreensaver}} package<br />
* {{Pkg|xss-lock}}<br />
* {{ic|slock}} in the {{Pkg|slock}} package<br />
* {{Pkg|kscreenlocker}}<br />
* {{Pkg|i3lock}}<br />
* {{AUR|i3lock-color}}<br />
<br />
Most desktop environments come with some way to lock the session.<br />
<br />
=== Wayland ===<br />
<br />
You can lock the session with {{Pkg|swaylock}} or {{Pkg|waylock}}.<br />
<br />
== Triggering the lock ==<br />
<br />
You can lock a session using different methods:<br />
* from a terminal<br />
* using a GUI:<br />
** from a desktop icon<br />
** using hot corners<br />
** from a menu (mouse or keyboard driven)<br />
* from a [[Keyboard shortcuts|shortcut]]<br />
* from an event:<br />
** inactivity (using [[#Inactivity|systemd]], [[#xss-lock|xss-lock]] or [[#xautolock|xautolock]])<br />
** [[#systemd events|systemd events]] (suspend, hibernate, etc.)<br />
<br />
The last point (triggering a lock from an event) is the trickiest, because you can do it in one of two ways:<br />
* get the action trigger to execute your lock, then to execute the initial action.<br />
* from the event trigger, add the lock to the event chain. So far this can only be done using systemd.<br />
<br />
=== Shell triggers ===<br />
<br />
==== Zsh ====<br />
<br />
To execute a command after terminal inactivity, you can use the TMOUT environment variable.<br />
<br />
You can combine it with a trap on the ALARM signal to execute the lock. Without a trap, it will just terminate the shell.<br />
<br />
You might want to detect if you are in a graphical environment, otherwise your GUI terminals might start disappearing without you understanding why.<br />
<br />
=== Xorg triggers ===<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} is triggered by one of two things:<br />
* systemd events<br />
* [[DPMS]]<br />
<br />
The advantage of this is that you can control a lock issued manually, by inactivity, and by a suspend command at the same place.<br />
<br />
To execute an action on one of those events:<br />
$ xss-lock <locker-utility><br />
<br />
===== systemd events =====<br />
<br />
By default, xss-lock subscribes to {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker).<br />
<br />
You can prevent xss-lock from being triggered by {{ic|suspend}} and {{ic|hibernate}} using {{ic|--ignore-sleep}}.<br />
<br />
You can trigger a manual lock using {{ic|loginctl lock-session}}.<br />
<br />
===== DPMS =====<br />
<br />
To configure DPMS signaling timeout:<br />
{{bc|<br />
# Trigger screensaver after 10 minutes of inactivity<br />
xset s on<br />
xset s 600<br />
}}<br />
DPMS signaling can also be configured in {{ic|/etc/X11/xorg.conf.d/}} in the {{ic|Monitor}} section.<br />
<br />
Using DPMS signaling, you can set a second timer, for example to notify the user or to dim the screen.<br />
For example (from {{man|1|xss-lock}}):<br />
{{bc|<br />
# Dim the screen after three minutes of inactivity, lock the screen two minutes later using i3lock:<br />
<br />
xset s 180 120<br />
xss-lock -n dim-screen.sh -- i3lock -n<br />
}}<br />
An example ''dim-screen.sh'' script can be found in {{ic|/usr/share/doc/xss-lock}}.<br />
{{Note|When using xss-lock with [[DPMS]], you will have to blank the screen yourself. It will not be triggered when looking at videos.}}<br />
<br />
==== xautolock ====<br />
<br />
$ xautolock -time 12 -locker "systemctl suspend" -detectsleep<br />
<br />
{{Note|1=<br />
xautolock has restrictive timer limits:<br />
<br />
* 1 min to 1 hour for {{ic|time}}<br />
* 10 min to 2 hour for {{ic|killtime}}<br />
<br />
It might be necessary to add {{ic|-detectsleep}} to prevent xautolock from locking the session after resuming. One nice feature of xautolock is the {{ic|corners}}.<br />
}}<br />
<br />
=== Wayland triggers ===<br />
<br />
==== swayidle ====<br />
<br />
{{Pkg|swayidle}} listens for idle activity from the Wayland compositor, as well as systemd events, and executes commands accordingly. See [[Sway#Idle]].<br />
<br />
==== D-Bus notification ====<br />
<br />
Using {{ic|loginctl lock-session}}, or the {{ic|lock}} action in {{man|5|logind.conf}}, you can notify the system through DBUS that you want to lock. This notification can then be processed, for example by xss-lock.<br />
<br />
==== Inactivity ====<br />
<br />
In {{man|5|logind.conf}}, you can configure the {{ic|IdleAction}} to {{ic|lock}}. This will trigger a DBUS notification, that will have to be processed (for example by xsslock) to lock the session.<br />
<br />
Note that this is for a global system (so this is not ideal for a multi user environment).<br />
<br />
Note also that "this requires that user sessions correctly report the idle status to the system".<br />
<br />
==== Units ====<br />
<br />
===== Before suspend or hibernate =====<br />
<br />
You can use a [[Power management#Sleep hooks|Sleep hook]].<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Lock the screen<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/i3lock -c 000000<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
To enable it for a certain user, [[enable]] {{ic|sleep@''Username''.service}}.<br />
<br />
===== Lid closing =====<br />
<br />
You can use the {{ic|lock}} action using the related [[Power management#ACPI events|ACPI event]].<br />
<br />
== See also ==<br />
<br />
* [https://geoff.greer.fm/2018/01/02/linux-laptop-locking/ Geoff Greer's site: Linux Laptop Locking]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=724254User talk:Scimmia2022-03-25T05:40:28Z<p>RaZorr: reply on importance of that addition</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned? Ic ouldn't find it.<br />
<br />
:As I said, it's when you 'set root='. Specifically when it says "set root=(hdX,Y) sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition (/)" As that's the partition you're working on, paths are pretty much common sense from there.<br />
<br />
::If common sense is considered, the Arch wiki would be much shorter. But then again what seems like commmon sense to us might not be for new users. In the GRUB wiki page itself under, [[GRUB#Encrypted_/boot|Encrypted_/boot]], the tip I mentioned regarding {{ic|/boot}} in path is mentioned. But I suggest to add it in more places especially tthe [https://wiki.archlinux.org/title/GRUB#Custom_grub.cfg Custom_grub.cfg] section becuase incorrect configuration will lead to unbootable systems. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 05:40, 25 March 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=724146Talk:GRUB2022-03-24T13:41:11Z<p>RaZorr: /* Highlight importance of adding or removing '/boot' from path in 'initrd=..' lines in configuration */ new section</p>
<hr />
<div>== Alpha sorting for kernel names without versions ==<br />
<br />
When installing the "linux" and "linux-lts" kernels on a basic install, the ''/etc/grub.d/10_linux'' in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:<br />
<br />
* https://savannah.gnu.org/bugs/index.php?42597<br />
<br />
Forum discussion w/patch:<br />
<br />
* https://bbs.archlinux.org/viewtopic.php?pid=1428523<br />
<br />
: [//gist.github.com/fstirlitz/7639129 I solved this (and other problems) long ago…] why nobody applied this patch to the Arch package is beyond me. [[User:Fstirlitz|felix]] ([[User talk:Fstirlitz|talk]]) 14:11, 8 August 2014 (UTC)<br />
<br />
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)<br />
<br />
:::I'd leave this open right now, as it seems a candidate for merging with [[GRUB/Tips and tricks#Multiple entries]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:36, 22 December 2014 (UTC)<br />
<br />
== Manually generate grub.cfg ==<br />
<br />
In previous revisions, instructions on manually creating a grub.cfg were removed [https://wiki.archlinux.org/index.php?title=GRUB&diff=347960&oldid=347954], and later added to [[GRUB/Tips and tricks]] [https://wiki.archlinux.org/index.php?title=GRUB/Tips_and_tricks&oldid=349645#Manually_creating_grub.cfg]. This was discussed with [https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=349659&oldid=349657].<br />
However, as it turns out manually creating a grub.cfg is in fact ''encouraged'' upstream [https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html#Simple-configuration]. This is especially true in Arch as we don't have versioned kernels: {{Bug|16702}} (and thus no changing vmlinuz/initrd paths). As such I believe we should reduce the role of grub-mkconfig, expand on grub.cfg and move it back to the main article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:24, 27 June 2015 (UTC)<br />
: I don't see a problem with this.<br />
: From upstream: '' In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so... and to '''disable any system provided by their distribution to automatically run grub-mkconfig.'''''<br />
: Correct me if I'm wrong here but I don't think we have anything that automatically calls grub-mkconfig. Therefore manually creating/editing grub.cfg shouldn't be a problem. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:01, 27 June 2015 (UTC)<br />
<br />
::+1, this will also avoid random notes [https://wiki.archlinux.org/index.php?title=Multiboot_USB_drive&diff=379818&oldid=379749 like this] in other articles. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 27 June 2015 (UTC)<br />
<br />
::Nothing calls grub-mkconfig, no. Yet, I tend to disagree. Reasons: (1) the article is still too long anyway and the fresh start on manually creating grub.cfg is a good base to expand in tips&tricks. (2) Reducing grub-mkconfig basically also means having to touch most content that covers the main options in /etc/default/grub. If I see it right, the Arch package comes with defaults there. (3) Thankfully grub-mkconfig automatically figures menu entry names, but also determines a root= UUID by default these days. The latter not a big problem for simple roots, but cumbersome to describe for others (e.g. when a device mapper is used, lvm, luks, ...). Likewise, grub-mkconfig also uses output from {{Pkg|os-prober}} to automatically generate entries. <br />
::So, I don't think it is a straight-forward task and make things clearer. The instances one would save on "Now re-generate the configuration: ..." would probably have to be replaced with "Now better check the result with grub-script-check /boot/grub/grub.cfg" ... I think it would be better to give [[GRUB/Tips and tricks#Manually creating grub.cfg]] more prominence and expand the fresh base there as required/wanted. Also some of the lengthy menu entry examples of [[GRUB#Automatically generating using .2Fetc.2Fgrub.d.2F40 custom and grub-mkconfig]] could be moved to a section there; they basically work/serve as examples for both (copy pasting into /etc/grub.d/40_custom or /boot/grub/grub.cfg). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:51, 27 June 2015 (UTC)<br />
<br />
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)<br />
<br />
::About (1), the inclusion on manually generating grub.cfg would be accompanied by (another, but needed) rewrite of the GRUB article. On (2), similar argument as in (1), and things like modules can be expanded on where needed. (3) It's not because you're not using grub-mkconfig, that you won't use tools such as ''grub-probe'' and ''grub-script-check'' to facilitate some tasks.<br />
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.<br />
::Note: I won't have much time to work on this (besides other tasks, I'd prefer to create [[fdisk]] first). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:48, 28 July 2015 (UTC)<br />
<br />
:Some work was done by Nl6720 recently to merge the manual section into the main page. I have a more fully featured rewrite at [[User:Eschwartz/Grub#Configuration]] and I think I'm more or less happy with it now. I'd like to consider it for merging, and we can then drop some/most/all of the overly specific examples that have accumulated for {{ic|/etc/grub.d/40_custom}} (which IMO add very little if anything).<br />
<br />
:Proposal: Drop the entire section [[GRUB#Custom grub.cfg]] and prepend my modifications before [[GRUB#Generated grub.cfg]]. Thoughts? -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:28, 8 January 2019 (UTC)<br />
<br />
::Must everything in [[GRUB#Custom grub.cfg]] be removed? Can't the examples from [[GRUB#Boot menu entries]] be integrated in [[User:Eschwartz/Grub#Examples]]? I find them useful. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:41, 8 January 2019 (UTC)<br />
<br />
:::I'm open to expanding the examples section, but I think many of them are needlessly ornate. It's redundant to, for example, include multiple full copy-paste definitions of menuentries to execute halt/reboot (which I don't see as particularly useful), or to chainload the specific .efi executable used for the UEFI Shell. I'm unsure how much Windows stuff might be valuable to merge, but I'm highly suspicious that most of it could be made smaller at least. Like, I have no idea why this stuff checks {{ic|$grub_platform}} ''per default''. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:54, 8 January 2019 (UTC)<br />
<br />
::::I don't really see a problem with having a lot of detailed examples, working examples should make it easier for the reader to understand the syntax.<br />
::::The {{ic|$grub_platform}} check in the Windows entries is most likely useless since AFAIK for Windows changing the boot mode is not that simple and I don't think it supports both at the same time. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:11, 8 January 2019 (UTC)<br />
<br />
:::::I'm myself looking at the expansion template in [https://wiki.archlinux.org/index.php?title=User:Eschwartz/Grub&oldid=563131#Examples], which end the new part. What I would do in that subsection is move and link the windows examples to the later detached examples section, replacing them with a very typical Linux one. For example, one with systemd hook boot parameters and one which crosslinks how to derive the correct lvm uuid. I agree it is still necessary to sieve the other existing examples, perhaps add a bullet list linking the most important ones. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:37, 13 January 2019 (UTC)<br />
<br />
::::::General examples section merged out of the grub-mkconfig subsection and linked in my examples section. Looking at options for further streamlining, suggestions welcome! -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 20:13, 13 January 2019 (UTC)<br />
<br />
::::Hi, first, the intro you wrote for the manual section is super, very clear already and enhances the upstream doc. IMO it would be totally helpful to merge in as a drop-in replacement for [[GRUB#Custom grub.cfg]] right away.<br />
::::At this point I'm not convinced it should prepend the [[GRUB#Generated grub.cfg]] as the first [[GRUB#Configuration]] section though. Let me give two examples:<br />
::::Look at [[User:Eschwartz/Grub#RAID]], it's inside the [[User:Eschwartz/Grub#Generate_the_configuration_file_using_grub-mkconfig|grub-mkconfig]] but actually describes grub-install and grub modules as well. I.e. the grub-mkconfig section mixes in the parts relevant for a first install. All this would have to be dis-entangled and crosslinked between both config sections first. What I am getting it is: Yes, a custom.cfg can be a slick three lines, but all that magic making them a working 50+ lines is shipped with supported defaults ([https://github.com/archlinux/svntogit-packages/blob/d60f7037b8122c9f3ef6b33787ed6b8d2101c706/trunk/0003-10_linux-detect-archlinux-initramfs.patch] [https://github.com/archlinux/svntogit-packages/commit/d60f7037b8122c9f3ef6b33787ed6b8d2101c706/trunk/grub.install]), because the major GRUB configuration task is to (1) install the boot loader image correctly to the disk and (2) have a initramfs with matching boot options for the machine setup based on configured defaults. Just one more example for this: nowhere in the article there is an explicit mention of an "-fallback" menu entry. --> Because the /etc/grub.d/ script handles it, sourcing /etc/default/grub <-- variables in that file are a lot explanation to cover for any meaningful manual examples... or not?<br />
::::So, to pre-pend the manual method as the first configuration section, there should first be a plan how to proceed with the more complex rest. My suggestion is to<br />
::::# drop-in your new part to start existing "3.2 [[GRUB#Custom grub.cfg]], <br />
::::# Separate the dispensable {{ic|menuentry{}}} examples into a new top-level "Examples" section (IMO ideally below current "4. [[GRUB#Using the command shell]]", because your new explanation is super helpful to lead over for command shell too), and remove/move/merge menuentries as appropriate (btw, I assume ordering [[User:Eschwartz/Grub#Multiple entries]] ff into "Encryption" is simply a glitch.). Meanwhile, <br />
::::# work-out where the "configuration from scratch" should end/what of the not-straight-forward three-line .cfg's are covered in which section.<br />
::::What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:29, 13 January 2019 (UTC)<br />
<br />
:::::First off, my rewrite and the main page have diverted a bit and I did not merge changes. I've now merged the current main page as-is with my rewrite dropped in where I suggested; this means there are now two sections for generating the custom grub.cfg, the latter of which is a boatload of custom.cfg things for grub-mkconfig to do like shutdown entries and stuff. Also, it is now much easier to grok the high-level organization of the page at a glance.<br />
:::::On the topic of things like RAID, would this be sufficient to include as references to how to write a filesystem path? I have no practical experience with RAID. Maybe we should merge this section into its own section as a child of [[User:Eschwartz/Grub#Configuration]].<br />
:::::If it doesn't provide a suitable explanation linked to writing your own grub.cfg, I'm hesitant to merge as-is, because it shouldn't depend on grub-mkconfig docs whether listed before or after. On an unrelated note, I really don't want to relegate this to second, because I want people to see what I believe the superior method first. :p I guess that could be fixed later, true...-- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 15:05, 13 January 2019 (UTC)<br />
<br />
::::::Yes, please don't start to merge as-is. If options are presented neutral, the order is secondary, exactly. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:37, 13 January 2019 (UTC)<br />
<br />
:::::::I'm wondering if the best option would be to simply drop it altogether. The handwritten cfg already describes the need to insmod the drivers for additional partitions, and this includes both grub and lvm. Make a new toplevel section #4, "Filesystem-specific issues", in between [[GRUB#Configuration]] and [[GRUB#Using the command shell]], which describes issues specific to ''installation'' in some given situation, and describe 1) the need to grub-install twice for RAID and 2) move [[GRUB#Encrypted /boot]] under that header.<br />
<br />
:::::::Maybe expand the mkconfig section to specify how to preload a module -- though I'm unsure why it doesn't autodetect the need, what is this huge script even useful for? :p -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 00:04, 15 January 2019 (UTC)<br />
<br />
::::::::Luckily I still kept my VMs with [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] and a slightly modified [[dm-crypt/Encrypting an entire system#LUKS on software RAID]]. Adding modules to {{ic|GRUB_PRELOAD_MODULES}} is not needed, grub-mkconfig detects them and puts them in {{ic|grub.cfg}} where needed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:55, 15 January 2019 (UTC)<br />
:::::::::I've implemented this in my rewrite as [[Special:Diff/563411]], do you agree with this? EDIT: reworked it several more times -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 17:22, 15 January 2019 (UTC)<br />
<br />
::::::::::I don't think that is what nl6720 (pls correct if wrong) implied: Unfortunately, not that simple. grub-mkconfig will detect its required modules according to what's running, but that does not mean you can leave the user alone with the determination. LUKS is likely worst case (~5 out of a 22 gcry_*.mod). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:34, 15 January 2019 (UTC)<br />
:::::::Actually, I suggest to stop this branch here as long as there is so much draft(ing)-in-progress. I know I started it too with making individual suggestions which Eschwartz integrated into his draft quickly, but at the same time my intention was also to reach a quick consensus to merge the new part over, so that reorganisation of existing other sections can be collaborated on step-by-step.<br />
:::::::@Eschwartz: how about you open a talk item on [[User talk:Eschwartz/Grub]] or similar, ideally with a short wip status, then leave a link here? I'm sure nl6720 and others will contribute there equally. I will too; in fact I have at least one suggestion I consider ''extremely'' relevant for the current draft. Later, i.e. as soon as you see sections of the draft ready to merge, it is time to pick up here again. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:34, 15 January 2019 (UTC)<br />
<br />
::::::::Done, further discussion will take place at [[User_talk:Eschwartz/Grub]] and I've copied over the two existing discussions. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 00:07, 16 January 2019 (UTC)<br />
<br />
== Custom keyboard layout ==<br />
<br />
Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found [http://lists.gnu.org/archive/html/grub-devel/2011-06/msg00008.html here], we need the ckbcomp script, which can be obtained from Debian console-setup package.<br />
<br />
Here's how I made things work:<br />
<br />
sudo mkdir /boot/grub/layouts<br />
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb<br />
<br />
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
<nowiki><br />
terminal_input at_keyboard<br />
keymap it<br />
</nowiki>}}<br />
<br />
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?<br />
<br />
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)<br />
<br />
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert <br />
<br />
{{hc|/etc/default/grub|<br />
<nowiki><br />
GRUB_TERMINAL_INPUT=at_keyboard<br />
</nowiki>}}<br />
<br />
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)<br />
<br />
:{{bc|<nowiki><br />
$ ckbcomp si | grub-mklayout -o si.gkb<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown keycode 0x79<br />
$ sudo mv si.gkb /boot/grub/<br />
</nowiki>}}<br />
<br />
:After that you add <br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
<nowiki><br />
insmod keylayouts<br />
keymap /boot/grub/si.gkb<br />
</nowiki>}}<br />
<br />
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with<br />
<br />
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)<br />
<br />
::The version of ckbcomp I got from Debian Squeeze kept giving this error:<br />
<br />
::{{bc|Unknown name $sun_t6_custom}}<br />
<br />
::The Ubuntu Precise version worked out of the box.<br />
<br />
::A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.<br />
<br />
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)<br />
<br />
:::This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.<br />
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:<br />
<br />
:::{{bc|<nowiki><br />
#!/bin/sh<br />
set -e<br />
# Include the GRUB helper library for grub-mkconfig.<br />
. /usr/share/grub/grub-mkconfig_lib<br />
KEYMAP_FILE=/boot/grub/bepo.gkb<br />
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then<br />
return 6--~~~~<br />
fi<br />
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")<br />
cat <<EOF<br />
insmod keylayouts<br />
keymap "${KEYMAP_FILE}"<br />
EOF<br />
</nowiki>}}<br />
<br />
:::So that the root partition is detected, loaded, and then the file is read within that partition.<br />
<br />
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)<br />
<br />
::::Is Glandos's solution to be used in addition to the Perl script, or is it a standalone solution? I get the vague sense that it is to be used as an additional step only when your /boot is located in its own partition. If someone can clarify this, I will add the above steps to the wiki and test them out, because I was looking for a solution to this same issue. [[User:Ingengnue|ingegnue]] ([[User talk:Ingengnue|talk]]) 09:39, 5 October 2014 (UTC)<br />
<br />
::::::There is a discussion further down the page about restructuring and cleaning up the GRUB article. I will make a suggestion to add a section like this in that discussion. This way we can see how much demand there is for it and get suggestions about where to put it and how to structure it. I will make a note of all of this information, and gather some more to build content for the section. Since I am moving this suggestion to the main discussion below, I move to close this. If anyone has any feedback regarding this please add it please. I move to close this so I may add it to the main section below. (All information has been saved in roder to reproduce if necessary.)<br />
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)<br />
<br />
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)<br />
<br />
:::::::This issue gets very important now that disk encryption becomes more popular and users have to type their passphrase during grub boot phase. I think there has to be something in the documentation for setting a locale in grub2. As for Ubuntu, it works out of the box and I'd love to have a clean howto to change the keymap in GRUB2. Guess what ? A complete guaranteed recipe is hard to find on the net. Those comments where very handy for me.<br />
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)<br />
<br />
::::::::There is, for UEFI: [[GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:10, 23 July 2016 (UTC)<br />
<br />
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard<br />
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...<br />
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464<br />
::::::::{{unsigned|04:11, 29 July 2017|Ryuta}}<br />
<br />
== Grub Shell normal linux booting ==<br />
<br />
A little improvement in GRUB Shell secction.<br />
When it is described the following example in [[GRUB#Using_the_rescue_console]]<br />
<br />
----<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
----<br />
<br />
I think it's imortant to say which partition is the root (/) and which is /boot, because it says sda5 and sda6, but it could be confusing. For example, to me, I don't really understand which is each one.<br />
Can someone explain it better? Thank you.<br />
<br />
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)<br />
<br />
:That is indeed confusing. I don't use GRUB, but I would guess that {{ic|1=set root=}} is setting the root of the ''console'' so that you can specify where the kernel/ramdisk is, which would be {{ic|/boot}}. Then when you boot linux you need to pass the usual kernel parameter {{ic|1=root=}} specifying where the linux filesystem is.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)<br />
<br />
<br />
:: Yes, I think is what you say. In facts, I tried to {{ic|1=set root=}} to my {{ic|/boot}} partition and then I specified the {{ic|1=root=}} for linux system, which is my partition mounted to {{ic|/ }} and it was OK. So I think we could explain it better in the wiki.<br />
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)<br />
<br />
== De-duplication of section header ==<br />
<br />
ATM there is a duplicate header anchor:<br />
* "Installation" links to the installation procedure for BIOS.<br />
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.<br />
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.<br />
<br />
In the same edition, I am also leaving a temporal manual anchor for "Installation_2", so as to minimize breaking links, considering the importance of this particular section of this particular wiki page.<br />
The reasoning for leaving a temporal manual anchor is that internal links are relatively easy to correct (right after renaming the header), whereas external links aren't.<br />
<br />
Examples of "external links" I am thinking about are:<br />
* Current / recent forum posts with links to the particular header / section.<br />
* Current / recent email threads / discussions with links to the particular header / section.<br />
* Other current / recent / relevant places / pages / sites with links to the particular header / section.<br />
The intention of this ''temporal'' manual anchor is to allow such potential recent links to still be valid (instead of leaving broken links), so users / readers / participants of conversations would still be able to make sense of such links and surrounding text / context, at least for some time.<br />
<br />
Not every single header's renaming deserves leaving a (temporal) manual anchor (i.e. in most cases, I wouldn't be leaving a manual anchor) but in this case I consider this wiki page and this section to be particularly important / popular / relevant for too many users.<br />
<br />
After some time, once current potential posts / emails containing links to the aforementioned section would be considered "old enough" (say, a month?), the manual anchor could be removed.<br />
<br />
When I'm done with the edition I'll add a comment here. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:53, 6 March 2017 (UTC)<br />
<br />
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)<br />
<br />
:: Duplication of section headers are a potential problem because they generate an '''automatic''' anchor with a trailing number ("Installation", "Installation_2", "Installation_3") which can _vary_ depending on the location / order of the header within the page. IOW, moving a section means that a link such as <nowiki>[[GRUB#Installation_2]]</nowiki> would point to a different section than what was originally intended.<br />
:: Anyway, the edition is done [https://wiki.archlinux.org/index.php?title=GRUB&diff=469963&oldid=468802] and I also corrected the corresponding internal links (in the main namespace).<br />
:: I intend to remove the manual anchor in some time (a month?). [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 17:31, 6 March 2017 (UTC)<br />
<br />
:::Do you plan to change the order of these sections? Otherwise you're just solving a fabricated problem - the headings are like this this since [https://wiki.archlinux.org/index.php?title=GRUB&oldid=351695 2014] when they were changed from something completely different, I don't think there was ever a change which just changed the order of two sections with the same heading. If such problem really appeared in practice, the best solution would be to rename the sections after swapping them, which would invalidate the old links. This way old links will be invalidated for no reason and probably the first person wondering why these headings are different might rename them back for coherence. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:08, 6 March 2017 (UTC)<br />
<br />
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names <br />
::::Renaming, moving, restructure... It happens all the time, with consequences. The fact that (some/many) editors don't notice / know / care about consequences of their editions doesn't mean that section header duplication is not a problem.<br />
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".<br />
::::OTOH, I ask for feedback at IRC #archlinux-wiki, I explain the reasoning in the Talk Page, I perform the edition, I fill in a relevant edition summary, I take care of the internal links that are affected by the edition, and I also minimize the potential impact on external links (which many wiki editors and maintainers don't even consider before performing editions). Then I come back to the Talk Page to inform about the changes that were performed. I think I've done the right thing, and I think my edition was adequate. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 08:07, 7 March 2017 (UTC)<br />
<br />
:::::I vote for reverting [https://wiki.archlinux.org/index.php?title=GRUB&curid=5984&diff=469963&oldid=468802], [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&curid=17198&diff=469964&oldid=467081] and [https://wiki.archlinux.org/index.php?title=Samsung_NP740U3L-L02US&diff=prev&oldid=469965]: having an "Installation" heading in the BIOS section, and "Install" in UEFI looks incoherent/unnatural, and as Lahwaacz points out, it just begs for somebody to fix it, which will happen sooner or later especially after removing the anchor (and hence breaking all its remaining backlinks), and even more especially if the article will really ever be radically restructured. In [[w:Help:Link#Duplicate_section_names]] the numbered suffix is presented as a feature, not a problem to work around, and IMO in general the least problematic way to edit the wiki is to do it in the way that the MediaWiki devs designed it. If one day we will have to swap "GRUB#Installation" links with "GRUB#Installation_2" we'll easily do it with a bot. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:48, 8 March 2017 (UTC)<br />
<br />
::::::The Wikipedia link is the description of the feature, not the problem. The fact that the feature exists doesn't mean that duplication of headers is recommended or welcomed; on the contrary.<br />
::::::Had I performed a simple renaming on both headers and nothing more (as most editors do all the time, without caring / understanding its consequences), we would not be wasting time with this. Possibly I should not even care to edit at all. I think this simple matter is not worth spending more time on it. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:25, 8 March 2017 (UTC)<br />
<br />
:::::::>"Possibly I should not even care to edit at all"<br />
:::::::What I don't understand is why apparently it's often impossible to accept disagreement and different opinions without taking them as personal affronts. Even if an edit is minor it doesn't mean that it's accepted just because of that, nonetheless nobody has reverted your edits yet, Lahwaacz hasn't even taken a definitive stance on the matter, can we please keep calm an reasonable, also considering the very minor nature of this issue?<br />
:::::::Instead of winging we could discuss compromises such as renaming those headings in neater ways, e.g. "BIOS installation" and "UEFI installation". As I said we can always use bots to change the backlinks.<br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)<br />
<br />
::::::::I'm not taking this personally (although I do value my own time), and I'm OK with disagreements. My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it. I could say more, but I'd rather focus on practical results and not waste more time.<br />
::::::::WRT a different renaming as a compromise, I am very much in favor. In fact, my initial idea was to rename both headers, "Installation on BIOS" and "Installation on UEFI" (or "Install on..") respectively. But renaming both headers in this way would mean that:<br />
*even more external links could be potentially affected;<br />
*many more internal links would need to be updated in comparison to renaming only one of the headers (and I was doing them manually, one by one);<br />
*there was a disagreement in IRC #archlinux-wiki about adding "... BIOS" and "... UEFI" in the headers when they are already subsections under the respective BIOS and UEFI sections.<br />
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.<br />
::::::::In such case, leaving a temporal manual anchor also for the first header would be a plus IMO. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:44, 8 March 2017 (UTC)<br />
<br />
:::::::::I agree with Kynikos that we should revert to the original, unproblematic state of headings until somebody comes up with a radical way to restructure the article's sections.<br />
:::::::::>"My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it."<br />
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.<br />
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"<br />
:::::::::FWIW I don't see any value in doing that. Internal links to the affected sections can be updated so quickly (with a bot) that it would be a waste of time, external links from resources that "don't care for updates" won't be updated anyway and external resources that absolutely need to preserve the temporal validity of the links should use [https://wiki.archlinux.org/index.php?title=GRUB&oldid=468802#Installation_2 permalinks]. Which alternative am I missing?<br />
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)<br />
<br />
::::::::::A simple reversion of those 3 edits was still my first choice, so I've jsut done it. I'm closing this discussion since apparently it didn't attract anybody else's interest: according to [[Help:Discussion]] it will still be visible at least for another week anyway. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:32, 9 March 2017 (UTC)<br />
<br />
== Dual Booting Windows. ==<br />
<br />
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR <br />
<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
}<br />
}}<br />
<br />
This probably works fine for most people. but if you run a BIOS-GPT setup to load GRUB and then want to load a BIOS-MBR windows setup on a separate drive. this wont work unless you remove the if statement. presumably the original author did not consider the fact that you could have both GPT and MBR in the same system on different drives.<br />
<br />
{{unsigned|18:46, 23 May 2017|Theholyduck}}<br />
<br />
:Perhaps what you indicated should be added in the same section or in another section regarding dual booting Windows. Have you tested exactly what you stated and you know it works when you remove the if statement?<br />
<br />
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
Has anyone besides the contributor got directly booting to work? [https://wiki.archlinux.org/index.php/GRUB#Windows_installed_in_BIOS-MBR_mode] I am the person who has added in the chainloading method because after some significant time I could not get the direct booting method working on my machine despite the fact that I do indeed have a BIOS-MBR configuration with Windows 10. I think we should have both methods because, as far as I know, the Arch Wiki has had the chainloading method available for a very long time and it always works. Further, Microsoft tends to do weird things with its files, so there's no telling when direct booting will or will not work depending on what Microsoft decides to do. By contrast, the chainloading method avoids this issue almost entirely.<br />
<br />
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:40, 25 October 2017 (UTC)Lo1<br />
<br />
== Graphics card maybe cause shell output some log ==<br />
<br />
My laptop has two card: intel (mesa intel uhd graphics 620) and NVDIAI 1050. And i use '''optimuse-manager''' to manage my card. Then I have install {{Pkg|intel-media-driver }}, {{Pkg|libvdpau}}, {{Pkg|xf86-video-intel}}, {{Pkg|libva-mesa-driver}}, {{Pkg|mesa-vdpau}}, {{Pkg|vulkan-intel}}, {{Pkg|vulkan-mesa-layers}}, and lib32*<br />
<br />
I install these packages for hardware acceleration.<br />
<br />
Now, I login KDE through Intel Card, and run '''grub-mkconfig -o /boot/grub/grub.cfg''', some information were be given:<br />
<br />
Generating grub configuration file ...<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9880: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9906: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9930: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9955: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 9979: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10074: /usr/bin/grub-probe<br />
Found linux image: /boot/vmlinuz-linux<br />
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10167: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10192: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10216: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10241: /usr/bin/grub-probe<br />
Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe<br />
File descriptor 13 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe<br />
File descriptor 19 (/dev/dri/renderD128) leaked on vgs invocation. Parent PID 10425: /usr/bin/grub-probe<br />
Found Windows Boot Manager on /dev/nvme0n1p2@/EFI/Microsoft/Boot/bootmgfw.efi<br />
done<br />
<br />
This situation have happended some times beform today.<br />
<br />
You see, so much log were given me, I watch this: '''/dev/dri/renderD128''', I guess it maybe caused by card driver. So I relogin KDE thourgh NVIDIA card, rerun this command, there is nothing happend, no so much log.<br />
<br />
So, I guess hardware acceleration driver maybe cause shell output more log. But I cannot whether this information should write in this wiki.<br />
<br />
[[User:Dragonwater|Dragonwater]] ([[User talk:Dragonwater|talk]]) 13:15, 27 July 2020 (UTC)<br />
<br />
== Add information how to generate the bootable files ==<br />
<br />
After the creation of both BIOS and UEFI partitions (probably in the subsection '''Installation''') one has to be sure that bootable images are actually present in ''/boot'' before running ''grub-mkconfig'' (I'm not sure that that is needed for UEFI though, because an ''.efi'' is generated by ''grub'', but I think it's needed too). In BIOS/Legacy setup if the ''/boot'' contains only ''grub/'' subfolder (not kernel images), grub loads only the ''command shell'', not the OS.<br />
<br />
I suggest adding a line about that and that they can be generated with<br />
<br />
pacman -S<br />
<br />
This seems to be a small duplication, but I think the easiest would be to add this line both to BIOS and UEFI sections. I also remember that I already suggested that on EFISTUB page.<br />
<br />
Another option would be to create a "Generate bootable images (?)" page and link to there in every place. But I think that for a short instruction a small insertion is better than a whole reference.<br />
<br />
[[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 16:37, 16 November 2020 (UTC)<br />
:Nothing about this makes sense. You deleted your kernel, then expect the docs to know that you screwed up? [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 14:34, 17 November 2020 (UTC)<br />
<br />
::Everything about this makes sense. You have to install a kernel in between "create the partition" and "install GRUB". The page should be self-consistent, and not assume you are using a recipe from a page somewhere else. [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 14:54, 17 November 2020 (UTC)<br />
:::If you're not using the official Installation Guide, you're not on Arch and are on your own anyway. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 14:58, 17 November 2020 (UTC)<br />
::::GRUB page is not a subpage of "Installation Guide", is it? A user may install and change their partitions and files during or after Arch installation. Do you propose to repeat the installation process if you format the boot partition? [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 15:02, 17 November 2020 (UTC)<br />
:::::I propose that if you format the boot partition, you have some idea what you're doing. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 15:05, 17 November 2020 (UTC)<br />
::::::I did that, and I share my findings to improve this article. If you have other arguments against or for this edit, feel free to write them. [[User:Ynikitenko|Ynikitenko]] ([[User talk:Ynikitenko|talk]]) 15:42, 17 November 2020 (UTC)<br />
<br />
== grub 2.06 "error: verification requested but nobody cares" ==<br />
<br />
When using boot encryption with grub 2.06, error "verification requested but nobody cares" can be worked around by using method described on https://wejn.org/2021/09/fixing-grub-verification-requested-nobody-cares. <br />
<br />
In short, after issuing "grub-install --target=x86_64-efi ..." and before signing the image, do <br />
sed -i 's/SecureBoot/SecureB00t/' /efi/EFI/GRUB/grubx64.efi<br />
<br />
I've added a comment to https://aur.archlinux.org/packages/cryptboot/ if anyoe is usign this tool.<br />
[[User:Dominik|Dominik]] ([[User talk:Dominik|talk]]) 15:06, 7 January 2022 (UTC)<br />
<br />
:I fixed it by doing this<br />
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB --modules="normal test efi_gop efi_uga search echo linux all_video gfxmenu gfxterm_background gfxterm_menu gfxterm loadenv configfile tpm" --disable-shim-lock<br />
:I don't think the solution listed here is secure? [[User:Afader|Afader]] ([[User talk:Afader|talk]]) 23:13, 26 January 2022 (UTC)<br />
<br />
== Highlight importance of adding or removing '/boot' from path in 'initrd=..' lines in configuration ==<br />
<br />
Many of the {{ic|initrd}} lines in grub configuration consider boot as a directory in root, But the note on changing the line to remove the {{ic|/boot}} in the case of separate {{ic|/boot}} partitions should be mentioned more strictly and widely as otherwise users will end up with unbootable systems with '''... not found''' errors.</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=724130User talk:Scimmia2022-03-24T12:23:35Z<p>RaZorr: Changes in grub regarding addition of '/boot' to configuration files.</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned? Ic ouldn't find it.</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User_talk:Scimmia&diff=724129User talk:Scimmia2022-03-24T12:22:53Z<p>RaZorr: /* Changes in grub regarding addition of '/boot' to configuration files. */ new section</p>
<hr />
<div>== Changes in grub regarding addition of '/boot' to configuration files. ==<br />
<br />
When you reverted my changes, you mentioned<br />
"This isn't a 'keyword', it's part of the path, which is relative to the volume it's on. This is already explained above when set root= is mentioned."<br />
I agree with the correction on the '''keyword''' part but where is the '''explanation''' you mentioned?</div>RaZorrhttps://wiki.archlinux.org/index.php?title=GRUB&diff=724127GRUB2022-03-24T12:03:45Z<p>RaZorr: Add note on '/boot' keyword in grub config files : part 1</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[Category:GNU]]<br />
[[de:GRUB]]<br />
[[es:GRUB]]<br />
[[fa:گراب]]<br />
[[fr:GRUB]]<br />
[[ja:GRUB]]<br />
[[pt:GRUB]]<br />
[[ru:GRUB]]<br />
[[zh-hans:GRUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|GRUB/EFI examples}}<br />
{{Related|GRUB/Tips and tricks}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) is a [[boot loader]]. The current GRUB is also referred to as '''GRUB 2'''. The original GRUB, or [[GRUB Legacy]], corresponds to versions 0.9x. This page exclusively describes GRUB 2.<br />
<br />
{{Note|In the entire article {{ic|''esp''}} denotes the mountpoint of the [[EFI system partition]] aka ESP.}}<br />
<br />
== BIOS systems ==<br />
<br />
=== GUID Partition Table (GPT) specific instructions ===<br />
<br />
On a BIOS/[[GPT]] configuration, a [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note|<br />
* Before attempting this method keep in mind that not all systems will be able to support this partitioning scheme. Read more on [[Partitioning#GUID Partition Table]].<br />
* The BIOS boot partition is only needed by GRUB on a BIOS/GPT setup. On a BIOS/MBR setup, GRUB uses the post-MBR gap for the embedding the {{ic|core.img}}. On GPT, however, there is no guaranteed unused space before the first partition.<br />
* For [[UEFI]] systems this extra partition is not required, since no embedding of boot sectors takes place in that case. However, UEFI systems still require an [[EFI system partition]].<br />
}}<br />
<br />
Create a mebibyte partition ({{ic|1=+1M}} with ''fdisk'' or ''gdisk'') on the disk with no file system and with partition type GUID {{ic|21686148-6449-6E6F-744E-656564454649}}.<br />
<br />
* Select partition type {{ic|BIOS boot}} for [[fdisk]].<br />
* Select partition type code {{ic|ef02}} for [[gdisk]].<br />
* For [[parted]] set/activate the flag {{ic|bios_grub}} on the partition.<br />
<br />
This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the bootloader as per the instructions below.<br />
<br />
The space before the first partition can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In ''fdisk'' or ''gdisk'' create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.<br />
<br />
=== Master Boot Record (MBR) specific instructions ===<br />
<br />
Usually the post-MBR gap (after the 512 byte [[MBR]] region and before the start of the first partition) in many MBR partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{Bug|24103}}). It is advisable to use a partitioning tool that supports 1 MiB [[Partitioning#Partition alignment|partition alignment]] to obtain this space as well as to satisfy other non-512-byte-sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|grub}} package. (It will replace {{AUR|grub-legacy}} if that is already installed.) Then do:<br />
<br />
# grub-install --target=i386-pc ''/dev/sdX''<br />
<br />
where {{ic|''/dev/sdX''}} is the '''disk''' ('''not a partition''') where GRUB is to be installed. For example {{ic|/dev/sda}} or {{ic|/dev/nvme0n1}}, or {{ic|/dev/mmcblk0}}. See [[Device file#Block device names]] for a description of the block device naming scheme.<br />
<br />
Now you must [[#Generate the main configuration file|generate the main configuration file]].<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
{{Tip|See [[GRUB/Tips and tricks#Alternative installation methods]] for other ways to install GRUB, such as to a USB stick.}}<br />
<br />
See {{man|8|grub-install}} and [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] for more details on the {{ic|grub-install}} command.<br />
<br />
== UEFI systems ==<br />
<br />
{{Note|<br />
* It is recommended to read and understand the [[Unified Extensible Firmware Interface]], [[Partitioning#GUID Partition Table]] and [[Arch boot process#Under UEFI]] pages.<br />
* When installing to use UEFI it is important to boot the installation media in UEFI mode, otherwise ''efibootmgr'' will not be able to add the GRUB UEFI boot entry. Installing to the [[#Default/fallback boot path|fallback boot path]] will still work even in BIOS mode since it does not touch the NVRAM.<br />
* To boot from a disk using UEFI, an EFI system partition is required. Follow [[EFI system partition#Check for an existing partition]] to find out if you have one already, otherwise you need to create it.<br />
}}<br />
<br />
=== Installation ===<br />
<br />
{{Note|<br />
* UEFI firmwares are not implemented consistently across manufacturers. The procedure described below is intended to work on a wide range of UEFI systems but those experiencing problems despite applying this method are encouraged to share detailed information, and if possible the workarounds found, for their hardware-specific case. A [[GRUB/EFI examples]] article has been provided for such cases.<br />
* The section assumes you are installing GRUB for x86_64 systems. For IA32 (32-bit) UEFI systems (not to be confused with 32-bit CPUs), replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
}}<br />
<br />
First, [[install]] the packages {{Pkg|grub}} and {{Pkg|efibootmgr}}: ''GRUB'' is the bootloader while ''efibootmgr'' is used by the GRUB installation script to write boot entries to NVRAM. <br />
<br />
Then follow the below steps to install GRUB to your disk:<br />
<br />
# [[EFI system partition#Mount the partition|Mount the EFI system partition]] and in the remainder of this section, substitute {{ic|''esp''}} with its mount point.<br />
# Choose a bootloader identifier, here named {{ic|GRUB}}. A directory of that name will be created in {{ic|''esp''/EFI/}} to store the EFI binary and this is the name that will appear in the UEFI boot menu to identify the GRUB boot entry.<br />
# Execute the following command to install the GRUB EFI application {{ic|grubx64.efi}} to {{ic|''esp''/EFI/GRUB/}} and install its modules to {{ic|/boot/grub/x86_64-efi/}}. {{Note|Make sure to install the packages and run the {{ic|grub-install}} command from the system in which GRUB will be installed as the boot loader. That means if you are booting from the live installation environment, you need to be inside the chroot when running {{ic|grub-install}}. If for some reason it is necessary to run {{ic|grub-install}} from outside of the installed system, append the {{ic|1=--boot-directory=}} option with the path to the mounted {{ic|/boot}} directory, e.g {{ic|1=--boot-directory=/mnt/boot}}.}} {{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}}<br />
<br />
After the above installation completed, the main GRUB directory is located at {{ic|/boot/grub/}}. Note that {{ic|grub-install}} also tries to [[#Create a GRUB entry in the firmware boot manager|create an entry in the firmware boot manager]], named {{ic|GRUB}} in the above example – this will, however, fail if your boot entries are full; use [[efibootmgr]] to remove unnecessary entries.<br />
<br />
Remember to [[#Generate the main configuration file]] after finalizing the configuration.<br />
<br />
{{Tip|If you use the option {{ic|--removable}} then GRUB will be installed to {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} (or {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} for the {{ic|i386-efi}} target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows.}}<br />
<br />
{{Note|<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI, {{ic|--efi-directory}} replaces {{ic|--root-directory}} which is deprecated. <br />
* You might note the absence of a ''device_path'' option (e.g.: {{ic|/dev/sda}}) in the {{ic|grub-install}} command. In fact any ''device_path'' provided will be ignored by the GRUB UEFI install script. Indeed, UEFI bootloaders do not use a MBR bootcode or partition boot sector at all.<br />
}}<br />
<br />
See [[#UEFI|UEFI troubleshooting]] in case of problems. Additionally see [[GRUB/Tips and tricks#UEFI further reading]].<br />
<br />
== Configuration ==<br />
<br />
On an installed system, GRUB loads the {{ic|/boot/grub/grub.cfg}} configuration file each boot. You can follow [[#Generated grub.cfg]] for using a tool, or [[#Custom grub.cfg]] for a manual creation.<br />
<br />
=== Generated grub.cfg ===<br />
<br />
This section only covers editing the {{ic|/etc/default/grub}} configuration file. See [[GRUB/Tips and tricks]] for more information.<br />
<br />
{{Note|Remember to always [[#Generate the main configuration file|generate the main configuration file]] after making changes to {{ic|/etc/default/grub}} and/or files in {{ic|/etc/grub.d/}}.}}<br />
<br />
==== Generate the main configuration file ====<br />
<br />
After the installation, the main configuration file {{ic|/boot/grub/grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}.<br />
<br />
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* The default file path is {{ic|/boot/grub/grub.cfg}}, not {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a [[chroot]] or [[systemd-nspawn]] container, you might notice that it does not work: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}. In this case, try using [[arch-chroot]] as described in the [https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 BBS post].<br />
* If you are installing GRUB in chroot environment using LVM and the {{ic|grub-mkconfig}} hangs indefinitely, see [[#Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds]].<br />
}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|/boot/grub/grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
By default the generation scripts automatically add menu entries for all installed Arch Linux [[kernel]]s to the generated configuration.<br />
<br />
{{Tip|<br />
* After installing or removing a [[kernel]], you just need to re-run the above ''grub-mkconfig'' command.<br />
* For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[GRUB/Tips and tricks#Multiple entries]].<br />
}}<br />
<br />
To automatically add entries for other installed operating systems, see [[#Detecting other operating systems]].<br />
<br />
You can add additional custom menu entries by editing {{ic|/etc/grub.d/40_custom}} and re-generating {{ic|/boot/grub/grub.cfg}}. Or you can create {{ic|/boot/grub/custom.cfg}} and add them there. Changes to {{ic|/boot/grub/custom.cfg}} do not require re-running ''grub-mkconfig'', since {{ic|/etc/grub.d/41_custom}} adds the necessary {{ic|source}} statement to the generated configuration file.<br />
<br />
{{Tip|{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/''nn''_custom}}, where {{ic|''nn''}} defines the precedence, indicating the order the script is executed. The order scripts are executed determine the placement in the GRUB boot menu. {{ic|''nn''}} should be greater than {{ic|06}} to ensure necessary scripts are executed first.}}<br />
<br />
See [[#Boot menu entry examples]] for custom menu entry examples.<br />
<br />
==== Detecting other operating systems ====<br />
<br />
To have ''grub-mkconfig'' search for other installed systems and automatically add them to the menu, [[install]] the {{Pkg|os-prober}} package and [[mount]] the partitions from which the other systems boot. Then re-run ''grub-mkconfig''. If you get the following output: {{ic|Warning: os-prober will not be executed to detect other bootable partitions}} then edit {{ic|/etc/default/grub}} and add/uncomment:<br />
GRUB_DISABLE_OS_PROBER=false<br />
Then try again.<br />
<br />
{{Note| <br />
* The exact mount point does not matter, ''os-prober'' reads the {{ic|mtab}} to identify places to search for bootable entries.<br />
* Remember to mount the partitions each time you run ''grub-mkconfig'' in order to include the other operating systems every time.<br />
}}<br />
<br />
{{Tip|You might also want GRUB to remember the last chosen boot entry, see [[GRUB/Tips and tricks#Recall previous entry]].}}<br />
<br />
===== MS Windows =====<br />
<br />
For Windows installed in UEFI mode, make sure the [[EFI system partition]] containing the Windows Boot Manager ({{ic|bootmgfw.efi}}) is mounted. Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
For Windows installed in BIOS mode, mount the Windows ''system partition'' (its [[Persistent block device naming#by-label|file system label]] should be {{ic|System Reserved}} or {{ic|SYSTEM}}). Run {{ic|os-prober}} as root to detect and generate an entry for it.<br />
<br />
{{Note|For Windows installed in BIOS mode:<br />
<br />
* NTFS partitions may not always be detected when mounted with the default Linux drivers. If GRUB is not detecting it, try installing [[NTFS-3G]] and remounting.<br />
{{Out of date|Since Windows 7, {{ic|bootmgr}} is placed in the [[Wikipedia:System partition and boot partition#Microsoft definition|system partition]] which is not encrypted.}}<br />
* Encrypted Windows partitions may need to be decrypted before mounting. For BitLocker, this can be done with [[cryptsetup]] or {{AUR|dislocker}}. This should be sufficient for {{Pkg|os-prober}} to add the correct entry.<br />
}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation.<br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=''uuid-of-swap-partition'' quiet"}} where {{ic|''uuid-of-swap-partition''}} is the [[UUID]] of your swap partition to enable resume after [[hibernation]]. This would generate a recovery boot entry without the resume and without {{ic|quiet}} suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.<br />
<br />
By default ''grub-mkconfig'' determines the [[UUID]] of the root filesystem for the configuration. To disable this, uncomment {{ic|1=GRUB_DISABLE_LINUX_UUID=true}}.<br />
<br />
For generating the GRUB recovery entry you have to ensure that {{ic|GRUB_DISABLE_RECOVERY}} is not set to {{ic|true}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
==== LVM ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|lvm}} module, specifying it in {{ic|GRUB_PRELOAD_MODULES}} is not required. Move warning to [[#Installation]] & [[#Installation_2]] or create a [[Help:Style#"Known issues" section|Known issues section]] and document it there.}}<br />
<br />
{{Warning|GRUB does not support thin-provisioned logical volumes.}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}} or {{ic|/}} root partition, make sure that the {{ic|lvm}} module is preloaded:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... lvm"<br />
}}<br />
<br />
==== RAID ====<br />
<br />
{{Merge|#Installation|grub-mkconfig is capable of detecting that it needs the {{ic|mdraid09}} and/or {{ic|mdraid1x}} modules, specifying them in {{ic|GRUB_PRELOAD_MODULES}} is not required. Summarize the double grub-install in a note and move it to [[#Installation]]; move {{ic|set root}} stuff to [[#Custom grub.cfg]].}}<br />
<br />
GRUB provides convenient handling of [[RAID]] volumes. You need to load GRUB modules {{ic|mdraid09}} or {{ic|mdraid1x}} to allow you to address the volume natively:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="... mdraid09 mdraid1x"<br />
}}<br />
<br />
For example, {{ic|/dev/md0}} becomes:<br />
<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on BIOS systems, simply run ''grub-install'' on both of the drives, such as:<br />
<br />
# grub-install --target=i386-pc --debug /dev/sda<br />
# grub-install --target=i386-pc --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
{{Note|GRUB supports booting from [[Btrfs]] RAID 0/1/10, but ''not'' RAID 5/6. You may use [[mdadm]] for RAID 5/6, which is supported by GRUB.}}<br />
<br />
==== Encrypted /boot ====<br />
<br />
GRUB also has special support for booting with an encrypted {{ic|/boot}}. This is done by unlocking a [[LUKS]] blockdevice in order to read its configuration and load any [[initramfs]] and [[kernel]] from it. This option tries to solve the issue of having an [[dm-crypt/Specialties#Securing the unencrypted_boot partition|unencrypted boot partition]].<br />
<br />
{{Tip|{{ic|/boot}} is '''not''' required to be kept in a separate partition; it may also stay under the system's root {{ic|/}} directory tree.}}<br />
<br />
{{Warning|GRUB 2.06 has limited support for LUKS2. See the [[#LUKS2]] section below for details.}}<br />
<br />
To enable this feature encrypt the partition with {{ic|/boot}} residing on it using [[LUKS]] as normal. Then add the following option to {{ic|/etc/default/grub}}:<br />
<br />
{{hc|/etc/default/grub|output=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
This option is used by grub-install to generate the grub {{ic|core.img}}, so make sure to [[#Installation|install grub]] after modifying this option.<br />
<br />
Without further changes you will be prompted twice for a passphrase: the first for GRUB to unlock the {{ic|/boot}} mount point in early boot, the second to unlock the root filesystem itself as implemented by the initramfs. You can use a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]] to avoid this.<br />
<br />
{{Warning|<br />
* If you want to [[#Generate the main configuration file|generate the main configuration file]], make sure that {{ic|/boot}} is mounted.<br />
* In order to perform system updates involving the {{ic|/boot}} mount point, ensure that the encrypted {{ic|/boot}} is unlocked and mounted before performing an update. With a separate {{ic|/boot}} partition, this may be accomplished automatically on boot by using [[crypttab]] with a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]].<br />
}}<br />
<br />
{{Note|<br />
* If you use a special keymap, a default GRUB installation will not know it. This is relevant for how to enter the passphrase to unlock the LUKS blockdevice. See [[GRUB/Tips and tricks#Manual configuration of core image for early boot]].<br />
* If you experience issues getting the prompt for a password to display (errors regarding cryptouuid, cryptodisk, or "device not found"), try reinstalling GRUB and appending {{ic|1=--modules="part_gpt part_msdos"}} to the end of your {{ic|grub-install}} command.<br />
}}<br />
<br />
{{Tip|1=You can use [https://bbs.archlinux.org/viewtopic.php?id=234607 pacman hooks] to automount your {{ic|/boot}} when upgrades need to access related files.}}<br />
<br />
===== LUKS2 =====<br />
<br />
GRUB 2.06 has limited support for LUKS2. See [https://savannah.gnu.org/bugs/?55093 GRUB bug #55093].<br />
{{Tip|1=You can use {{AUR|grub-improved-luks2-git}} that has been patched for LUKS2 support.}}<br />
<br />
* Argon2id (''cryptsetup'' default) and Argon2i PBKDFs are not supported, only PBKDF2 is.<br />
* {{ic|grub-install}} does not support creating a core image that could be used for unlocking LUKS2. See the comments below or on {{AUR|grub-git}} for a workaround.<br />
<br />
Use {{ic|grub-install}} as described in the [[#Installation]] section. However, the generated EFI binary does not support LUKS2 and needs to be replaced.<br />
<br />
Create {{ic|grub-pre.cfg}}, replace {{ic|/dev/nvme0n1p2}} accordingly. The output is the UUID of the encrypted partition without hyphens.<br />
<br />
{{bc|<br />
# replace ... by the output of: lsblk -no TYPE,UUID ''/dev/nvme0n1p2''<nowiki> | awk '$1=="part"{print $2}' | tr -d -<br />
set crypto_uuid=...<br />
cryptomount -u $crypto_uuid<br />
# Replace crypto0 by lvm/NameOfVolume if you use LVM<br />
set root=crypto0<br />
set prefix=($root)/boot/grub<br />
insmod normal<br />
normal<br />
</nowiki>}}<br />
<br />
Add {{ic|lvm}} if you use [[LVM]]. Replace {{ic|ext2}} by {{ic|btrfs}} if needed:<br />
<br />
$ grub-mkimage -p /boot/grub -O x86_64-efi -c grub-pre.cfg -o /tmp/grubx64.efi luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 gcry_sha256 ext2<br />
<br />
Copy to ESP:<br />
<br />
# install -v /tmp/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi<br />
<br />
If you enter an invalid passphrase during boot and end up at the GRUB rescue shell, try {{ic|cryptomount -a}} to mount all (hopefully only one) encrypted partitions or use {{ic|cryptomount -u $crypto_uuid}} to mount a specific one. Then proceed with {{ic|insmod normal}} and {{ic|normal}} as usual.<br />
<br />
If you enter a correct passphrase, but an {{ic|Invalid passphrase}} error is immediately returned, make sure that the right cryptographic modules are specified. Use {{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} and check whether the hash function (SHA-256, SHA-512) matches the modules ({{ic|gcry_sha256}}, {{ic|gcry_sha512}}) installed and the PBKDF algorithm is pbkdf2. The hash and PBDKDF algorithms can be changed for existing keys by using {{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}}. Under normal circumstances it should take a few seconds before the passphrase is processed.<br />
<br />
=== Custom grub.cfg ===<br />
<br />
{{Expansion|Add instructions on how to write a custom {{ic|/boot/grub/grub.cfg}}. See [[User:Eschwartz/Grub]] for a proposed draft.|section=Manually generate grub.cfg}}<br />
<br />
This section describes the manual creation of GRUB boot entries in {{ic|/boot/grub/grub.cfg}} instead of relying on ''grub-mkconfig''.<br />
<br />
A basic GRUB config file uses the following options:<br />
<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
==== Boot menu entry examples ====<br />
<br />
{{Tip|These boot entries can also be used when using a {{ic|/boot/grub/grub.cfg}} generated by ''grub-mkconfig''. Add them to {{ic|/etc/grub.d/40_custom}} and [[#Generate the main configuration file|re-generate the main configuration file]] or add them to {{ic|/boot/grub/custom.cfg}}.}}<br />
<br />
For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[GRUB/Tips and tricks#Multiple entries]].<br />
<br />
For [[Archiso]] and [[Archboot]] boot menu entries see [[Multiboot USB drive#Boot entries]].<br />
<br />
===== GRUB commands =====<br />
<br />
====== "Shutdown" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
}}<br />
<br />
====== "Restart" menu entry ======<br />
<br />
{{bc|<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}<br />
}}<br />
<br />
====== "UEFI Firmware Settings" menu entry ======<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {<br />
fwsetup<br />
}<br />
fi<br />
}}<br />
<br />
===== EFI binaries =====<br />
<br />
When launched in UEFI mode, GRUB can chainload other EFI binaries.<br />
<br />
{{Tip|1=To show these menu entries only when GRUB is launched in UEFI mode, enclose them in the following {{ic|if}} statement:<br />
<br />
{{bc|1=<br />
if [ ${grub_platform} == "efi" ]; then<br />
''place UEFI-only menu entries here''<br />
fi<br />
}}<br />
<br />
}}<br />
<br />
====== UEFI Shell ======<br />
<br />
You can launch [[Unified Extensible Firmware Interface#UEFI Shell|UEFI Shell]] by placing it in the root of the [[EFI system partition]] and adding this menu entry:<br />
<br />
{{bc|1=<br />
menuentry "UEFI Shell" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /shellx64.efi<br />
chainloader /shellx64.efi<br />
}<br />
}}<br />
<br />
====== gdisk ======<br />
<br />
Download the [[gdisk#gdisk EFI application|gdisk EFI application]] and copy {{ic|gdisk_x64.efi}} to {{ic|''esp''/EFI/tools/}}.<br />
<br />
{{bc|1=<br />
menuentry "gdisk" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi<br />
chainloader /EFI/tools/gdisk_x64.efi<br />
}<br />
}}<br />
<br />
====== Chainloading a unified kernel image ======<br />
<br />
If you have a [[unified kernel image]] generated from following [[Secure Boot]] or other means, you can add it to the boot menu. For example:<br />
<br />
{{bc|1=<br />
menuentry "Arch Linux" {<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''<br />
chainloader /EFI/Linux/Arch-linux.efi<br />
}<br />
}}<br />
<br />
===== Dual-booting =====<br />
<br />
====== GNU/Linux ======<br />
<br />
Assuming that the other distribution is on partition {{ic|sda2}}:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
Alternatively let GRUB search for the right partition by UUID or file system label:<br />
<br />
{{bc|1=<br />
menuentry "Other Linux" {<br />
# assuming that UUID is 763A-9CB6<br />
search --no-floppy --set=root --fs-uuid 763A-9CB6<br />
<br />
# search by label OTHER_LINUX (make sure that partition label is unambiguous)<br />
#search --no-floppy --set=root --label OTHER_LINUX<br />
<br />
linux /boot/vmlinuz (add other options here as required, for example: root=UUID=763A-9CB6)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
}}<br />
<br />
If the other distribution has already a valid {{ic|/boot}} folder with installed GRUB, {{ic|grub.cfg}}, kernel and initramfs, GRUB can be instructed to load these other {{ic|grub.cfg}} files on-the-fly during boot. For example, for {{ic|hd0}} and the fourth GPT partition:<br />
<br />
{{bc|1=<br />
menuentry "configfile hd0,gpt4" {<br />
insmod part_gpt<br />
insmod btrfs<br />
insmod ext2<br />
set root='hd0,gpt4'<br />
configfile /boot/grub/grub.cfg<br />
}<br />
}}<br />
<br />
When choosing this entry, GRUB loads the {{ic|grub.cfg}} file from the other volume and displays that menu. Any environment variable changes made by the commands in file will not be preserved after {{ic|configfile}} returns. Press {{ic|Esc}} to return to the first GRUB menu.<br />
<br />
{{Tip|As usual {{ic|/boot}} keyword is '''not''' required to be kept in the above configurations if boot is a separate partition; it may also stay under the system's root {{ic|/}} directory tree.}}<br />
<br />
====== Windows installed in UEFI/GPT mode ======<br />
<br />
This mode determines where the Windows bootloader resides and chain-loads it after GRUB when the menu entry is selected. The main task here is finding the EFI system partition and running the bootloader from it.<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the UEFI bitness. It will not work in BIOS installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] for more information.}}<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod chain<br />
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi<br />
}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands.<br />
<br />
The {{ic|$fs_uuid}} command determines the UUID of the EFI system partition:<br />
<br />
{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
1ce5-7f28<br />
}}<br />
<br />
Alternatively one can run {{ic|blkid}} (as root) and read the UUID of the EFI system partition from there.<br />
<br />
The {{ic|$hints_string}} command will determine the location of the EFI system partition, in this case harddrive 0:<br />
<br />
{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|''esp''}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
====== Windows installed in BIOS/MBR mode ======<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading chainloading] of partition boot sector is no longer required to boot Windows in a BIOS/MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually {{ic|C:}}). The system partition's [[Persistent block device naming#by-label|filesystem label]] is {{ic|System Reserved}} or {{ic|SYSTEM}} and the partition is only about 100 to 549 MiB in size. See [[Wikipedia:System partition and boot partition]] for more information.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of {{ic|hd0,msdos1}}.<br />
<br />
{{Note|These menu entries will work only in BIOS boot mode. It will not work in UEFI installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] .}}<br />
<br />
In both examples {{ic|''XXXXXXXXXXXXXXXX''}} is the filesystem UUID which can be found with command {{ic|lsblk --fs}}.<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /bootmgr<br />
}<br />
fi<br />
}}<br />
<br />
For Windows XP:<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod ntldr<br />
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''<br />
ntldr /ntldr<br />
}<br />
fi<br />
}}<br />
<br />
{{Note|In some cases, GRUB may be installed without a clean Windows 8, in which case you cannot boot Windows without having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it by going to Windows Recovery Console ({{ic|cmd.exe}} from install disk) and executing:<br />
<br />
X:\> bootrec.exe /fixboot<br />
X:\> bootrec.exe /RebuildBcd<br />
<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.<br />
Or you can use Boot Repair function in the Troubleshooting menu - it will not wipe out GRUB but will fix most errors.<br />
Also you would better keep plugged in both the target hard drive and your bootable device '''ONLY'''. Windows usually fails to repair boot information if any other devices are connected.<br />
}}<br />
<br />
===== Using labels =====<br />
<br />
It is possible to use file system labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, [[Persistent block device naming#by-label|make sure your file system has a label]].<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub/}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub><br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the start of a partitioned disk (MBR), at the start of a partition or a partitionless disk (VBR), or as an EFI binary in the case of UEFI.<br />
<br />
==== Chainloading a partition's VBR ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partition of the first hard disk,<br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk's MBR or a partitionless disk's VBR ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod fat<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
{{ic|insmod fat}} is used for loading the FAT file system module for accessing the Windows bootloader on the EFI system partition.<br />
{{ic|(hd0,gpt4)}} or {{ic|/dev/sda4}} is the EFI system partition in this example.<br />
The entry in the {{ic|chainloader}} line specifies the path of the ''.efi'' file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[#Using the rescue console]]<br />
<br />
=== Using the rescue console ===<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hd''X'',''Y'')/boot/grub<br />
<br />
where {{ic|''X''}} is the physical drive number and {{ic|''Y''}} is the partition number.<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path (i.e. type {{ic|1=set prefix=(hd''X'',''Y'')/grub}}).}}<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
or simply<br />
<br />
grub rescue> insmod linux<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar.<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using UEFI), again change the lines accordingly:<br />
<br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hd''X'',''Y'')/vmlinuz-linux root=/dev/sda6<br />
initrd (hd''X'',''Y'')/initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== GRUB removal ==<br />
<br />
{{Expansion|Migrating from BIOS booting to UEFI is not the only case where GRUB could be removed. Section needs to either cover how to remove GRUB installed for UEFI booting or it should be removed altogether as too trivial.}}<br />
In general, in order to remove ''grub'', one has to do the installation steps in reverse order. Perhaps cleaning any left over at the end. However, before doing anything, one has to decide if, and how, the machine will boot after the removal. Assuming one removes ''grub'' because he would like to use another boot loader, a safe, though a bit difficult, method is to make sure the other boot loader is working before removing ''grub''.<br />
<br />
In any case, even when removing ''grub'' before installing another boot loader, for the UEFI case, run<br />
$ efibootmgr<br />
And verify the other boot loader is listed in the {{ic|BootOrder}} line. If ''grub'' was not removed, the other boot loader should be listed before ''grub''. If ''grub'' is already removed, ''grub'' should not be mentioned in that line. But note this is only a necessary, but not sufficient, condition for the machine to boot with the other boot loader. Neither it is a sufficient condition for the full removal of ''grub''.<br />
<br />
For both UEFI and non UEFI machines, {{ic|grub-install}} was manually run as part of the installation of ''grub''. One of its jobs for the UEFI case was to run the equivalent of {{ic|efibootmgr --create}}. As part of ''grub'' removal, one has to remove the products of {{ic|grub-install}}. The opposite of {{ic|efibootmgr --create}} is {{ic|efibootmgr --delete-bootnum}}, or an equivalent program. One way to obtain the number of the boot entry for the {{ic|efibootmgr --delete-bootnum}} command is from the output of {{ic|efibootmgr}} (with no arguments).<br />
<br />
{{ic|grub-install}} creates the {{ic|/boot/grub}} directory that needs to be removed manually. Though some users will want to keep it, should they want to install ''grub'' again.<br />
<br />
After migrating to GPT/UEFI one may want to remove the [[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]] [[dd#Remove bootloader|using dd]]:<br />
<br />
# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unsupported file systems ===<br />
<br />
In case that GRUB does not support the root file system, an alternative {{ic|/boot}} partition with a supported file system must be created. In some cases, the development version of GRUB {{aur|grub-git}} may have native support for the file system.<br />
<br />
If GRUB is used with an unsupported file system it is not able to extract the [[UUID]] of your drive so it uses classic non-persistent {{ic|/dev/''sdXx''}} names instead. In this case you might have to manually edit {{ic|/boot/grub/grub.cfg}} and replace {{ic|1=root=/dev/''sdXx''}} with {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}}. You can use the {{ic|blkid}} command to get the UUID of your device, see [[Persistent block device naming]].<br />
<br />
While GRUB supports [[F2FS]] since version 2.0.4, it cannot correctly read its boot files from an F2FS partition that was created with the {{ic|extra_attr}} flag enabled.<br />
<br />
=== Enable debug messages ===<br />
<br />
{{Note|This change is overwritten when [[#Generate the main configuration file]].}}<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== UEFI ===<br />
<br />
==== Common installation errors ====<br />
<br />
* If you have a problem when running ''grub-install'' with ''sysfs'' or ''procfs'' and it says you must run {{ic|modprobe efivarfs}}, try [[Unified Extensible Firmware Interface#Mount efivarfs]].<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* If after running grub-install you are told your partition does not look like an EFI partition then the partition is most likely not {{ic|Fat32}}.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
<br />
{{Expansion|Provide an efibootmgr command.}}<br />
<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== Drop to rescue shell ====<br />
<br />
If GRUB loads but drops into the rescue shell with no errors, it can be due to one of these two reasons:<br />
<br />
* It may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing,<br />
* It also happens if the boot partition, which is hardcoded into the {{ic|grubx64.efi}} file, has changed.<br />
<br />
==== GRUB UEFI not loaded ====<br />
<br />
An example of a working UEFI:<br />
<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EFI\GRUB\grubx64.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\shellx64.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
<br />
Boot0000* GRUB HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grubx64.efi)<br />
<br />
==== Default/fallback boot path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''<br />
<br />
Alternatively you can move an already installed GRUB EFI executable to the default/fallback path:<br />
<br />
# mv ''esp''/EFI/grub ''esp''/EFI/BOOT<br />
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions may have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}}.<br />
<br />
=== Warning when installing in chroot ===<br />
<br />
When installing GRUB on a LVM system in a chroot environment (e.g. during system installation), you may receive warnings like<br />
<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
<br />
or<br />
<br />
WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.<br />
<br />
This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
<br />
=== GRUB loads slowly ===<br />
<br />
GRUB can take a long time to load when disk space is low. Check if you have sufficient free disk space on your {{ic|/boot}} or {{ic|/}} partition when you are having problems.<br />
<br />
=== error: unknown filesystem ===<br />
<br />
GRUB may output {{ic|error: unknown filesystem}} and refuse to boot for a few reasons. If you are certain that all [[UUID]]s are correct and all filesystems are valid and supported, it may be because your [[#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] is located outside the first 2 TiB of the drive [https://bbs.archlinux.org/viewtopic.php?id=195948]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2 TiB, then reinstall and reconfigure GRUB.<br />
<br />
This error might also be caused by an [[ext4]] filesystem having unsupported features set:<br />
* {{ic|large_dir}} - unsupported.<br />
* {{ic|metadata_csum_seed}} - will be supported in GRUB 2.11 ([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 commit]).<br />
<br />
{{Warning|Make sure to check GRUB support for new [[file system]] features before you enable them on your {{ic|/boot}} file system.}}<br />
<br />
=== grub-reboot not resetting ===<br />
<br />
GRUB seems to be unable to write to root BTRFS partitions [https://bbs.archlinux.org/viewtopic.php?id=166131]. If you use grub-reboot to boot into another entry it will therefore be unable to update its on-disk environment. Either run grub-reboot from the other entry (for example when switching between various distributions) or consider a different file system. You can reset a "sticky" entry by executing {{ic|grub-editenv create}} and setting {{ic|1=GRUB_DEFAULT=0}} in your {{ic|/etc/default/grub}} (do not forget {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}).<br />
<br />
=== Old BTRFS prevents installation ===<br />
<br />
If a drive is formatted with BTRFS without creating a partition table (eg. /dev/sdx), then later has partition table written to, there are parts of the BTRFS format that persist. Most utilities and OS's do not see this, but GRUB will refuse to install, even with --force<br />
<br />
# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..<br />
# grub-install: error: filesystem `btrfs' does not support blocklists.<br />
<br />
You can zero the drive, but the easy solution that leaves your data alone is to erase the BTRFS superblock with {{ic|wipefs -o 0x10040 /dev/sdx}}<br />
<br />
=== Windows 8/10 not found ===<br />
<br />
A setting in Windows 8/10 called "Hiberboot", "Hybrid Boot" or "Fast Boot" can prevent the Windows partition from being mounted, so {{ic|grub-mkconfig}} will not find a Windows install. Disabling Hiberboot in Windows will allow it to be added to the GRUB menu.<br />
<br />
=== VirtualBox EFI mode ===<br />
<br />
For VirtualBox < 6.1, install GRUB to the [[#Default/fallback boot path|default/fallback boot path]].<br />
<br />
See also [[VirtualBox#Installation in EFI mode on VirtualBox < 6.1]].<br />
<br />
=== Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds ===<br />
<br />
If grub-mkconfig hangs and gives error: {{ic|WARNING: Device /dev/''xxx'' not initialized in udev database even after waiting 10000000 microseconds}}.<br />
<br />
You may need to provide {{ic|/run/lvm/}} access to the chroot environment using:<br />
<br />
# mkdir /mnt/hostlvm<br />
# mount --bind /run/lvm /mnt/hostlvm<br />
# arch-chroot /mnt<br />
# ln -s /hostlvm /run/lvm<br />
<br />
See {{Bug|61040}} and [https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949 workaround].<br />
<br />
=== GRUB rescue and encrypted /boot ===<br />
<br />
When using an [[#Encrypted /boot|encrypted /boot]], and you fail to input a correct password, you will be dropped in grub-rescue prompt.<br />
<br />
This grub-rescue prompt has limited capabilities. Use the following commands to complete the boot:<br />
{{bc|<br />
grub rescue> cryptomount <partition><br />
grub rescue> insmod normal<br />
grub rescue> normal<br />
}}<br />
<br />
See [https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html this blog post] for a better description.<br />
<br />
=== GRUB is installed but the menu is not shown at boot ===<br />
<br />
Check {{ic|/etc/default/grub}} if {{ic|GRUB_TIMEOUT}} is set to {{ic|0}}, in which case set it to a positive number: it sets the number of seconds before the default GRUB entry is loaded. Also check if {{ic|GRUB_TIMEOUT_STYLE}} is set to {{ic|hidden}} and set it to {{ic|menu}}, so that the menu will be shown by default. Then [[#Generate the main configuration file|regenerate the main configuration file]] and reboot to check if it worked.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:GNU GRUB]]<br />
* [https://www.gnu.org/software/grub/manual/grub.html Official GRUB Manual]<br />
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki page for GRUB]<br />
* [https://help.ubuntu.com/community/UEFIBooting GRUB wiki page describing steps to compile for UEFI systems]<br />
* [[Wikipedia:BIOS Boot partition]]<br />
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme How to configure GRUB]<br />
* [https://archived.forum.manjaro.org/t/detecting-efi-files-and-booting-them-from-grub/38083 Detecting efi files and booting them from grub]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption&diff=723955Dm-crypt/Device encryption2022-03-22T09:12:42Z<p>RaZorr: Remove 'expansion note on adding method fo sd-encrypt'</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[es:Dm-crypt (Español)/Device encryption]]<br />
[[ja:Dm-crypt/デバイスの暗号化]]<br />
[[pl:Dm-crypt (Polski)/Device encryption]]<br />
[[pt:Dm-crypt (Português)/Device encryption]]<br />
This section covers how to manually utilize ''dm-crypt'' from the command line to encrypt a system.<br />
<br />
== Preparation ==<br />
<br />
Before using {{pkg|cryptsetup}}, always make sure the {{ic|dm_crypt}} [[kernel module]] is loaded.<br />
<br />
== Cryptsetup usage ==<br />
<br />
''Cryptsetup'' is the command line tool to interface with ''dm-crypt'' for creating, accessing and managing encrypted devices. The tool was later expanded to support different encryption types that rely on the Linux kernel '''d'''evice-'''m'''apper and the '''crypt'''ographic modules. The most notable expansion was for the Linux Unified Key Setup (LUKS) extension, which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use. Devices accessed via the device-mapper are called block devices. For further information see [[Data-at-rest encryption#Block device encryption]]. <br />
<br />
The tool is used as follows: <br />
<br />
# cryptsetup ''OPTIONS'' ''action'' ''action-specific-options'' ''device'' ''dmname''<br />
<br />
It has compiled-in defaults for the options and the encryption mode, which will be used if no others are specified on the command line. Have a look at <br />
<br />
$ cryptsetup --help <br />
<br />
which lists options, actions and the default parameters for the encryption modes in that order. A full list of options can be found on the man page.<br />
Since different parameters are required or optional, depending on encryption mode and action, the following sections point out differences further. Block device encryption is fast, but speed matters a lot too. Since changing an encryption cipher of a block device after setup is difficult, it is important to check ''dm-crypt'' performance for the individual parameters in advance: <br />
<br />
$ cryptsetup benchmark <br />
<br />
can give guidance on deciding for an algorithm and key-size prior to installation. If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU.<br />
<br />
{{Tip|You may want to practise encrypting a virtual hard drive in a [[virtual machine]] when learning.}}<br />
<br />
=== Cryptsetup passphrases and keys ===<br />
<br />
An encrypted block device is protected by a key. A key is either: <br />
<br />
* a passphrase: see [[Security#Passwords]].<br />
* a keyfile, see [[#Keyfiles]].<br />
<br />
Both key types have default maximum sizes: passphrases can be up to 512 characters and keyfiles up to 8192 KiB. <br />
<br />
An important distinction of ''LUKS'' to note at this point is that the key is used to unlock the master-key of a LUKS-encrypted device and can be changed with root access. Other encryption modes do not support changing the key after setup, because they do not employ a master-key for the encryption. See [[Data-at-rest encryption#Block device encryption]] for details.<br />
<br />
== Encryption options with dm-crypt ==<br />
<br />
''Cryptsetup'' supports different encryption operating modes to use with ''dm-crypt'': <br />
<br />
* {{ic|--type luks}} for using the default LUKS format version (LUKS1 with {{Pkg|cryptsetup}} < 2.1.0, LUKS2 with {{Pkg|cryptsetup}} ≥ 2.1.0),<br />
* {{ic|--type luks1}} for using LUKS1, the most common version of LUKS,<br />
* {{ic|--type luks2}} for using LUKS2, the latest available version of LUKS that allows additional extensions,<br />
* {{ic|--type plain}} for using dm-crypt plain mode, <br />
* {{ic|--type loopaes}} for a loopaes legacy mode, <br />
* {{ic|--type tcrypt}} for a [[TrueCrypt]] compatibility mode.<br />
* {{ic|--type bitlk}} for a [[Wikipedia:BitLocker|BitLocker]] compatibility mode. See {{man|8|cryptsetup|BITLK (Windows BitLocker-compatible) EXTENSION (EXPERIMENTAL)}}.<br />
<br />
The basic cryptographic options for encryption cipher and hashes available can be used for all modes and rely on the kernel cryptographic backend features. All that are loaded and available to use as options at runtime can be viewed with:<br />
<br />
$ less /proc/crypto <br />
<br />
{{Tip|If the list is short, execute {{ic|$ cryptsetup benchmark}} which will trigger loading available modules.}}<br />
<br />
The following introduces encryption options for the {{ic|luks}}, {{ic|luks1}}, {{ic|luks2}} and {{ic|plain}} modes. Note that the tables list options used in the respective examples in this article and not all available ones.<br />
<br />
=== Encryption options for LUKS mode ===<br />
<br />
The ''cryptsetup'' action to set up a new dm-crypt device in LUKS encryption mode is {{ic|luksFormat}}. Unlike what the name implies, it does not format the device, but sets up the LUKS device header and encrypts the master-key with the desired cryptographic options. <br />
<br />
In order to create a new LUKS container with the compiled-in defaults listed by {{ic|cryptsetup --help}}, simply execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
As of cryptsetup 2.4.0, this is equivalent to: <br />
<br />
# cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat ''device''<br />
<br />
Defaults are compared with a cryptographically higher specification example in the table below, with accompanying comments: <br />
<br />
{| class="wikitable"<br />
! Options !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-xts-plain64}}<br />
| {{ic|aes-xts-plain64}}<br />
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes Release 1.6.0] changed the defaults to an AES [[Data-at-rest encryption#Ciphers and modes of operation|cipher]] in [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] mode (see item 5.16 [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects of the FAQ]). It is advised against using the previous default {{ic|--cipher aes-cbc-essiv}} because of its known [[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|issues]] and practical [https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ attacks] against them.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
| {{ic|256}} ({{ic|512}} for XTS)<br />
| {{ic|512}}<br />
| By default a 512 bit key-size is used for XTS ciphers. Note however that [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS splits the supplied key in half]], so this results in AES-256 being used.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|sha256}}<br />
| {{ic|sha512}}<br />
| Hash algorithm used for [[Data-at-rest encryption#Cryptographic metadata|key derivation]]. Release 1.7.0 changed defaults from {{ic|sha1}} to {{ic|sha256}} "''not for security reasons [but] mainly to prevent compatibility problems on hardened systems where SHA1 is already [being] phased out''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. The former default of {{ic|sha1}} can still be used for compatibility with older versions of ''cryptsetup'' since it is [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects considered secure] (see item 5.20). <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --iter-time<br />
-i<br />
| {{ic|2000}}<br />
| {{ic|5000}}<br />
| Number of milliseconds to spend with PBKDF2 passphrase processing. Release 1.7.0 changed defaults from {{ic|1000}} to {{ic|2000}} to "''try to keep PBKDF2 iteration count still high enough and also still acceptable for users.''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. This option is only relevant for LUKS operations that set or change passphrases, such as {{ic|luksFormat}} or {{ic|luksAddKey}}. Specifying 0 as parameter selects the compiled-in default..<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --use-urandom<br />
| {{ic|--use-urandom}}<br />
| {{ic|--use-random}}<br />
| Selects which [[random number generator]] to use. Note that [https://lwn.net/Articles/808575/ /dev/random blocking pool has been removed]. Therefore, {{ic|--use-random}} flag is now equivalent to {{ic|--use-urandom}}.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --verify-passphrase<br />
-y<br />
| Yes<br />
| -<br />
| Enabled by default in Arch Linux for {{ic|luksFormat}} and {{ic|luksAddKey}}.<br />
|}<br />
<br />
The properties of LUKS features and options are described in the [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification LUKS1] (pdf) and [https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf LUKS2] (pdf) specifications.<br />
<br />
{{Tip|The project developers' [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) presentation summarizes the motivation for the major specification update to LUKS2.}}<br />
<br />
==== Iteration time ====<br />
<br />
From [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] and [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]:<br />
<br />
:The unlock time for a key-slot [...] is calculated when setting a passphrase. By default it is 1 second (2 seconds for LUKS2). [...]<br />
:Passphrase iteration count is based on time and hence security level depends on CPU power of the system the LUKS container is created on. [...]<br />
:If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be much longer.<br />
<br />
As such, it is better to always create a container on the machine where it will be most often accessed.<br />
<br />
Read the rest of those sections for advice on how to correctly adjust the iteration count should the need arise.<br />
<br />
==== Sector size ====<br />
<br />
See [[Advanced Format#dm-crypt]].<br />
<br />
=== Encryption options for plain mode ===<br />
<br />
In dm-crypt ''plain'' mode, there is no master-key on the device, hence, there is no need to set it up. Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed. <br />
<br />
To create a ''plain'' mode mapping with cryptsetup's default parameters: <br />
<br />
# cryptsetup ''options'' open --type plain ''device'' ''dmname''<br />
<br />
Executing it will prompt for a password, which should have very high entropy. Below a comparison of default parameters with the example in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]].<br />
<br />
{| class="wikitable"<br />
! Option !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|ripemd160}}<br />
| -<br />
| The hash is used to create the key from the passphrase; it is not used on a keyfile. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-cbc-essiv:sha256}}<br />
| {{ic|aes-xts-plain64}}<br />
| The cipher consists of three parts: cipher-chainmode-IV generator. Please see [[Data-at-rest encryption#Ciphers and modes of operation]] for an explanation of these settings, and the [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt documentation] for some of the options available. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
|{{ic|256}}<br />
|{{ic|512}}<br />
|The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode requires twice the key size of cbc. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --size<br />
-b<br />
|real size of target disk<br />
|{{ic|2048}} (mapped device will be 512B×2048=1MiB)<br />
|Limit the maximum size of the device (in 512-byte sectors).<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --offset<br />
-o<br />
|{{ic|0}}<br />
|{{ic|0}}<br />
|The offset from the beginning of the target disk (in 512-byte sectors) from which to start the mapping.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --skip<br />
-p<br />
|{{ic|0}}<br />
|{{ic|2048}} (512B×2048=1MiB will be skipped)<br />
|The number of 512-byte sectors of encrypted data to skip at the beginning.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-file<br />
-d<br />
| default uses a passphrase<br />
| {{ic|/dev/sd''Z''}} (or e.g. {{ic|/boot/keyfile.enc}})<br />
|The device or file to be used as a key. See [[#Keyfiles]] for further details.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-offset<br />
| {{ic|0}}<br />
| {{ic|0}}<br />
| Offset from the beginning of the file where the key starts (in bytes). This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-size<br />
-l<br />
|{{ic|8192kB}}<br />
| - (default applies)<br />
| Limits the bytes read from the key file. This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|}<br />
<br />
Using the device {{ic|/dev/sd''X''}}, the above right column example results in:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sd''Z'' --key-size=512 open --type=plain /dev/sdX enc<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:<br />
<br />
# fdisk -l<br />
<br />
An entry should now exist for {{ic|/dev/mapper/enc}}.<br />
<br />
== Encrypting devices with cryptsetup ==<br />
<br />
This section shows how to employ the options for creating new encrypted block devices and accessing them manually. <br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
=== Encrypting devices with LUKS mode ===<br />
<br />
==== Formatting LUKS partitions ====<br />
<br />
In order to setup a partition as an encrypted LUKS partition execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
You will then be prompted to enter a password and verify it.<br />
<br />
See [[#Encryption options for LUKS mode]] for command line options.<br />
<br />
You can check the results with:<br />
<br />
# cryptsetup luksDump ''device''<br />
<br />
You will note that the dump not only shows the cipher header information, but also the key-slots in use for the LUKS partition. <br />
<br />
The following example will create an encrypted root partition on {{ic|/dev/sda1}} using the default AES cipher in XTS mode with an effective 256-bit encryption <br />
<br />
# cryptsetup -s 512 luksFormat /dev/sda1<br />
<br />
===== Using LUKS to format partitions with a keyfile =====<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup luksFormat ''device'' ''/path/to/mykeyfile''<br />
<br />
See [[#Keyfiles]] for instructions on how to generate and manage keyfiles.<br />
<br />
==== Unlocking/Mapping LUKS partitions with the device mapper ====<br />
<br />
Once the LUKS partitions have been created, they can then be unlocked.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|''device''}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/''dm_name''}} so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to [[#Backup and restore|backup the cryptheader]] after finishing setup.<br />
<br />
In order to open an encrypted LUKS partition execute:<br />
<br />
# cryptsetup open ''device'' ''dm_name''<br />
<br />
You will then be prompted for the password to unlock the partition. Usually the device mapped name is descriptive of the function of the partition that is mapped. For example the following unlocks a root luks partition {{ic|/dev/sda1}} and maps it to device mapper named {{ic|root}}:<br />
<br />
# cryptsetup open /dev/sda1 root <br />
<br />
Once opened, the root partition device address would be {{ic|/dev/mapper/root}} instead of the partition (e.g. {{ic|/dev/sda1}}). <br />
<br />
For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like {{ic|/dev/mapper/root}} instead of {{ic|/dev/sda1}}. LVM will then give additional names to all logical volumes created, e.g. {{ic|/dev/lvmpool/root}} and {{ic|/dev/lvmpool/swap}}.<br />
<br />
In order to write encrypted data into the partition it must be accessed through the device mapped name. The first step of access will typically be to [[create a file system]]. For example:<br />
<br />
# mkfs -t ext4 /dev/mapper/root<br />
<br />
The device {{ic|/dev/mapper/root}} can then be [[mount]]ed like any other partition.<br />
<br />
To close the LUKS container, unmount the partition and do:<br />
<br />
# cryptsetup close root<br />
<br />
==== Using a TPM to store keys ====<br />
<br />
See [[Trusted Platform Module#Data-at-rest encryption with LUKS]].<br />
<br />
=== Encrypting devices with plain mode ===<br />
<br />
The creation and subsequent access of a ''dm-crypt'' plain mode encryption both require not more than using the ''cryptsetup'' {{ic|open}} action with correct [[#Encryption options for plain mode|parameters]]. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage. <br />
<br />
A first mapper is created with ''cryptsetup's'' plain-mode defaults, as described in the table's left column above <br />
<br />
{{hc|# cryptsetup --type plain -v open /dev/sdaX plain1|<br />
Enter passphrase: <br />
Command successful.<br />
}}<br />
<br />
Now we add the second block device inside it, using different encryption parameters and with an (optional) offset, create a file system and mount it <br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
/dev/sda <br />
├─/dev/sdaX <br />
│ └─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
# mkfs -t ext2 /dev/mapper/plain2<br />
# mount -t ext2 /dev/mapper/plain2 /mnt<br />
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt<br />
<br />
We close the stack to check access works<br />
<br />
# cryptsetup close plain2<br />
# cryptsetup close plain1<br />
<br />
First, let us try to open the file system directly: <br />
<br />
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdaX plain2<br />
<br />
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|<br />
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,<br />
missing codepage or helper program, or other error<br />
}}<br />
<br />
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself. <br />
<br />
Trying again in correct order: <br />
<br />
# cryptsetup close plain2 # dysfunctional mapper from previous try<br />
<br />
{{hc|# cryptsetup --type plain open /dev/sdaX plain1|<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|<br />
This is stacked. one passphrase per foot to shoot.<br />
}}<br />
<br />
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.<br />
<br />
Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time: <br />
<br />
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdaX plain1|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdaX plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
dev/sdaX <br />
├─/dev/sdaX <br />
│ ├─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
As the device tree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.<br />
<br />
== Cryptsetup actions specific for LUKS ==<br />
<br />
=== Key management ===<br />
<br />
It is possible to define addition keys for the LUKS partition. This enables the user to create access keys for safe backup storage In so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. A different key-slot could also be used to grant access to a partition to a user by issuing a second key and later revoking it again. <br />
<br />
Once an encrypted partition has been created, the initial keyslot 0 is created (if no other was specified manually). Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing <br />
<br />
# cryptsetup luksDump /dev/''device''<br />
<br />
Where {{ic|''device''}} is the block device containing the LUKS header. This and all the following commands in this section work on header backup files as well.<br />
<br />
==== Adding LUKS keys ====<br />
<br />
Adding new keyslots is accomplished using cryptsetup with the {{ic|luksAddKey}} action. For safety it will always, i.e. also for already unlocked devices, ask for a valid existing key ("any passphrase") before a new one may be entered:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' (''/path/to/''additionalkeyfile'')|<br />
Enter any passphrase:<br />
Enter new passphrase for key slot:<br />
Verify passphrase: <br />
}}<br />
<br />
If {{ic|''/path/to/additionalkeyfile''}} is given, cryptsetup will add a new keyslot for {{ic|''additionalkeyfile''}}. Otherwise a new passphrase will be prompted for twice. For using an existing ''keyfile'' to authorize the action, the {{ic|--key-file}} or {{ic|-d}} option followed by the "old" {{ic|''keyfile''}} will try to unlock all available keyfile keyslots:<br />
<br />
# cryptsetup luksAddKey /dev/''device'' (''/path/to/additionalkeyfile'') -d ''/path/to/keyfile''<br />
<br />
If it is intended to use multiple keys and change or revoke them, the {{ic|--key-slot}} or {{ic|-S}} option may be used to specify the slot: <br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' -S 6|<br />
Enter any passphrase: <br />
Enter new passphrase for key slot: <br />
Verify passphrase:<br />
}}<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: ENABLED<br />
}}<br />
<br />
To show an associated action in this example, we decide to change the key right away: <br />
<br />
{{hc|# cryptsetup luksChangeKey /dev/''device'' -S 6|<br />
Enter LUKS passphrase to be changed: <br />
Enter new LUKS passphrase:<br />
}}<br />
<br />
before continuing to remove it.<br />
<br />
==== Removing LUKS keys ====<br />
<br />
There are three different actions to remove keys from the header: <br />
<br />
* {{ic|luksRemoveKey}} is used to remove a key by specifying its passphrase/key-file. <br />
* {{ic|luksKillSlot}} may be used to remove a key from a specific key slot (using another key). Obviously, this is extremely useful if you have forgotten a passphrase, lost a key-file, or have no access to it. <br />
* {{ic|luksErase}} is used to quickly remove '''all''' active keys. <br />
<br />
{{warning|<br />
* All above actions can be used to irrevocably delete the last active key for an encrypted device! <br />
* The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[dm-crypt/Drive preparation#Wipe LUKS header|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.<br />
}}<br />
<br />
For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies: <br />
<br />
{{hc|# cryptsetup --test-passphrase -v open /dev/''device''|<br />
Enter passphrase for /dev/''device'': <br />
Key slot 1 unlocked.<br />
Command successful.<br />
}}<br />
<br />
Now we can remove the key added in the previous subsection using its passphrase: <br />
<br />
{{hc|# cryptsetup luksRemoveKey /dev/''device''|<br />
Enter LUKS passphrase to be deleted:<br />
}}<br />
<br />
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one. <br />
<br />
Alternatively, we can specify the key slot: <br />
<br />
{{hc|# cryptsetup luksKillSlot /dev/''device'' 6|<br />
Enter any remaining LUKS passphrase:<br />
}}<br />
<br />
Note that in both cases, no confirmation was required.<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: DISABLED<br />
}}<br />
<br />
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.<br />
<br />
=== Backup and restore ===<br />
<br />
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.<br />
<br />
{{Note|If one of the LUKS-encrypted partitions' passphrases becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to determine the master key which in turn can be used to decrypt the associated partition (even your actual partition, not only the backed-up version). On the other hand, if the master key gets compromised, you have to reencrypt your whole partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}<br />
<br />
==== Backup using cryptsetup ====<br />
<br />
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:<br />
<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file ''/mnt/backup/file.img''<br />
<br />
where {{ic|''device''}} is the partition containing the LUKS volume.<br />
<br />
You can also back up the plain text header into ramfs and encrypt it with e.g. [[GPG]] before writing it to persistent storage:<br />
<br />
# mkdir /root/''tmp''/<br />
# mount ramfs /root/''tmp''/ -t ramfs<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file /root/''tmp''/''file''.img<br />
# gpg2 --recipient ''User_ID'' --encrypt /root/''tmp''/''file''.img <br />
# cp /root/''tmp''/''file''.img.gpg /mnt/''backup''/<br />
# umount /root/''tmp''<br />
<br />
{{Warning|[[tmpfs]] can swap to the disk in low memory situations, so it is not recommended here.}}<br />
<br />
==== Restore using cryptsetup ====<br />
<br />
{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}} <br />
<br />
In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first: <br />
<br />
{{hc|# cryptsetup -v --header /mnt/''backup''/''file''.img open /dev/''device'' test|<br />
Key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
# mount /dev/mapper/test /mnt/test && ls /mnt/test <br />
# umount /mnt/test <br />
# cryptsetup close test <br />
<br />
Now that the check succeeded, the restore may be performed: <br />
<br />
# cryptsetup luksHeaderRestore /dev/''device'' --header-backup-file ./mnt/''backup''/''file''.img<br />
<br />
Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.<br />
<br />
==== Manual backup and restore ====<br />
<br />
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:<br />
<br />
{{hc|# cryptsetup luksDump /dev/''device'' {{!}} grep "Payload offset"|<br />
Payload offset: 4040<br />
}}<br />
<br />
Second check the sector size of the drive<br />
<br />
{{hc|# fdisk -l /dev/''device'' {{!}} grep "Sector size"|<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
}}<br />
<br />
Now that you know the values, you can backup the header with a simple [[dd]] command:<br />
<br />
# dd if=/dev/''device'' of=/path/to/''file''.img bs=512 count=4040<br />
<br />
and store it safely.<br />
<br />
A restore can then be performed using the same values as when backing up:<br />
<br />
# dd if=./''file''.img of=/dev/''device'' bs=512 count=4040<br />
<br />
=== Re-encrypting devices ===<br />
<br />
{{Expansion|cryptsetup 2.2 using LUKS2 (with a 16 MiB header) supports online encryption/decryption/reencryption.[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/v2.2.0-ReleaseNotes]}}<br />
<br />
The {{Pkg|cryptsetup}} package features two options for re-encryption.<br />
<br />
; cryptsetup reencrypt: Argument to {{ic|cryptsetup}} itself: Preferred method. Currently LUKS2 devices only. Actions can be performed online. Supports multiple parallel re-encryption jobs. Resilient to system failures. See {{man|8|cryptsetup}} for more information.<br />
<br />
; cryptsetup-reencrypt: Legacy tool, supports LUKS1 in addition to LUKS2. Actions can be performed on unmounted devices only. Single process at a time. Sensitive to system failures. See {{man|8|cryptsetup-reencrypt}} for more information. <br />
<br />
Both can be used to convert an existing unencrypted file system to a LUKS encrypted one or permanently remove LUKS encryption from a device (using {{ic|--decrypt}}). As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#Encryption options for LUKS mode]]. <br />
<br />
One application of re-encryption may be to secure the data again after a passphrase or [[#Keyfiles|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]). <br />
<br />
{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}<br />
<br />
The following shows an example to encrypt an unencrypted file system partition and a re-encryption of an existing LUKS device.<br />
<br />
==== Encrypt an existing unencrypted file system ====<br />
<br />
{{Tip|If you are trying to encrypt an existing root partition, you might want to create a separate and unencrypted boot partition which will be mounted to {{ic|/boot}} (see [[Dm-crypt/Encrypting an entire system#Preparing the boot partition]]). It is not strictly necessary but has a number of advantages:<br />
<br />
* If {{ic|/boot}} is located inside an encrypted root partition, the system will ask for the passphrase twice when the machine is powered on. The first time will happen when the boot loader attempts to read the files located inside encrypted {{ic|/boot}}, the second time will be when the kernel tries to mount the encrypted partition [https://opencraft.com/blog/tutorial-encrypting-an-existing-root-partition-in-ubuntu-with-dm-crypt-and-luks/]. This might not be the desired behaviour and can be prevented by having a separate and unencryted boot partition.<br />
* Some system restore applications (e.g., {{AUR|timeshift}}) will not work if {{ic|/boot}} is located inside an encryted partition [https://github.com/teejee2008/timeshift/issues/280].<br />
<br />
In short, create a partition with the size of at least 260 MiB if needed. See [[Partitioning#/boot]].}}<br />
<br />
A LUKS encryption header is always stored at the beginning of the device. Since an existing file system will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.<br />
<br />
{{Expansion|cryptsetup man pages suggest using twice the LUKS2 header size. That implies 32 MiB and using {{ic|--reduce-device-size 32M}}}}<br />
<br />
The [[#Encryption options for LUKS mode|default]] LUKS2 header requires 16 MiB. If the current file system occupies all the available space, we will have to shrink it at least that much. To shrink an existing {{ic|ext4}} file system on {{ic|/dev/sdaX}} to its current possible minimum:<br />
<br />
# umount /mnt<br />
<br />
{{hc|# e2fsck -f /dev/sdaX|<br />
e2fsck 1.43-WIP (18-May-2015)<br />
Pass 1: Checking inodes, blocks, and sizes<br />
...<br />
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks<br />
}}<br />
<br />
{{hc|# resize2fs -p -M /dev/sdaX|<br />
resize2fs 1.43-WIP (18-May-2015)<br />
Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks.<br />
The filesystem on /dev/sdaX is now 26347 (4k) blocks long.<br />
}}<br />
<br />
{{Tip|Shrinking to the minimum size with {{ic|-M}} might take very long. You might want to calculate a size just 32 MiB smaller than the current size instead of using {{ic|-M}}.}}<br />
<br />
{{Warning|The file system should be shrunk while the underlying device (e.g., a partition) should be kept at its original size. Some graphical tools (e.g., [[GParted]]) may resize both the file system and the partition, and data loss may occur after encryption.}}<br />
<br />
Now we encrypt it, using the default cipher we do not have to specify it explicitly:<br />
<br />
{{hc|# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sdaX|<nowiki><br />
<br />
WARNING!<br />
<br />
========<br />
<br />
This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.<br />
<br />
Are you sure? (Type 'yes' in capital letters): YES<br />
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new: <br />
Verify passphrase: <br />
</nowiki>}}<br />
<br />
After it finished, the whole {{ic|/dev/sdaX}} partition is encrypted, not only the space the file system was shrunk to. As a final step we extend the original {{ic|ext4}} file system to occupy all available space again, on the now encrypted partition:<br />
<br />
{{hc|# cryptsetup open /dev/sdaX recrypt|<br />
Enter passphrase for /dev/sdaX: <br />
...<br />
}}<br />
<br />
{{hc|# resize2fs /dev/mapper/recrypt|<br />
resize2fs 1.43-WIP (18-May-2015)<br />
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.<br />
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.<br />
}}<br />
<br />
# mount /dev/mapper/recrypt /mnt<br />
<br />
The file system is now ready to use. You may want to add it to your [[crypttab]].<br />
<br />
{{Tip|If you have just encrypted your root partition, you might need to perform a number of post-encryption adjustments.<br />
<br />
See [[Dm-crypt/Encrypting an entire system#Configuring mkinitcpio]], [[Dm-crypt/Encrypting an entire system#Configuring the boot loader]], and [[Dm-crypt/Encrypting an entire system#Configuring GRUB]].}}<br />
<br />
==== Re-encrypting an existing LUKS partition ====<br />
<br />
In this example an existing LUKS device is re-encrypted. <br />
<br />
{{Warning|Double-check you specify encryption options for correctly and ''never'' re-encrypt without a '''reliable backup'''!}}<br />
<br />
In order to re-encrypt a device with its existing encryption options, they do not need to be specified:<br />
{{bc|# cryptsetup reencrypt /dev/sdaX}}<br />
{{Note|For LUKS1 we will need to use the legacy tool:{{bc|# cryptsetup-reencrypt /dev/sdaX}}}}<br />
<br />
Existing keys are retained when re-encrypting a device with a different cipher and/or hash. Another use case is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors: <br />
<br />
{{hc|# cryptsetup luksDump /dev/sdaX {{!}} grep -e "mode" -e "Payload" -e "MK bits"|<br />
Cipher mode: cbc-essiv:sha256<br />
Payload offset: '''2048'''<br />
MK bits: 128<br />
}}<br />
<br />
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.<br />
<br />
=== Conversion from LUKS1 to LUKS2 and back ===<br />
<br />
The {{Pkg|cryptsetup}} package has {{ic|convert}} option that needed for conversion between LUKS1 and LUKS2 container types. The argument {{ic|--type}} is '''required'''.<br />
<br />
Migration from LUKS1 to LUKS2:<br />
<br />
# cryptsetup convert --type luks2 /dev/sdaX<br />
<br />
{{Note|The LUKS header size will be 2 MiB instead of 16 MiB.}}<br />
<br />
Rollback to LUKS1 (for example, to boot from [[GRUB#Encrypted /boot|GRUB with encrypted /boot]]):<br />
<br />
# cryptsetup convert --type luks1 /dev/sdaX<br />
<br />
{{Note|Conversion from LUKS2 to LUKS1 is '''not''' always possible. You may get the following error:<br />
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.<br />
}}<br />
<br />
== Resizing encrypted devices ==<br />
<br />
{{Expansion|This section should be rewritten to introduce resizing more generically. Perhaps work on it together with [[Resizing LVM-on-LUKS]].}}<br />
<br />
If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space. <br />
<br />
The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:<br />
<br />
# cryptsetup luksOpen /dev/sdX2 sdX2<br />
# cryptsetup resize sdX2<br />
<br />
Then the underlying file system must be resized.<br />
<br />
=== Loopback file system ===<br />
<br />
Assume that an encrypted loopback file system is stored in a file {{ic|/bigsecret}}, looped to {{ic|/dev/loop0}}, mapped to {{ic|secret}} and mounted on {{ic|/mnt/secret}}, as in the example at [[dm-crypt/Encrypting a non-root file system#File container]].<br />
<br />
If the container file is currently mapped and/or mounted, unmount and/or close it:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
Next, expand the container file with the size of the data you want to add. In this example, the file will be expanded with 1M * 1024, which is 1G.<br />
<br />
{{Warning|Make absolutely sure to use '''two''' {{ic|>}}, instead of just one, or else you will overwrite the file instead of appending to it. Making a backup before this step is strongly recommended.}}<br />
<br />
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Now map the container to the loop device:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
<br />
After this, resize the encrypted part of the container to the new maximum size of the container file:<br />
<br />
# cryptsetup resize secret<br />
<br />
Finally, perform a file system check and, if it is ok, resize it (example for ext2/3/4):<br />
<br />
# e2fsck -f /dev/mapper/secret<br />
# resize2fs /dev/mapper/secret<br />
<br />
You can now mount the container again:<br />
<br />
# mount /dev/mapper/secret /mnt/secret<br />
<br />
=== Integrity protected device ===<br />
<br />
If the device was formatted with integrity support (e.g., {{ic|--integrity hmac-sha256}}) and the backing block device is shrinked, it cannot be opened with this error: {{ic|device-mapper: reload ioctl on failed: Invalid argument}}.<br />
<br />
To fix this issue without wiping the device again, it can be formatted with the previous master key (keeping the per-sector tags valid).<br />
<br />
# cryptsetup luksDump /dev/sdX2 --dump-master-key --master-key-file=/tmp/masterkey-in-tmpfs.key<br />
# cryptsetup luksFormat /dev/sdX2 --type luks2 --integrity hmac-sha256 --master-key-file=/tmp/masterkey-in-tmpfs.key --integrity-no-wipe<br />
# rm /tmp/masterkey-in-tmpfs.key<br />
<br />
== Keyfiles ==<br />
<br />
{{Note|This section describes using a plaintext keyfile. If you want to encrypt your keyfile giving you two factor authentication see [[dm-crypt/Specialties#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|Using GPG or OpenSSL Encrypted Keyfiles]] for details, but please still read this section.}}<br />
<br />
'''What is a keyfile?'''<br />
<br />
A keyfile is a file whose data is used as the passphrase to unlock an encrypted volume.<br />
That means if such a file is lost or changed, decrypting the volume may no longer be possible.<br />
<br />
{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}<br />
<br />
'''Why use a keyfile?'''<br />
<br />
There are many kinds of keyfiles. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
=== Types of keyfiles ===<br />
<br />
==== passphrase ====<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.<br />
<br />
Example: {{ic|1234}}<br />
<br />
{{Note|The keyfile containing the passphrase must not have a newline in it. One option is to create it using <br />
<br />
# echo -n 'your_passphrase' > ''/path/to/keyfile''<br />
# chown root:root ''/path/to/keyfile''; chmod 400 ''/path/to/keyfile''<br />
<br />
If the file contains special characters such as a backslash, rather than escaping these, it is recommended to simply edit the key file directly entering or pasting the passphrase and then remove the trailing newline with a handy perl one-liner:<br />
<br />
# perl -pi -e 'chomp if eof' ''/path/to/keyfile''<br />
}}<br />
<br />
==== randomtext ====<br />
<br />
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.<br />
<br />
Example: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}<br />
<br />
==== binary ====<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a random text file. However this is controversial and has never been exploited publicly.<br />
<br />
Example: images, text, video, ...<br />
<br />
=== Creating a keyfile with random characters ===<br />
<br />
==== Storing the keyfile on a file system ====<br />
<br />
A keyfile can be of arbitrary content and size. <br />
<br />
Here [[dd]] is used to generate a keyfile of 2048 random bytes, storing it in the file {{ic|/etc/mykeyfile}}:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/etc/mykeyfile iflag=fullblock<br />
<br />
If you are planning to store the keyfile on an external device, you can also simply change the outputfile to the corresponding directory:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/media/usbstick/mykeyfile iflag=fullblock<br />
<br />
To deny any access for other users than {{ic|root}}:<br />
<br />
# chmod 600 /etc/mykeyfile<br />
<br />
===== Securely overwriting stored keyfiles =====<br />
<br />
If you stored your temporary keyfile on a physical storage device, and want to delete it, remember to not just remove the keyfile later on, but use something like<br />
<br />
# shred --remove --zero mykeyfile<br />
<br />
to securely overwrite it. For overaged file systems like FAT or ext2 this will suffice while in the case of journaling file systems, flash memory hardware and other cases it is highly recommended to [[Securely wipe disk|wipe the entire device]].<br />
<br />
==== Storing the keyfile in ramfs ====<br />
<br />
Alternatively, you can mount a ramfs for storing the keyfile temporarily:<br />
<br />
# mkdir /root/myramfs<br />
# mount ramfs /root/myramfs/ -t ramfs<br />
# cd /root/myramfs<br />
<br />
The advantage is that it resides in RAM and not on a physical disk, therefore it can not be recovered after unmounting the ramfs. After copying the keyfile to another secure and persistent file system, unmount the ramfs again with<br />
<br />
# umount /root/myramfs<br />
<br />
=== Configuring LUKS to make use of the keyfile ===<br />
<br />
Add a keyslot for the keyfile to the LUKS header:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
=== Manually unlocking a partition using a keyfile ===<br />
<br />
Use the {{ic|--key-file}} option when opening the LUKS device:<br />
<br />
# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile<br />
<br />
=== Unlocking the root partition at boot ===<br />
<br />
This is simply a matter of configuring [[mkinitcpio]] to include the necessary modules or files and configuring the [[dm-crypt/System configuration#cryptkey|cryptkey]] [[kernel parameter]] to know where to find the keyfile.<br />
<br />
Two cases are covered below:<br />
<br />
# Using a keyfile stored on an external medium (e.g. a USB stick)<br />
# Using a keyfile embedded in the initramfs<br />
<br />
==== With a keyfile stored on an external media ====<br />
<br />
===== Configuring mkinitcpio =====<br />
<br />
You have to add the kernel module for the drive's [[file system]] to the [[mkinitcpio#MODULES|MODULES array]] in {{ic|/etc/mkinitcpio.conf}}. For example, add {{ic|ext4}} if the file system is [[Ext4]] or {{ic|vfat}} in case it is [[FAT]]:<br />
<br />
MODULES=(vfat)<br />
<br />
If there are messages about bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.<br />
<br />
[[Regenerate the initramfs]].<br />
<br />
===== Configuring the kernel parameters =====<br />
<br />
* For a busybox-based initramfs using the [[dm-crypt/System configuration#Using encrypt hook|encrypt]] hook, see [[dm-crypt/System configuration#cryptkey]].<br />
* For a systemd based initramfs using the [[sd-encrypt]] hook, see [[dm-crypt/System configuration#rd.luks.key]].<br />
<br />
==== With a keyfile embedded in the initramfs ====<br />
<br />
{{Warning|Use an embedded keyfile '''only''' if you protect the keyfile sufficiently by:<br />
* Using some form of authentication earlier in the boot process. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.<br />
* {{ic|/boot}} is encrypted. Otherwise root on a different installation (including the [[Installation guide#Boot the live environment|live environment]]) can extract your key from the initramfs, and unlock the device without any other authentication.}}<br />
<br />
This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root file system ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#Encrypted /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.<br />
<br />
The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''path/to/keyfile''}}. See [[dm-crypt/System configuration#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.<br />
<br />
If using {{ic|sd-encrypt}} instead of {{ic|encrypt}}, specify the location of the keyfile with the {{ic|rd.luks.key}} kernel parameter: in the case of initramfs, the syntax is {{ic|''path/to/keyfile''}}. See [[dm-crypt/System configuration#rd.luks.key]]. This kernel parameter defaults to using {{ic|/etc/cryptsetup-keys.d/''name''.key}} (where ''name'' is the ''dm_name'' used for decryption in [[Dm-crypt/Device_encryption#Encrypting_devices_with_cryptsetup|Encrypting_devices_with_cryptsetup]]) and can be omitted if initramfs contains a valid key with this path.<br />
<br />
[[#Creating a keyfile with random characters|Generate the keyfile]], give it suitable permissions and [[#Adding LUKS keys|add it as a LUKS key]]:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock<br />
# chmod 600 /crypto_keyfile.bin<br />
# chmod 600 /boot/initramfs-linux*<br />
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin<br />
<br />
{{Warning|When initramfs' permissions are set to 644 (by default), then all users will be able to dump the keyfile. Make sure the permissions are still 600 if you install a new kernel.}}<br />
<br />
Include the key in [[mkinitcpio#BINARIES and FILES|mkinitcpio's FILES array]]:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/crypto_keyfile.bin)<br />
}}<br />
<br />
Finally [[regenerate the initramfs]].<br />
<br />
On the next reboot you should only have to enter your container decryption passphrase once.<br />
<br />
([https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once source])</div>RaZorrhttps://wiki.archlinux.org/index.php?title=ConnMan&diff=722527ConnMan2022-03-11T18:09:15Z<p>RaZorr: Move line on restarting connman service file to dns server conflict section</p>
<hr />
<div>[[Category:Network managers]]<br />
[[ja:ConnMan]]<br />
[[zh-hans:ConnMan]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
<br />
[https://web.archive.org/web/20210224075615/https://01.org/connman ConnMan] is a command-line network manager designed for use with embedded devices and fast resolve times. It is modular through a [https://git.kernel.org/cgit/network/connman/connman.git/tree/plugins plugin architecture], but has native [[Wikipedia:DHCP|DHCP]] and [[NTP]] support.[https://git.kernel.org/cgit/network/connman/connman.git/tree/src/]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|connman}} package. {{Pkg|wpa_supplicant}}, {{Pkg|bluez}}, and {{pkg|openvpn}} are optional dependencies required for Wi-Fi, Bluetooth, and VPN functionality respectively.<br />
<br />
Before [[enabling]] {{ic|connman.service}}, ensure any existing [[network configuration]] is disabled.<br />
<br />
ConnMan comes with the {{man|1|connmanctl}} CLI, there are various [[#Front-ends]] available.<br />
<br />
=== Front-ends ===<br />
<br />
* {{App|cmst|Qt GUI for ConnMan.|https://github.com/andrew-bibb/cmst|{{AUR|cmst}}}}<br />
* {{App|connman-ncurses|Simple ncurses UI for ConnMan; not all of connman functionality is implemented, but usable (with X or from terminal without X), see the [https://github.com/eurogiciel-oss/connman-json-client/wiki wiki].|https://github.com/eurogiciel-oss/connman-json-client|{{AUR|connman-ncurses-git}}}}<br />
* {{App|ConnMan-UI|GTK3 client applet.|https://github.com/tbursztyka/connman-ui|{{AUR|connman-ui-git}}}}<br />
* {{App|connman_dmenu|Client/frontend for dmenu.|https://github.com/taylorchu/connman_dmenu|{{AUR|connman_dmenu-git}}}}<br />
* {{App|Econnman|Enlightenment desktop panel applet.|https://www.enlightenment.org|{{AUR|econnman}}}}<br />
* {{App|LXQt-Connman-Applet|LXQt desktop panel applet.|https://github.com/lxqt/lxqt-connman-applet|{{AUR|lxqt-connman-applet}}}}<br />
* {{App|connman-gtk| GTK client.|https://github.com/jgke/connman-gtk|{{AUR|connman-gtk}}}}<br />
* {{App|gnome-extension-connman| Gnome3 extension for connman; it contains only some of the functionality without installing connman-gtk.|https://github.com/jgke/gnome-extension-connman|https://extensions.gnome.org/extension/981/connman-extension/}}<br />
<br />
== Usage ==<br />
<br />
{{Expansion|Only Wired and Wi-Fi plugins are described.}}<br />
<br />
ConnMan comes with the {{ic|connmanctl}} command-line interface, see {{man|1|connmanctl}}.<br />
If you do not provide any commands {{ic|connmanctl}} starts as an interactive shell.<br />
<br />
''ConnMan'' automatically handles wired connections.<br />
<br />
=== Wi-Fi ===<br />
<br />
==== Enabling and disabling wifi ====<br />
<br />
To check if wifi is enabled you can run {{ic|connmanctl technologies}} and check for the line that says {{ic|Powered: True/False}}.<br />
To power the wifi on you can run {{ic|connmanctl enable wifi}} or if you need to disable it you can run {{ic|connmanctl disable wifi}}.<br />
Other ways to enable wifi could include using the {{ic|Fn}} keys on the laptop to turn it on or running {{ic|ip link set <interface> up}}.<br />
<br />
==== Connecting to an open access point ====<br />
<br />
To scan the network {{ic|connmanctl}} accepts simple names called ''technologies''. To scan for nearby Wi-Fi networks:<br />
<br />
$ connmanctl scan wifi<br />
<br />
To list the available networks found after a scan run (example output): <br />
<br />
{{hc|$ connmanctl services|<br />
*AO MyNetwork wifi_dc85de828967_68756773616d_managed_psk<br />
OtherNET wifi_dc85de828967_38303944616e69656c73_managed_psk <br />
AnotherOne wifi_dc85de828967_3257495245363836_managed_wep<br />
FourthNetwork wifi_dc85de828967_4d7572706879_managed_wep<br />
AnOpenNetwork wifi_dc85de828967_4d6568657272696e_managed_none<br />
}}<br />
<br />
To connect to an open network, use the second field beginning with {{ic|wifi_}}:<br />
<br />
$ connmanctl connect wifi_dc85de828967_4d6568657272696e_managed_none<br />
<br />
{{Tip|Network names can be tab-completed.}}<br />
<br />
You should now be connected to the network. Check using {{ic|connmanctl state}} or {{ic|ip addr}}.<br />
<br />
==== Connecting to a protected access point ====<br />
<br />
For protected access points you will need to provide some information to the ConnMan daemon, at the very least a password or a passphrase.<br />
<br />
The commands in this section show how to run {{ic|connmanctl}} in interactive mode, it is required for running the {{ic|agent}} command. To start interactive mode simply type: <br />
<br />
$ connmanctl<br />
<br />
You then proceed almost as above, first scan for any Wi-Fi ''technologies'':<br />
<br />
connmanctl> scan wifi<br />
<br />
To list services:<br />
<br />
connmanctl> services<br />
<br />
Now you need to register the agent to handle user requests. The command is:<br />
<br />
connmanctl> agent on<br />
<br />
You now need to connect to one of the protected services. To do this easily, just use tab completion for the wifi_ service. If you were connecting to OtherNET in the example above you would type:<br />
<br />
connmanctl> connect wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
<br />
The agent will then ask you to provide any information the daemon needs to complete the connection. The <br />
information requested will vary depending on the type of network you are connecting to. The agent<br />
will also print additional data about the information it needs as shown in the example below.<br />
<br />
Agent RequestInput wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
Passphrase = [ Type=psk, Requirement=mandatory ]<br />
Passphrase? <br />
<br />
Provide the information requested, in this example the passphrase, and then type:<br />
<br />
connmanctl> quit<br />
<br />
If the information you provided is correct you should now be connected to the protected access point.<br />
<br />
==== Using iwd instead of wpa_supplicant ====<br />
<br />
ConnMan can use {{pkg|iwd}} to connect to wireless networks. The package which is available in community already supports using {{pkg|iwd}} for connecting to wireless networks. As {{pkg|connman}} will start {{pkg|wpa_supplicant}} when it finds it, it is recommended to uninstall {{pkg|wpa_supplicant}}.<br />
<br />
Currently the {{ic|-i}}-option of {{pkg|iwd}} seems to cause that the WiFi-interface gets hidden from {{pkg|connman}}.<br />
<br />
Create the following two service files which should cause {{pkg|connman}} to use {{pkg|iwd}} to connect to wireless networks, regardless if {{pkg|wpa_supplicant}} is installed.<br />
<br />
{{hc|/etc/systemd/system/iwd.service|output=<br />
[Unit]<br />
Description=Internet Wireless Daemon (IWD)<br />
Before=network.target<br />
Wants=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/lib/iwd/iwd<br />
<br />
[Install]<br />
Alias=multi-user.target.wants/iwd.service<br />
}}<br />
<br />
{{hc|/etc/systemd/system/connman_iwd.service|output=<br />
[Unit]<br />
Description=Connection service<br />
DefaultDependencies=false<br />
Conflicts=shutdown.target<br />
RequiresMountsFor=/var/lib/connman<br />
After=dbus.service network-pre.target systemd-sysusers.service iwd.service<br />
Before=network.target multi-user.target shutdown.target<br />
Wants=network.target<br />
Requires=iwd.service<br />
<br />
[Service]<br />
Type=dbus<br />
BusName=net.connman<br />
Restart=on-failure<br />
ExecStart=/usr/bin/connmand --wifi=iwd_agent -n <br />
StandardOutput=null<br />
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE<br />
ProtectHome=true<br />
ProtectSystem=true<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Then [[enable]]/[[start]] the {{ic|connman_iwd}} service.<br />
<br />
Advantage of using {{pkg|iwd}} instead of {{pkg|wpa_supplicant}} is, that the ping times seem to be much more consistent and the connection seems to be more reliable.<br />
<br />
=== Settings ===<br />
<br />
Settings and profiles are automatically created for networks the user connects to often. They contain fields for the passphrase, essid and other information. Profile settings are stored in directories under {{ic|/var/lib/connman/}} by their service name. To view all network profiles run this command from [[Help:Reading#Regular_user_or_root|root shell]]: <br />
<br />
# cat /var/lib/connman/*/settings<br />
<br />
{{Note|VPN settings can be found in {{ic|/var/lib/connman-vpn/}}.}}<br />
<br />
=== Technologies ===<br />
<br />
Various hardware interfaces are referred to as ''Technologies'' by ConnMan.<br />
<br />
To list available ''technologies'' run: <br />
<br />
$ connmanctl technologies<br />
<br />
To get just the types by their name one can use this one liner:<br />
<br />
$ connmanctl technologies | awk '/Type/ { print $NF }'<br />
<br />
{{Note| The field {{ic|1=Type = tech_name}} provides the technology type used with {{ic|connmanctl}} commands}}<br />
<br />
To interact with them one must refer to the technology by type. ''Technologies'' can be toggled on/off with: <br />
<br />
$ connmanctl enable ''technology_type''<br />
<br />
and:<br />
<br />
$ connmanctl disable ''technology_type''<br />
<br />
For example to toggle off wifi:<br />
<br />
$ connmanctl disable wifi<br />
<br />
{{Warning|connman grabs rfkill events. It is most likely impossible to use {{ic|rfkill}} or {{ic|bluetoothctl}} to (un)block devices, yet hardware keys may still work.[https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/overview-api.txt#n406] Always use {{ic|connmanctl enable{{!}}disable}} }}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Avoid changing the hostname ===<br />
<br />
By default, ConnMan changes the transient hostname (see {{man|1|hostnamectl}}) on a per network basis. This can create problems with X authority: If ConnMan changes your hostname to something else than the one used to generate the xauth magic cookie, then it will become impossible to create new windows. Symptoms are error messages like {{ic|No protocol specified}} and {{ic|Can't open display: :0.0}}. Manually resetting the host name fixes this, but a permanent solution is to prevent ConnMan from changing your host name in the first place. This can be accomplished by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
AllowHostnameUpdates=false<br />
<br />
Make sure to [[restart]] the {{ic|connman.service}} after changing this file.<br />
<br />
For testing purposes it is recommended to watch the [[systemd journal]] and plug the network cable a few times to see the action.<br />
<br />
=== Prefer ethernet to wireless ===<br />
<br />
By default ConnMan does not prefer ethernet over wireless, which can lead to it deciding to stick with a slow wireless network even when ethernet is available. You can tell connman to prefer ethernet adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
PreferredTechnologies=ethernet,wifi<br />
<br />
=== Exclusive connection ===<br />
<br />
ConnMan allows you to be connected to both ethernet and wireless at the same time. This can be useful as it allows programs that established a connection over wifi to stay connected even after you connect to ethernet. But some people prefer to have only a single unambiguous connection active at a time. That behavior can be activated by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
SingleConnectedTechnology=true<br />
<br />
=== Connecting to eduroam (802.1X) ===<br />
<br />
[[WPA2 Enterprise]] networks such as eduroam require a separate configuration file before [[#Wi-Fi|connecting]] to the network. For example, create {{ic|/var/lib/connman/eduroam.config}}:<br />
<br />
{{hc|1=eduroam.config|2=<br />
[service_eduroam]<br />
Type=wifi<br />
Name=eduroam<br />
EAP=peap<br />
CACertFile=/etc/ssl/certs/''certificate.cer''<br />
Phase2=''MSCHAPV2''<br />
Identity=''user@foo.edu''<br />
AnonymousIdentity=''anonymous@foo.edu''<br />
Passphrase=''password''<br />
}}<br />
<br />
[[Restart]] {{ic|wpa_supplicant.service}} and {{ic|connman.service}} to connect to the new network.<br />
<br />
{{Note|<br />
* Options are case-sensitive, e.g. {{ic|1=EAP = ttls}} instead of {{ic|1=EAP = TTLS}}.[https://together.jolla.com/question/55969/connman-fails-due-to-case-sensitive-settings/]<br />
* Consult the institution hosting the eduroam network for various settings such as username, password, {{ic|EAP}}, {{ic|Phase2output}}, and needed certificates.<br />
}}<br />
<br />
For more information, see {{man|5|connman-service.config}} and [[Wireless network configuration#eduroam]].<br />
<br />
=== Avoiding conflicts with local DNS server ===<br />
<br />
If you are running a local DNS server, it will likely have problems binding to port 53 (TCP and/or UDP) after installing Connman. This is because Connman includes its own DNS proxy which also tries to bind to those ports. If you see log messages from [[BIND]] or [[dnsmasq]] like <br />
<br />
named[529]: could not listen on UDP socket: address in use<br />
<br />
this could be the problem. To verify which application is listening on the ports, you can execute {{ic|ss -tulpn}} as root.<br />
<br />
To fix this connmand can be started with the options {{ic|-r}} or {{ic|--nodnsproxy}} by [[Systemd#Editing provided units|overriding]] the systemd service file. Create the folder {{ic|/etc/systemd/system/connman.service.d/}} and add the file {{ic|disable_dns_proxy.conf}}:<br />
<br />
{{hc|/etc/systemd/system/connman.service.d/disable_dns_proxy.conf|2=<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/connmand -n --nodnsproxy<br />
}}<br />
<br />
Make sure to [[reload]] the systemd daemon and [[restart]] the {{ic|connman.service}}, and your DNS proxy, after adding this file.<br />
<br />
=== /etc/resolv.conf ===<br />
<br />
If you want to know the DNS servers received from DHCP while keeping a custom {{ic|/etc/resolv.conf}}, then append {{ic|<nowiki>RuntimeDirectory=connman</nowiki>}} to the above file (clear the {{ic|ExecStart}} lines if not needed). Now connman will write them to {{ic|/var/run/connman/resolv.conf}} instead.<br />
<br />
=== Blacklist interfaces ===<br />
<br />
If something like [[Docker]] is creating virtual interfaces Connman may attempt to connect to one of these instead of your physical adapter if the connection drops. A simple way of avoiding this is to blacklist the interfaces you do not want to use. Connman will by default blacklist interfaces starting with {{ic|vmnet}}, {{ic|vboxnet}}, {{ic|virbr}} and {{ic|ifb}}, so those need to be included in the new blacklist as well.<br />
<br />
Blacklisting interface names is also useful to avoid a race condition where connman may access {{ic|eth#}} or {{ic|wlan#}} before systemd/udev can change it to use a [https://systemd.io/PREDICTABLE_INTERFACE_NAMES/ Predictable Network Interface Names] like {{ic|enp4s0}}. Blacklisting the conventional (and unpredictable) interface prefixes makes connman wait until they are renamed.<br />
<br />
If it does not already exist, create {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth,eth,wlan<br />
<br />
Once {{ic|connman.service}} has been [[systemd#Using units|restarted]] this will also hide all the {{ic|veth#######}} interfaces from GUI tools like Econnman.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Error /net/connman/technology/wifi: Not supported ===<br />
<br />
Currently, connman does not support scanning for WiFi networks with {{Pkg|iwd}}, at the moment this functionality is available with {{ic|wpa_supplicant}} only (see [https://lists.01.org/pipermail/connman/2018-August/022915.html]). To connect to wifi with iwd, [[enable]]/[[start]] {{ic|iwd.service}} and then either follow instructions in [[Iwd]] to connect to the wifi or you can also use any of the [[ConnMan#Front-ends|#Front-ends]]. In order to have Wifi Scanning support from within connman, install {{Pkg|wpa_supplicant}} and then [[restart]] {{ic|connman.service}} after you stop {{ic|iwd.service}}.<br />
<br />
=== Error /net/connman/technology/wifi: No carrier ===<br />
<br />
You have enabled your wifi with:<br />
<br />
$ connmanctl enable wifi<br />
<br />
If wireless scanning leads to above error, this may be due to an unresolved bug.[https://01.org/jira/browse/CM-670]<br />
If it does not resolve even though wireless [https://lists.01.org/pipermail/connman/2014-December/019203.html preconditions] are met, try again after disabling competing network managers and rebooting.<br />
<br />
This may also simply be caused by the wireless interface being blocked by [[rfkill]], which can occur after restarting wpa_supplicant. Use {{ic|rfkill list}} to check.<br />
<br />
=== "Not registered", or "Method "Connect" with signature ... doesn't exist" ===<br />
<br />
When issuing commands, you may see errors like the following:<br />
<br />
From a {{ic|connmanctl}} prompt:<br />
<br />
{{hc|connmanctl> connect ''service_id''|<br />
Error /net/connman/service/''SSID'': Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist<br />
}}<br />
<br />
From the shell:<br />
<br />
{{hc|# connmanctl connect ''service_id''|<br />
Error /net/connman/service/''service_id'': Not registered<br />
}}<br />
<br />
These errors are produced because the agent is not running. Start the agent from a {{ic|connmanctl}} prompt with {{ic|agent on}}, and try again.<br />
<br />
=== Error Failed to set hostname/domainname ===<br />
<br />
connman can failed to set hostname or domainname due to lack of {{ic|CAP_SYS_ADMIN}}.<br />
<br />
You will need to [[edit]] {{ic|connman.service}} (and other like {{ic|connman-vpn.service}} , etc ...) to modify the {{ic|CapabilityBoundingSet}} line to add {{ic|CAP_SYS_ADMIN}}.<br />
<br />
See {{ic|EPERM}} under {{man|2|sethostname|ERRORS}} or {{man|2|setdomainname|ERRORS}} for more details.<br />
<br />
=== Unknown route on connection ===<br />
<br />
A log entry for an unknown route appears each time a connect is done. For example: <br />
<br />
...<br />
connmand[473]: wlp2s0 {add} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
connmand[473]: wlp2s0 {del} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
...<br />
<br />
It likely is Connman performing a connectivity check to the ipv4.connman.net host (which resolves to the IP address {{ic|82.165.8.211}} at current).[https://01.org/jira/browse/CM-657] See the [https://git.kernel.org/pub/scm/network/connman/connman.git/tree/README#n388 Connman README] for more information on why and what - apart from the connecting IP - it transmits.<br />
This behaviour can be prevented by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
EnableOnlineCheck=false<br />
<br />
This setting will cause that the default device will not switch to ONLINE, but stay in READY state.{{man|5|connman.conf}} However, the connection will still be functional.<br />
<br />
The connection itself is also functional (unless behind a captive portal) if the check is blocked by a firewall rule: <br />
<br />
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT<br />
# iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT<br />
<br />
=== File /proc/net/pnp doesn't exist ===<br />
<br />
If you see this in your error log it is caused by bug in connman [https://bbs.archlinux.org/viewtopic.php?id=227689#p1766928] and can be ignored. [https://01.org/jira/browse/CM-690 Bug Report]<br />
<br />
== See also ==<br />
<br />
* [https://git.kernel.org/cgit/network/connman/connman.git/tree/doc Git repository documentation] — for further detailed documentation</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Domain_name_resolution&diff=722526Domain name resolution2022-03-11T18:04:21Z<p>RaZorr: Add new ConnMan#/etc/resolv.conf point</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Network configuration]]<br />
[[de:Resolv.conf]]<br />
[[fr:Domain name resolution]]<br />
[[ja:ドメイン名前解決]]<br />
[[pt:Domain name resolution]]<br />
[[ru:Domain name resolution]]<br />
[[zh-hans:Domain name resolution]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|DNS over HTTPS servers}}<br />
{{Related articles end}}<br />
In general, a [[Wikipedia:Domain name|domain name]] represents an IP address and is associated to it in the [[Wikipedia:Domain Name System|Domain Name System]] (DNS).<br />
This article explains how to configure domain name resolution and resolve domain names.<br />
<br />
== Name Service Switch ==<br />
<br />
{{Expansion|Mention {{Pkg|nss-mdns}}, {{AUR|nss-tls-git}} and others.}}<br />
<br />
The [[Wikipedia:Name Service Switch|Name Service Switch]] (NSS) facility is part of the GNU C Library ({{Pkg|glibc}}) and backs the {{man|3|getaddrinfo}} API, used to resolve domain names. NSS allows system databases to be provided by separate services, whose search order can be configured by the administrator in {{man|5|nsswitch.conf}}. The database responsible for domain name resolution is the ''hosts'' database, for which glibc offers the following services:<br />
<br />
* ''files'': reads the {{ic|/etc/hosts}} file, see {{man|5|hosts}}<br />
* ''dns'': the [[#Glibc resolver|glibc resolver]] which reads {{ic|/etc/resolv.conf}}, see {{man|5|resolv.conf}}<br />
<br />
[[systemd]] provides three NSS services for hostname resolution:<br />
<br />
* {{man|8|nss-resolve}} — a caching DNS stub resolver, described in [[systemd-resolved]]<br />
* {{man|8|nss-myhostname}} — provides local hostname resolution without having to edit {{ic|/etc/hosts}}, described in [[Network configuration#Local hostname resolution]]<br />
* {{man|8|nss-mymachines}} — provides hostname resolution for the names of local {{man|8|systemd-machined}} containers<br />
<br />
=== Resolve a domain name using NSS ===<br />
<br />
NSS databases can be queried with {{man|1|getent}}. A domain name can be resolved through NSS using:<br />
<br />
$ getent hosts ''domain_name''<br />
<br />
{{Note|While most programs resolve domain names using NSS, some may read {{ic|/etc/resolv.conf}} and/or {{ic|/etc/hosts}} directly. See [[Network configuration#Local hostname resolution]].}}<br />
<br />
== Glibc resolver ==<br />
<br />
The glibc resolver reads {{ic|/etc/resolv.conf}} for every resolution to determine the nameservers and options to use. <br />
<br />
{{man|5|resolv.conf}} lists nameservers together with some configuration options.<br />
Nameservers listed first are tried first, up to three nameservers may be listed. Lines starting with a number sign ({{ic|#}}) are ignored.<br />
<br />
{{Note|The glibc resolver does not cache queries. To improve query lookup time you can set up a caching resolver. Glibc resolver also can not validate DNSSEC. A DNSSEC capable validator resolver is required for that one. See [[#DNS servers]] for more information.}}<br />
<br />
=== Overwriting of /etc/resolv.conf ===<br />
<br />
[[Network manager]]s tend to overwrite {{ic|/etc/resolv.conf}}, for specifics see the corresponding section:<br />
<br />
* [[dhcpcd#/etc/resolv.conf]]<br />
* [[Netctl#/etc/resolv.conf]]<br />
* [[NetworkManager#/etc/resolv.conf]]<br />
* [[ConnMan#/etc/resolv.conf]]<br />
<br />
To prevent programs from overwriting {{ic|/etc/resolv.conf}}, it is also possible to write-protect it by setting the immutable [[file attribute]]:<br />
<br />
# chattr +i /etc/resolv.conf<br />
<br />
{{Tip|If you want multiple processes to write to {{ic|/etc/resolv.conf}}, you can use [[resolvconf]].}}<br />
<br />
=== Limit lookup time ===<br />
<br />
If you are confronted with a very long hostname lookup (may it be in [[pacman]] or while browsing), it often helps to define a small timeout after which an alternative nameserver is used. To do so, put the following in {{ic|/etc/resolv.conf}}.<br />
<br />
options timeout:1<br />
<br />
=== Hostname lookup delayed with IPv6 ===<br />
<br />
If you experience a 5 second delay when resolving hostnames it might be due to a DNS-server/Firewall misbehaving and only giving one reply to a parallel A and AAAA request.[https://udrepper.livejournal.com/20948.html] You can fix that by setting the following option in {{ic|/etc/resolv.conf}}:<br />
<br />
options single-request<br />
<br />
=== Local domain names ===<br />
<br />
To be able to use the hostname of local machine names without the fully qualified domain name, add a line to {{ic|/etc/resolv.conf}} with the local domain such as:<br />
domain example.org<br />
That way you can refer to local hosts such as {{ic|mainmachine1.example.org}} as simply {{ic|mainmachine1}} when using the ''ssh'' command, but the [[#Lookup utilities|drill]] command still requires the fully qualified domain names in order to perform lookups.<br />
<br />
== Lookup utilities ==<br />
<br />
To query specific DNS servers and DNS/[[DNSSEC]] records you can use dedicated DNS lookup utilities. These tools implement DNS themselves and do not use [[#Name Service Switch|NSS]].<br />
<br />
{{Pkg|ldns}} provides {{man|1|drill}}, which is a tool designed to retrieve information out of the DNS.<br />
<br />
For example, to query a specific nameserver with ''drill'' for the TXT records of a domain:<br />
<br />
$ drill @''nameserver'' TXT ''domain''<br />
<br />
Unless a DNS server is specified, ''drill'' will use the nameservers defined in {{ic|/etc/resolv.conf}}.<br />
<br />
{{Tip|Some DNS servers ship with their own DNS lookup utilities. E.g.<br />
<br />
* {{Pkg|knot}} provides {{man|1|khost}} and {{man|1|kdig}}.<br />
* [[Unbound]] has {{man|1|unbound-host}}.<br />
* [[BIND]] has {{man|1|dig}}, {{man|1|host}}, {{man|1|nslookup}} and a bunch of {{ic|dnssec-}} tools.<br />
<br />
}}<br />
<br />
== Resolver performance ==<br />
<br />
The Glibc resolver does not cache queries. To implement local caching, use [[systemd-resolved]] or set up a local caching [[#DNS servers|DNS server]] and use it as the name server by setting {{ic|127.0.0.1}} and {{ic|::1}} as the name servers in {{ic|/etc/resolv.conf}} or in {{ic|/etc/resolvconf.conf}} if using [[openresolv]].<br />
<br />
{{Tip|<br />
* The ''drill'' or ''dig'' [[#Lookup utilities|lookup utilities]] report the query time.<br />
* A router usually sets its own caching resolver as the network's DNS server thus providing DNS cache for the whole network. <br />
* If it takes too long to switch to the next DNS server you can try [[#Limit lookup time|decreasing the timeout]].}}<br />
<br />
== Privacy and security ==<br />
<br />
The DNS protocol is unencrypted and does not account for confidentiality, integrity or authentication, so if you use an untrusted network or a malicious ISP, your DNS queries can be eavesdropped and the responses [[Wikipedia:Man-in-the-middle attack|manipulated]]. Furthermore, DNS servers can conduct [[Wikipedia:DNS hijacking|DNS hijacking]].<br />
<br />
You need to trust your DNS server to treat your queries confidentially. DNS servers are provided by ISPs and [[#Third-party DNS services|third-parties]]. Alternatively you can run your own [[#DNS servers|recursive name server]], which however takes more effort. If you use a [[DHCP]] client in untrusted networks, be sure to set static name servers to avoid using and being subject to arbitrary DNS servers. To secure your communication with a remote DNS server you can use an encrypted protocol, like [[Wikipedia:DNS over TLS|DNS over TLS]] ([[RFC:7858|RFC 7858]]), [[Wikipedia:DNS over HTTPS|DNS over HTTPS]] ([[RFC:8484|RFC 8484]]), or [[Wikipedia:DNSCrypt|DNSCrypt]], provided that both the upstream server and your [[#DNS servers|resolver]] support the protocol. An alternative can be a dedicated software to encrypt and decrypt the communication, such as [[stunnel]]. To verify that responses are actually from [[Wikipedia:Authoritative name server|authoritative name servers]], you can validate [[DNSSEC]], provided that both the upstream server(s) and your [[#DNS servers|resolver]] support it.<br />
<br />
=== Application-level DNS ===<br />
<br />
Be aware that some client software, such as major web browsers[https://support.mozilla.org/en-US/kb/firefox-dns-over-https][https://www.chromium.org/developers/dns-over-https], are starting to implement DNS over HTTPS. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/]<br />
<br />
[[Firefox]] provides [https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_manually-enabling-and-disabling-dns-over-https configuration options] to enable or disable DNS over HTTPS and select a DNS server.<br />
<br />
[[Chromium]] will examine the user's system resolver and enable DNS over HTTPS if the system resolver addresses are known to also provide DNS over HTTPS. See [https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html this blog post] for more information and how DNS over HTTPS can be disabled.<br />
<br />
Mozilla [https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https has proposed] universally disabling application-level DNS if the system resolver cannot resolve the domain {{ic|use-application-dns.net}}. Currently, this is only implemented in Firefox.<br />
<br />
=== Oblivious DNS ===<br />
<br />
[https://odns.cs.princeton.edu/ Oblivious DNS] is a system which addresses a number of DNS privacy concerns. See [https://blog.cloudflare.com/oblivious-dns/ Cloudflare's article] for more information.<br />
<br />
== Third-party DNS services ==<br />
<br />
{{Note|Before using a third-party DNS service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties.}}<br />
<br />
There are various [[Wikipedia:Public recursive name server#List of public DNS service operators|third-party DNS services]] available, some of which also have dedicated software:<br />
<br />
* {{App|[[cloudflared]]|A DNS client for Cloudflare DNS over HTTPS|https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy|{{AUR|cloudflared}}, {{AUR|cloudflared-bin}}}}<br />
* {{App|dingo|A DNS client for Google DNS over HTTPS|https://github.com/pforemski/dingo|{{AUR|dingo-git}}}}<br />
* {{App|opennic-up|Automates the renewal of the DNS servers with the most responsive OpenNIC servers|https://github.com/kewlfft/opennic-up|{{AUR|opennic-up}}}}<br />
* {{App|nextdns|A DNS-over-HTTPS CLI client for NextDNS|https://github.com/nextdns/nextdns|{{AUR|nextdns}}}}<br />
<br />
You can use [https://github.com/cleanbrowsing/dnsperftest dnsperftest] to test the performance of the most popular DNS resolvers from your location. [https://www.dnsperf.com/#!dns-resolvers dnsperf.com] provides global benchmarks between providers.<br />
<br />
== DNS servers ==<br />
<br />
DNS servers can be [[Wikipedia:Authoritative name server|authoritative]] and [[Wikipedia:Name server#Recursive query|recursive]]. If they are neither, they are called '''stub resolvers''' and simply forward all queries to another recursive name server. Stub resolvers are typically used to introduce DNS caching on the local host or network. Note that the same can also be achieved with a fully-fledged name server. This section compares the available DNS servers, for a more detailed comparison, refer to [[Wikipedia:Comparison of DNS server software]].<br />
<br />
{{Expansion|Fill in the unknowns.}}<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
! rowspan=2 | Name !! rowspan=2 | Package !! colspan=4 | Capabilities !! rowspan=2 | [[resolvconf]] !! colspan=4 | Supported protocols<br />
|-<br />
! [[Wikipedia:Authoritative name server|Authoritative]] !! [[Wikipedia:Name server#Recursive query|Recursive]] !! [[Wikipedia:Name server#Caching name server|Cache]] !! [[Wikipedia:Domain Name System Security Extensions#The lookup procedure|Validates]]<br>[[DNSSEC]] !! [[Wikipedia:Domain Name System|DNS]] !! [[Wikipedia:DNSCrypt|DNSCrypt]] !! [[Wikipedia:DNS over TLS|DNS<br>over TLS]] !! [[Wikipedia:DNS over HTTPS|DNS<br>over HTTPS]]<br />
|-<br />
! [[BIND]]<br />
| {{Pkg|bind}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{G|[[openresolv#Subscribers|Yes]]}} || {{Yes}} || {{No}} || {{Y|Server<sup>1</sup>}} || {{Y|Server}}<br />
|-<br />
! [[CoreDNS]]<br />
| {{AUR|coredns}} or {{AUR|coredns-bin}} || ? || ? || ? || ? || ? || ? || ? || {{Yes}} || ?<br />
|-<br />
! [https://maradns.samiam.org/deadwood/doc/Deadwood.html Deadwood] ([[Wikipedia:MaraDNS|MaraDNS]] recursor)<br />
| {{AUR|maradns}} || {{No}} || {{Yes}} || {{Yes}} || {{No}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
! [[dnscrypt-proxy]]<br />
| {{Pkg|dnscrypt-proxy}} || {{No}} || {{No}} || {{Yes}} || {{No}} || {{No}} || {{Y|Server}} || {{Y|Resolver}} || {{No}} || {{Yes}}<br />
|-<br />
! [[dnsmasq]]<br />
| {{Pkg|dnsmasq}} || {{Y|Partial}}<sup>2</sup> || {{No}} || {{Yes}} || {{Yes}} || {{G|[[openresolv#Subscribers|Yes]]}} || {{Yes}} || {{No}} || {{No|https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012131.html}} || {{No}}<br />
|-<br />
! [[Knot Resolver]]<br />
| {{Pkg|knot-resolver}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{No}} || {{Yes}} || {{No}} || {{Yes}} || {{Y|[https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-net_tlssrv.html#dns-over-https-doh Server]}}<br />
|-<br />
! [[pdnsd]]<br />
| {{Pkg|pdnsd}} || {{Yes}} || {{Yes}} || {{G|Permanent}} || {{No}} || {{G|[[openresolv#Subscribers|Yes]]}} || {{Yes}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
! [[Wikipedia:PowerDNS#Recursor|PowerDNS Recursor]]<br />
| {{Pkg|powerdns-recursor}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{G|[[openresolv#Subscribers|Yes]]}} || {{Yes}} || {{No}} || {{No}} || {{No}}<br />
|-<br />
! [[Rescached]]<br />
| {{AUR|rescached-git}} || {{No}} || {{No}} || {{Yes}} || {{No}} || {{Yes|https://github.com/shuLhan/rescached-go#integration-with-openresolv}} || {{Yes}} || {{No}} || {{Yes}} || {{Yes}}<br />
|-<br />
! [https://github.com/pymumu/smartdns SmartDNS]<br />
| {{Pkg|smartdns}} || {{No}} || {{No}} || {{Yes}} || {{No|https://github.com/pymumu/smartdns/issues/19}} || ? || {{Yes}} || {{No}} || {{Y|Resolver}} || {{Y|Resolver}}<br />
|-<br />
! [[Stubby]]<br />
| {{Pkg|stubby}} || {{No}} || {{No}} || {{No}} || {{Yes}} || {{No}} || {{Y|Server}} || {{No}} || {{Y|Resolver}} || {{No|https://github.com/getdnsapi/stubby/issues/278}}<br />
|-<br />
!style="white-space: nowrap;"| [[systemd-resolved]]<br />
| {{Pkg|systemd}} || {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{G|[[systemd-resolvconf|Yes]]}} || {{Y|Resolver and [https://github.com/systemd/systemd/issues/4621#issuecomment-260050033 limited server]}} || {{No}} || {{Y|Resolver}} || {{No|https://github.com/systemd/systemd/issues/8639}}<br />
|-<br />
! [[Unbound]]<br />
| {{Pkg|unbound}} || {{Y|Partial}} || {{Yes}} || {{Yes}}<sup>3</sup> || {{Yes}} || {{G|[[openresolv#Subscribers|Yes]]}} || {{Yes}} || {{Y|Server}} || {{Yes}} || {{Y|[https://github.com/NLnetLabs/unbound/issues/308 Server]}}<br />
|}<br />
<br />
# BIND can serve both DNS over TLS and DNS over HTTPS (see [https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/reference.html#tls tls{}] and [https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/reference.html#interfaces listen-on]), but cannot yet forward queries to a DNS over TLS/DNS over HTTPS upstream. The ''dig'' tool can make queries over DNS over TLS and DNS over HTTPS (using {{ic|+tls}} and {{ic|+https}} options), though [https://gitlab.isc.org/isc-projects/bind9/-/issues/3163 without any certificate checks].<br />
# From [[Wikipedia:Comparison of DNS server software#cite_note-masqauth-32|Wikipedia]]: dnsmasq has limited authoritative support, intended for internal network use rather than public Internet use.<br />
# The [[Redis]] backend can be used to provide a persistent cache for Unbound.<br />
<br />
=== Authoritative-only servers ===<br />
<br />
{| class="wikitable sortable" style="text-align:center"<br />
! Name !! Package !! [[DNSSEC]] !! Geographic<br>balancing<br />
|-<br />
! gdnsd<br />
| {{Pkg|gdnsd}} || {{No}} || {{Yes}}<br />
|-<br />
! [[Wikipedia:Knot DNS|Knot DNS]]<br />
| {{Pkg|knot}} || {{Yes}} || {{Yes|https://www.knot-dns.cz/docs/2.7/singlehtml/#geoip-geography-based-responses}}<br />
|-<br />
! [[Wikipedia:MaraDNS|MaraDNS]]<br />
| {{AUR|maradns}} || {{No}} || ?<br />
|-<br />
! [[NSD]]<br />
| {{Pkg|nsd}} || {{No}} || {{No}}<br />
|-<br />
! [[PowerDNS]]<br />
| {{Pkg|powerdns}} || {{Yes}} || {{Yes}}<br />
|}<br />
<br />
=== Conditional forwarding ===<br />
<br />
It is possible to use specific DNS resolvers when querying specific domain names. This is particularly useful when connecting to a VPN, so that queries to the VPN network are resolved by the VPN's DNS, while queries to the internet will still be resolved by your standard DNS resolver. It can also be used on local networks.<br />
<br />
To implement it, you need to use a [[#DNS servers|local resolver]] because glibc does not support it.<br />
<br />
In a dynamic environment (laptops and to some extents desktops), you need to configure your resolver based on the network(s) you are connected to. The best way to do that is to use [[openresolv]] because it supports [[openresolv#Subscribers|multiple subscribers]]. Some [[network manager]]s support it, either through openresolv, or by configuring the resolver directly. NetworkManager [[NetworkManager#DNS caching and conditional forwarding|supports conditional forwarding without openresolv]].<br />
<br />
{{Note|Although you could use other conditions for forwarding (for example, source IP address), "conditional forwarding" appears to be the name used for the "domain queried" condition.}}<br />
<br />
== See also ==<br />
<br />
* [https://www.tldp.org/LDP/nag2/x-087-2-resolv.html Linux Network Administrators Guide]<br />
* [https://www.debian.org/doc/manuals/debian-handbook/sect.hostname-name-service.en.html#sect.name-resolution Debian Handbook]<br />
* [[RFC:7706]] - Decreasing Access Time to Root Servers by Running One on Loopback<br />
* [http://linux-ip.net/pages/diagrams.html#domain-name-system-overview Domain name system overview] - Diagram about DNS<br />
* [[Alternative DNS services]]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=ConnMan&diff=722524ConnMan2022-03-11T18:03:09Z<p>RaZorr: separate dns conflict section into etc/resolv.conf section to put in Domain_name_resolution#Overwriting_of_/etc/resolv.conf</p>
<hr />
<div>[[Category:Network managers]]<br />
[[ja:ConnMan]]<br />
[[zh-hans:ConnMan]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
<br />
[https://web.archive.org/web/20210224075615/https://01.org/connman ConnMan] is a command-line network manager designed for use with embedded devices and fast resolve times. It is modular through a [https://git.kernel.org/cgit/network/connman/connman.git/tree/plugins plugin architecture], but has native [[Wikipedia:DHCP|DHCP]] and [[NTP]] support.[https://git.kernel.org/cgit/network/connman/connman.git/tree/src/]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|connman}} package. {{Pkg|wpa_supplicant}}, {{Pkg|bluez}}, and {{pkg|openvpn}} are optional dependencies required for Wi-Fi, Bluetooth, and VPN functionality respectively.<br />
<br />
Before [[enabling]] {{ic|connman.service}}, ensure any existing [[network configuration]] is disabled.<br />
<br />
ConnMan comes with the {{man|1|connmanctl}} CLI, there are various [[#Front-ends]] available.<br />
<br />
=== Front-ends ===<br />
<br />
* {{App|cmst|Qt GUI for ConnMan.|https://github.com/andrew-bibb/cmst|{{AUR|cmst}}}}<br />
* {{App|connman-ncurses|Simple ncurses UI for ConnMan; not all of connman functionality is implemented, but usable (with X or from terminal without X), see the [https://github.com/eurogiciel-oss/connman-json-client/wiki wiki].|https://github.com/eurogiciel-oss/connman-json-client|{{AUR|connman-ncurses-git}}}}<br />
* {{App|ConnMan-UI|GTK3 client applet.|https://github.com/tbursztyka/connman-ui|{{AUR|connman-ui-git}}}}<br />
* {{App|connman_dmenu|Client/frontend for dmenu.|https://github.com/taylorchu/connman_dmenu|{{AUR|connman_dmenu-git}}}}<br />
* {{App|Econnman|Enlightenment desktop panel applet.|https://www.enlightenment.org|{{AUR|econnman}}}}<br />
* {{App|LXQt-Connman-Applet|LXQt desktop panel applet.|https://github.com/lxqt/lxqt-connman-applet|{{AUR|lxqt-connman-applet}}}}<br />
* {{App|connman-gtk| GTK client.|https://github.com/jgke/connman-gtk|{{AUR|connman-gtk}}}}<br />
* {{App|gnome-extension-connman| Gnome3 extension for connman; it contains only some of the functionality without installing connman-gtk.|https://github.com/jgke/gnome-extension-connman|https://extensions.gnome.org/extension/981/connman-extension/}}<br />
<br />
== Usage ==<br />
<br />
{{Expansion|Only Wired and Wi-Fi plugins are described.}}<br />
<br />
ConnMan comes with the {{ic|connmanctl}} command-line interface, see {{man|1|connmanctl}}.<br />
If you do not provide any commands {{ic|connmanctl}} starts as an interactive shell.<br />
<br />
''ConnMan'' automatically handles wired connections.<br />
<br />
=== Wi-Fi ===<br />
<br />
==== Enabling and disabling wifi ====<br />
<br />
To check if wifi is enabled you can run {{ic|connmanctl technologies}} and check for the line that says {{ic|Powered: True/False}}.<br />
To power the wifi on you can run {{ic|connmanctl enable wifi}} or if you need to disable it you can run {{ic|connmanctl disable wifi}}.<br />
Other ways to enable wifi could include using the {{ic|Fn}} keys on the laptop to turn it on or running {{ic|ip link set <interface> up}}.<br />
<br />
==== Connecting to an open access point ====<br />
<br />
To scan the network {{ic|connmanctl}} accepts simple names called ''technologies''. To scan for nearby Wi-Fi networks:<br />
<br />
$ connmanctl scan wifi<br />
<br />
To list the available networks found after a scan run (example output): <br />
<br />
{{hc|$ connmanctl services|<br />
*AO MyNetwork wifi_dc85de828967_68756773616d_managed_psk<br />
OtherNET wifi_dc85de828967_38303944616e69656c73_managed_psk <br />
AnotherOne wifi_dc85de828967_3257495245363836_managed_wep<br />
FourthNetwork wifi_dc85de828967_4d7572706879_managed_wep<br />
AnOpenNetwork wifi_dc85de828967_4d6568657272696e_managed_none<br />
}}<br />
<br />
To connect to an open network, use the second field beginning with {{ic|wifi_}}:<br />
<br />
$ connmanctl connect wifi_dc85de828967_4d6568657272696e_managed_none<br />
<br />
{{Tip|Network names can be tab-completed.}}<br />
<br />
You should now be connected to the network. Check using {{ic|connmanctl state}} or {{ic|ip addr}}.<br />
<br />
==== Connecting to a protected access point ====<br />
<br />
For protected access points you will need to provide some information to the ConnMan daemon, at the very least a password or a passphrase.<br />
<br />
The commands in this section show how to run {{ic|connmanctl}} in interactive mode, it is required for running the {{ic|agent}} command. To start interactive mode simply type: <br />
<br />
$ connmanctl<br />
<br />
You then proceed almost as above, first scan for any Wi-Fi ''technologies'':<br />
<br />
connmanctl> scan wifi<br />
<br />
To list services:<br />
<br />
connmanctl> services<br />
<br />
Now you need to register the agent to handle user requests. The command is:<br />
<br />
connmanctl> agent on<br />
<br />
You now need to connect to one of the protected services. To do this easily, just use tab completion for the wifi_ service. If you were connecting to OtherNET in the example above you would type:<br />
<br />
connmanctl> connect wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
<br />
The agent will then ask you to provide any information the daemon needs to complete the connection. The <br />
information requested will vary depending on the type of network you are connecting to. The agent<br />
will also print additional data about the information it needs as shown in the example below.<br />
<br />
Agent RequestInput wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
Passphrase = [ Type=psk, Requirement=mandatory ]<br />
Passphrase? <br />
<br />
Provide the information requested, in this example the passphrase, and then type:<br />
<br />
connmanctl> quit<br />
<br />
If the information you provided is correct you should now be connected to the protected access point.<br />
<br />
==== Using iwd instead of wpa_supplicant ====<br />
<br />
ConnMan can use {{pkg|iwd}} to connect to wireless networks. The package which is available in community already supports using {{pkg|iwd}} for connecting to wireless networks. As {{pkg|connman}} will start {{pkg|wpa_supplicant}} when it finds it, it is recommended to uninstall {{pkg|wpa_supplicant}}.<br />
<br />
Currently the {{ic|-i}}-option of {{pkg|iwd}} seems to cause that the WiFi-interface gets hidden from {{pkg|connman}}.<br />
<br />
Create the following two service files which should cause {{pkg|connman}} to use {{pkg|iwd}} to connect to wireless networks, regardless if {{pkg|wpa_supplicant}} is installed.<br />
<br />
{{hc|/etc/systemd/system/iwd.service|output=<br />
[Unit]<br />
Description=Internet Wireless Daemon (IWD)<br />
Before=network.target<br />
Wants=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/lib/iwd/iwd<br />
<br />
[Install]<br />
Alias=multi-user.target.wants/iwd.service<br />
}}<br />
<br />
{{hc|/etc/systemd/system/connman_iwd.service|output=<br />
[Unit]<br />
Description=Connection service<br />
DefaultDependencies=false<br />
Conflicts=shutdown.target<br />
RequiresMountsFor=/var/lib/connman<br />
After=dbus.service network-pre.target systemd-sysusers.service iwd.service<br />
Before=network.target multi-user.target shutdown.target<br />
Wants=network.target<br />
Requires=iwd.service<br />
<br />
[Service]<br />
Type=dbus<br />
BusName=net.connman<br />
Restart=on-failure<br />
ExecStart=/usr/bin/connmand --wifi=iwd_agent -n <br />
StandardOutput=null<br />
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE<br />
ProtectHome=true<br />
ProtectSystem=true<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Then [[enable]]/[[start]] the {{ic|connman_iwd}} service.<br />
<br />
Advantage of using {{pkg|iwd}} instead of {{pkg|wpa_supplicant}} is, that the ping times seem to be much more consistent and the connection seems to be more reliable.<br />
<br />
=== Settings ===<br />
<br />
Settings and profiles are automatically created for networks the user connects to often. They contain fields for the passphrase, essid and other information. Profile settings are stored in directories under {{ic|/var/lib/connman/}} by their service name. To view all network profiles run this command from [[Help:Reading#Regular_user_or_root|root shell]]: <br />
<br />
# cat /var/lib/connman/*/settings<br />
<br />
{{Note|VPN settings can be found in {{ic|/var/lib/connman-vpn/}}.}}<br />
<br />
=== Technologies ===<br />
<br />
Various hardware interfaces are referred to as ''Technologies'' by ConnMan.<br />
<br />
To list available ''technologies'' run: <br />
<br />
$ connmanctl technologies<br />
<br />
To get just the types by their name one can use this one liner:<br />
<br />
$ connmanctl technologies | awk '/Type/ { print $NF }'<br />
<br />
{{Note| The field {{ic|1=Type = tech_name}} provides the technology type used with {{ic|connmanctl}} commands}}<br />
<br />
To interact with them one must refer to the technology by type. ''Technologies'' can be toggled on/off with: <br />
<br />
$ connmanctl enable ''technology_type''<br />
<br />
and:<br />
<br />
$ connmanctl disable ''technology_type''<br />
<br />
For example to toggle off wifi:<br />
<br />
$ connmanctl disable wifi<br />
<br />
{{Warning|connman grabs rfkill events. It is most likely impossible to use {{ic|rfkill}} or {{ic|bluetoothctl}} to (un)block devices, yet hardware keys may still work.[https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/overview-api.txt#n406] Always use {{ic|connmanctl enable{{!}}disable}} }}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Avoid changing the hostname ===<br />
<br />
By default, ConnMan changes the transient hostname (see {{man|1|hostnamectl}}) on a per network basis. This can create problems with X authority: If ConnMan changes your hostname to something else than the one used to generate the xauth magic cookie, then it will become impossible to create new windows. Symptoms are error messages like {{ic|No protocol specified}} and {{ic|Can't open display: :0.0}}. Manually resetting the host name fixes this, but a permanent solution is to prevent ConnMan from changing your host name in the first place. This can be accomplished by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
AllowHostnameUpdates=false<br />
<br />
Make sure to [[restart]] the {{ic|connman.service}} after changing this file.<br />
<br />
For testing purposes it is recommended to watch the [[systemd journal]] and plug the network cable a few times to see the action.<br />
<br />
=== Prefer ethernet to wireless ===<br />
<br />
By default ConnMan does not prefer ethernet over wireless, which can lead to it deciding to stick with a slow wireless network even when ethernet is available. You can tell connman to prefer ethernet adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
PreferredTechnologies=ethernet,wifi<br />
<br />
=== Exclusive connection ===<br />
<br />
ConnMan allows you to be connected to both ethernet and wireless at the same time. This can be useful as it allows programs that established a connection over wifi to stay connected even after you connect to ethernet. But some people prefer to have only a single unambiguous connection active at a time. That behavior can be activated by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
SingleConnectedTechnology=true<br />
<br />
=== Connecting to eduroam (802.1X) ===<br />
<br />
[[WPA2 Enterprise]] networks such as eduroam require a separate configuration file before [[#Wi-Fi|connecting]] to the network. For example, create {{ic|/var/lib/connman/eduroam.config}}:<br />
<br />
{{hc|1=eduroam.config|2=<br />
[service_eduroam]<br />
Type=wifi<br />
Name=eduroam<br />
EAP=peap<br />
CACertFile=/etc/ssl/certs/''certificate.cer''<br />
Phase2=''MSCHAPV2''<br />
Identity=''user@foo.edu''<br />
AnonymousIdentity=''anonymous@foo.edu''<br />
Passphrase=''password''<br />
}}<br />
<br />
[[Restart]] {{ic|wpa_supplicant.service}} and {{ic|connman.service}} to connect to the new network.<br />
<br />
{{Note|<br />
* Options are case-sensitive, e.g. {{ic|1=EAP = ttls}} instead of {{ic|1=EAP = TTLS}}.[https://together.jolla.com/question/55969/connman-fails-due-to-case-sensitive-settings/]<br />
* Consult the institution hosting the eduroam network for various settings such as username, password, {{ic|EAP}}, {{ic|Phase2output}}, and needed certificates.<br />
}}<br />
<br />
For more information, see {{man|5|connman-service.config}} and [[Wireless network configuration#eduroam]].<br />
<br />
=== Avoiding conflicts with local DNS server ===<br />
<br />
If you are running a local DNS server, it will likely have problems binding to port 53 (TCP and/or UDP) after installing Connman. This is because Connman includes its own DNS proxy which also tries to bind to those ports. If you see log messages from [[BIND]] or [[dnsmasq]] like <br />
<br />
named[529]: could not listen on UDP socket: address in use<br />
<br />
this could be the problem. To verify which application is listening on the ports, you can execute {{ic|ss -tulpn}} as root.<br />
<br />
To fix this connmand can be started with the options {{ic|-r}} or {{ic|--nodnsproxy}} by [[Systemd#Editing provided units|overriding]] the systemd service file. Create the folder {{ic|/etc/systemd/system/connman.service.d/}} and add the file {{ic|disable_dns_proxy.conf}}:<br />
<br />
{{hc|/etc/systemd/system/connman.service.d/disable_dns_proxy.conf|2=<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/connmand -n --nodnsproxy<br />
}}<br />
<br />
=== /etc/resolv.conf ===<br />
<br />
If you want to know the DNS servers received from DHCP while keeping a custom {{ic|/etc/resolv.conf}}, then append {{ic|<nowiki>RuntimeDirectory=connman</nowiki>}} to the above file (clear the {{ic|ExecStart}} lines if not needed). Now connman will write them to {{ic|/var/run/connman/resolv.conf}} instead.<br />
<br />
Make sure to [[reload]] the systemd daemon and [[restart]] the {{ic|connman.service}}, and your DNS proxy, after adding this file.<br />
<br />
=== Blacklist interfaces ===<br />
<br />
If something like [[Docker]] is creating virtual interfaces Connman may attempt to connect to one of these instead of your physical adapter if the connection drops. A simple way of avoiding this is to blacklist the interfaces you do not want to use. Connman will by default blacklist interfaces starting with {{ic|vmnet}}, {{ic|vboxnet}}, {{ic|virbr}} and {{ic|ifb}}, so those need to be included in the new blacklist as well.<br />
<br />
Blacklisting interface names is also useful to avoid a race condition where connman may access {{ic|eth#}} or {{ic|wlan#}} before systemd/udev can change it to use a [https://systemd.io/PREDICTABLE_INTERFACE_NAMES/ Predictable Network Interface Names] like {{ic|enp4s0}}. Blacklisting the conventional (and unpredictable) interface prefixes makes connman wait until they are renamed.<br />
<br />
If it does not already exist, create {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth,eth,wlan<br />
<br />
Once {{ic|connman.service}} has been [[systemd#Using units|restarted]] this will also hide all the {{ic|veth#######}} interfaces from GUI tools like Econnman.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Error /net/connman/technology/wifi: Not supported ===<br />
<br />
Currently, connman does not support scanning for WiFi networks with {{Pkg|iwd}}, at the moment this functionality is available with {{ic|wpa_supplicant}} only (see [https://lists.01.org/pipermail/connman/2018-August/022915.html]). To connect to wifi with iwd, [[enable]]/[[start]] {{ic|iwd.service}} and then either follow instructions in [[Iwd]] to connect to the wifi or you can also use any of the [[ConnMan#Front-ends|#Front-ends]]. In order to have Wifi Scanning support from within connman, install {{Pkg|wpa_supplicant}} and then [[restart]] {{ic|connman.service}} after you stop {{ic|iwd.service}}.<br />
<br />
=== Error /net/connman/technology/wifi: No carrier ===<br />
<br />
You have enabled your wifi with:<br />
<br />
$ connmanctl enable wifi<br />
<br />
If wireless scanning leads to above error, this may be due to an unresolved bug.[https://01.org/jira/browse/CM-670]<br />
If it does not resolve even though wireless [https://lists.01.org/pipermail/connman/2014-December/019203.html preconditions] are met, try again after disabling competing network managers and rebooting.<br />
<br />
This may also simply be caused by the wireless interface being blocked by [[rfkill]], which can occur after restarting wpa_supplicant. Use {{ic|rfkill list}} to check.<br />
<br />
=== "Not registered", or "Method "Connect" with signature ... doesn't exist" ===<br />
<br />
When issuing commands, you may see errors like the following:<br />
<br />
From a {{ic|connmanctl}} prompt:<br />
<br />
{{hc|connmanctl> connect ''service_id''|<br />
Error /net/connman/service/''SSID'': Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist<br />
}}<br />
<br />
From the shell:<br />
<br />
{{hc|# connmanctl connect ''service_id''|<br />
Error /net/connman/service/''service_id'': Not registered<br />
}}<br />
<br />
These errors are produced because the agent is not running. Start the agent from a {{ic|connmanctl}} prompt with {{ic|agent on}}, and try again.<br />
<br />
=== Error Failed to set hostname/domainname ===<br />
<br />
connman can failed to set hostname or domainname due to lack of {{ic|CAP_SYS_ADMIN}}.<br />
<br />
You will need to [[edit]] {{ic|connman.service}} (and other like {{ic|connman-vpn.service}} , etc ...) to modify the {{ic|CapabilityBoundingSet}} line to add {{ic|CAP_SYS_ADMIN}}.<br />
<br />
See {{ic|EPERM}} under {{man|2|sethostname|ERRORS}} or {{man|2|setdomainname|ERRORS}} for more details.<br />
<br />
=== Unknown route on connection ===<br />
<br />
A log entry for an unknown route appears each time a connect is done. For example: <br />
<br />
...<br />
connmand[473]: wlp2s0 {add} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
connmand[473]: wlp2s0 {del} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
...<br />
<br />
It likely is Connman performing a connectivity check to the ipv4.connman.net host (which resolves to the IP address {{ic|82.165.8.211}} at current).[https://01.org/jira/browse/CM-657] See the [https://git.kernel.org/pub/scm/network/connman/connman.git/tree/README#n388 Connman README] for more information on why and what - apart from the connecting IP - it transmits.<br />
This behaviour can be prevented by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
EnableOnlineCheck=false<br />
<br />
This setting will cause that the default device will not switch to ONLINE, but stay in READY state.{{man|5|connman.conf}} However, the connection will still be functional.<br />
<br />
The connection itself is also functional (unless behind a captive portal) if the check is blocked by a firewall rule: <br />
<br />
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT<br />
# iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT<br />
<br />
=== File /proc/net/pnp doesn't exist ===<br />
<br />
If you see this in your error log it is caused by bug in connman [https://bbs.archlinux.org/viewtopic.php?id=227689#p1766928] and can be ignored. [https://01.org/jira/browse/CM-690 Bug Report]<br />
<br />
== See also ==<br />
<br />
* [https://git.kernel.org/cgit/network/connman/connman.git/tree/doc Git repository documentation] — for further detailed documentation</div>RaZorrhttps://wiki.archlinux.org/index.php?title=ConnMan&diff=722515ConnMan2022-03-11T16:56:53Z<p>RaZorr: Add note on connecting to wifi with iwd</p>
<hr />
<div>[[Category:Network managers]]<br />
[[ja:ConnMan]]<br />
[[zh-hans:ConnMan]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related articles end}}<br />
<br />
[https://web.archive.org/web/20210224075615/https://01.org/connman ConnMan] is a command-line network manager designed for use with embedded devices and fast resolve times. It is modular through a [https://git.kernel.org/cgit/network/connman/connman.git/tree/plugins plugin architecture], but has native [[Wikipedia:DHCP|DHCP]] and [[NTP]] support.[https://git.kernel.org/cgit/network/connman/connman.git/tree/src/]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|connman}} package. {{Pkg|wpa_supplicant}}, {{Pkg|bluez}}, and {{pkg|openvpn}} are optional dependencies required for Wi-Fi, Bluetooth, and VPN functionality respectively.<br />
<br />
Before [[enabling]] {{ic|connman.service}}, ensure any existing [[network configuration]] is disabled.<br />
<br />
ConnMan comes with the {{man|1|connmanctl}} CLI, there are various [[#Front-ends]] available.<br />
<br />
=== Front-ends ===<br />
<br />
* {{App|cmst|Qt GUI for ConnMan.|https://github.com/andrew-bibb/cmst|{{AUR|cmst}}}}<br />
* {{App|connman-ncurses|Simple ncurses UI for ConnMan; not all of connman functionality is implemented, but usable (with X or from terminal without X), see the [https://github.com/eurogiciel-oss/connman-json-client/wiki wiki].|https://github.com/eurogiciel-oss/connman-json-client|{{AUR|connman-ncurses-git}}}}<br />
* {{App|ConnMan-UI|GTK3 client applet.|https://github.com/tbursztyka/connman-ui|{{AUR|connman-ui-git}}}}<br />
* {{App|connman_dmenu|Client/frontend for dmenu.|https://github.com/taylorchu/connman_dmenu|{{AUR|connman_dmenu-git}}}}<br />
* {{App|Econnman|Enlightenment desktop panel applet.|https://www.enlightenment.org|{{AUR|econnman}}}}<br />
* {{App|LXQt-Connman-Applet|LXQt desktop panel applet.|https://github.com/lxqt/lxqt-connman-applet|{{AUR|lxqt-connman-applet}}}}<br />
* {{App|connman-gtk| GTK client.|https://github.com/jgke/connman-gtk|{{AUR|connman-gtk}}}}<br />
* {{App|gnome-extension-connman| Gnome3 extension for connman; it contains only some of the functionality without installing connman-gtk.|https://github.com/jgke/gnome-extension-connman|https://extensions.gnome.org/extension/981/connman-extension/}}<br />
<br />
== Usage ==<br />
<br />
{{Expansion|Only Wired and Wi-Fi plugins are described.}}<br />
<br />
ConnMan comes with the {{ic|connmanctl}} command-line interface, see {{man|1|connmanctl}}.<br />
If you do not provide any commands {{ic|connmanctl}} starts as an interactive shell.<br />
<br />
''ConnMan'' automatically handles wired connections.<br />
<br />
=== Wi-Fi ===<br />
<br />
==== Enabling and disabling wifi ====<br />
<br />
To check if wifi is enabled you can run {{ic|connmanctl technologies}} and check for the line that says {{ic|Powered: True/False}}.<br />
To power the wifi on you can run {{ic|connmanctl enable wifi}} or if you need to disable it you can run {{ic|connmanctl disable wifi}}.<br />
Other ways to enable wifi could include using the {{ic|Fn}} keys on the laptop to turn it on or running {{ic|ip link set <interface> up}}.<br />
<br />
==== Connecting to an open access point ====<br />
<br />
To scan the network {{ic|connmanctl}} accepts simple names called ''technologies''. To scan for nearby Wi-Fi networks:<br />
<br />
$ connmanctl scan wifi<br />
<br />
To list the available networks found after a scan run (example output): <br />
<br />
{{hc|$ connmanctl services|<br />
*AO MyNetwork wifi_dc85de828967_68756773616d_managed_psk<br />
OtherNET wifi_dc85de828967_38303944616e69656c73_managed_psk <br />
AnotherOne wifi_dc85de828967_3257495245363836_managed_wep<br />
FourthNetwork wifi_dc85de828967_4d7572706879_managed_wep<br />
AnOpenNetwork wifi_dc85de828967_4d6568657272696e_managed_none<br />
}}<br />
<br />
To connect to an open network, use the second field beginning with {{ic|wifi_}}:<br />
<br />
$ connmanctl connect wifi_dc85de828967_4d6568657272696e_managed_none<br />
<br />
{{Tip|Network names can be tab-completed.}}<br />
<br />
You should now be connected to the network. Check using {{ic|connmanctl state}} or {{ic|ip addr}}.<br />
<br />
==== Connecting to a protected access point ====<br />
<br />
For protected access points you will need to provide some information to the ConnMan daemon, at the very least a password or a passphrase.<br />
<br />
The commands in this section show how to run {{ic|connmanctl}} in interactive mode, it is required for running the {{ic|agent}} command. To start interactive mode simply type: <br />
<br />
$ connmanctl<br />
<br />
You then proceed almost as above, first scan for any Wi-Fi ''technologies'':<br />
<br />
connmanctl> scan wifi<br />
<br />
To list services:<br />
<br />
connmanctl> services<br />
<br />
Now you need to register the agent to handle user requests. The command is:<br />
<br />
connmanctl> agent on<br />
<br />
You now need to connect to one of the protected services. To do this easily, just use tab completion for the wifi_ service. If you were connecting to OtherNET in the example above you would type:<br />
<br />
connmanctl> connect wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
<br />
The agent will then ask you to provide any information the daemon needs to complete the connection. The <br />
information requested will vary depending on the type of network you are connecting to. The agent<br />
will also print additional data about the information it needs as shown in the example below.<br />
<br />
Agent RequestInput wifi_dc85de828967_38303944616e69656c73_managed_psk<br />
Passphrase = [ Type=psk, Requirement=mandatory ]<br />
Passphrase? <br />
<br />
Provide the information requested, in this example the passphrase, and then type:<br />
<br />
connmanctl> quit<br />
<br />
If the information you provided is correct you should now be connected to the protected access point.<br />
<br />
==== Using iwd instead of wpa_supplicant ====<br />
<br />
ConnMan can use {{pkg|iwd}} to connect to wireless networks. The package which is available in community already supports using {{pkg|iwd}} for connecting to wireless networks. As {{pkg|connman}} will start {{pkg|wpa_supplicant}} when it finds it, it is recommended to uninstall {{pkg|wpa_supplicant}}.<br />
<br />
Currently the {{ic|-i}}-option of {{pkg|iwd}} seems to cause that the WiFi-interface gets hidden from {{pkg|connman}}.<br />
<br />
Create the following two service files which should cause {{pkg|connman}} to use {{pkg|iwd}} to connect to wireless networks, regardless if {{pkg|wpa_supplicant}} is installed.<br />
<br />
{{hc|/etc/systemd/system/iwd.service|output=<br />
[Unit]<br />
Description=Internet Wireless Daemon (IWD)<br />
Before=network.target<br />
Wants=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/lib/iwd/iwd<br />
<br />
[Install]<br />
Alias=multi-user.target.wants/iwd.service<br />
}}<br />
<br />
{{hc|/etc/systemd/system/connman_iwd.service|output=<br />
[Unit]<br />
Description=Connection service<br />
DefaultDependencies=false<br />
Conflicts=shutdown.target<br />
RequiresMountsFor=/var/lib/connman<br />
After=dbus.service network-pre.target systemd-sysusers.service iwd.service<br />
Before=network.target multi-user.target shutdown.target<br />
Wants=network.target<br />
Requires=iwd.service<br />
<br />
[Service]<br />
Type=dbus<br />
BusName=net.connman<br />
Restart=on-failure<br />
ExecStart=/usr/bin/connmand --wifi=iwd_agent -n <br />
StandardOutput=null<br />
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE<br />
ProtectHome=true<br />
ProtectSystem=true<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Then [[enable]]/[[start]] the {{ic|connman_iwd}} service.<br />
<br />
Advantage of using {{pkg|iwd}} instead of {{pkg|wpa_supplicant}} is, that the ping times seem to be much more consistent and the connection seems to be more reliable.<br />
<br />
=== Settings ===<br />
<br />
Settings and profiles are automatically created for networks the user connects to often. They contain fields for the passphrase, essid and other information. Profile settings are stored in directories under {{ic|/var/lib/connman/}} by their service name. To view all network profiles run this command from [[Help:Reading#Regular_user_or_root|root shell]]: <br />
<br />
# cat /var/lib/connman/*/settings<br />
<br />
{{Note|VPN settings can be found in {{ic|/var/lib/connman-vpn/}}.}}<br />
<br />
=== Technologies ===<br />
<br />
Various hardware interfaces are referred to as ''Technologies'' by ConnMan.<br />
<br />
To list available ''technologies'' run: <br />
<br />
$ connmanctl technologies<br />
<br />
To get just the types by their name one can use this one liner:<br />
<br />
$ connmanctl technologies | awk '/Type/ { print $NF }'<br />
<br />
{{Note| The field {{ic|1=Type = tech_name}} provides the technology type used with {{ic|connmanctl}} commands}}<br />
<br />
To interact with them one must refer to the technology by type. ''Technologies'' can be toggled on/off with: <br />
<br />
$ connmanctl enable ''technology_type''<br />
<br />
and:<br />
<br />
$ connmanctl disable ''technology_type''<br />
<br />
For example to toggle off wifi:<br />
<br />
$ connmanctl disable wifi<br />
<br />
{{Warning|connman grabs rfkill events. It is most likely impossible to use {{ic|rfkill}} or {{ic|bluetoothctl}} to (un)block devices, yet hardware keys may still work.[https://git.kernel.org/cgit/network/connman/connman.git/tree/doc/overview-api.txt#n406] Always use {{ic|connmanctl enable{{!}}disable}} }}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Avoid changing the hostname ===<br />
<br />
By default, ConnMan changes the transient hostname (see {{man|1|hostnamectl}}) on a per network basis. This can create problems with X authority: If ConnMan changes your hostname to something else than the one used to generate the xauth magic cookie, then it will become impossible to create new windows. Symptoms are error messages like {{ic|No protocol specified}} and {{ic|Can't open display: :0.0}}. Manually resetting the host name fixes this, but a permanent solution is to prevent ConnMan from changing your host name in the first place. This can be accomplished by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
AllowHostnameUpdates=false<br />
<br />
Make sure to [[restart]] the {{ic|connman.service}} after changing this file.<br />
<br />
For testing purposes it is recommended to watch the [[systemd journal]] and plug the network cable a few times to see the action.<br />
<br />
=== Prefer ethernet to wireless ===<br />
<br />
By default ConnMan does not prefer ethernet over wireless, which can lead to it deciding to stick with a slow wireless network even when ethernet is available. You can tell connman to prefer ethernet adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
PreferredTechnologies=ethernet,wifi<br />
<br />
=== Exclusive connection ===<br />
<br />
ConnMan allows you to be connected to both ethernet and wireless at the same time. This can be useful as it allows programs that established a connection over wifi to stay connected even after you connect to ethernet. But some people prefer to have only a single unambiguous connection active at a time. That behavior can be activated by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
SingleConnectedTechnology=true<br />
<br />
=== Connecting to eduroam (802.1X) ===<br />
<br />
[[WPA2 Enterprise]] networks such as eduroam require a separate configuration file before [[#Wi-Fi|connecting]] to the network. For example, create {{ic|/var/lib/connman/eduroam.config}}:<br />
<br />
{{hc|1=eduroam.config|2=<br />
[service_eduroam]<br />
Type=wifi<br />
Name=eduroam<br />
EAP=peap<br />
CACertFile=/etc/ssl/certs/''certificate.cer''<br />
Phase2=''MSCHAPV2''<br />
Identity=''user@foo.edu''<br />
AnonymousIdentity=''anonymous@foo.edu''<br />
Passphrase=''password''<br />
}}<br />
<br />
[[Restart]] {{ic|wpa_supplicant.service}} and {{ic|connman.service}} to connect to the new network.<br />
<br />
{{Note|<br />
* Options are case-sensitive, e.g. {{ic|1=EAP = ttls}} instead of {{ic|1=EAP = TTLS}}.[https://together.jolla.com/question/55969/connman-fails-due-to-case-sensitive-settings/]<br />
* Consult the institution hosting the eduroam network for various settings such as username, password, {{ic|EAP}}, {{ic|Phase2output}}, and needed certificates.<br />
}}<br />
<br />
For more information, see {{man|5|connman-service.config}} and [[Wireless network configuration#eduroam]].<br />
<br />
=== Avoiding conflicts with local DNS server ===<br />
<br />
If you are running a local DNS server, it will likely have problems binding to port 53 (TCP and/or UDP) after installing Connman. This is because Connman includes its own DNS proxy which also tries to bind to those ports. If you see log messages from [[BIND]] or [[dnsmasq]] like <br />
<br />
named[529]: could not listen on UDP socket: address in use<br />
<br />
this could be the problem. To verify which application is listening on the ports, you can execute {{ic|ss -tulpn}} as root.<br />
<br />
To fix this connmand can be started with the options {{ic|-r}} or {{ic|--nodnsproxy}} by [[Systemd#Editing provided units|overriding]] the systemd service file. Create the folder {{ic|/etc/systemd/system/connman.service.d/}} and add the file {{ic|disable_dns_proxy.conf}}:<br />
<br />
{{hc|/etc/systemd/system/connman.service.d/disable_dns_proxy.conf|2=<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/connmand -n --nodnsproxy<br />
}}<br />
<br />
If you want to know the DNS servers received from DHCP while keeping a custom {{ic|/etc/resolv.conf}}, then append {{ic|<nowiki>RuntimeDirectory=connman</nowiki>}} to the same file. Now connman will write them to {{ic|/var/run/connman/resolv.conf}} instead.<br />
<br />
Make sure to [[reload]] the systemd daemon and [[restart]] the {{ic|connman.service}}, and your DNS proxy, after adding this file.<br />
<br />
=== Blacklist interfaces ===<br />
<br />
If something like [[Docker]] is creating virtual interfaces Connman may attempt to connect to one of these instead of your physical adapter if the connection drops. A simple way of avoiding this is to blacklist the interfaces you do not want to use. Connman will by default blacklist interfaces starting with {{ic|vmnet}}, {{ic|vboxnet}}, {{ic|virbr}} and {{ic|ifb}}, so those need to be included in the new blacklist as well.<br />
<br />
Blacklisting interface names is also useful to avoid a race condition where connman may access {{ic|eth#}} or {{ic|wlan#}} before systemd/udev can change it to use a [https://systemd.io/PREDICTABLE_INTERFACE_NAMES/ Predictable Network Interface Names] like {{ic|enp4s0}}. Blacklisting the conventional (and unpredictable) interface prefixes makes connman wait until they are renamed.<br />
<br />
If it does not already exist, create {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,docker,veth,eth,wlan<br />
<br />
Once {{ic|connman.service}} has been [[systemd#Using units|restarted]] this will also hide all the {{ic|veth#######}} interfaces from GUI tools like Econnman.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Error /net/connman/technology/wifi: Not supported ===<br />
<br />
Currently, connman does not support scanning for WiFi networks with {{Pkg|iwd}}, at the moment this functionality is available with {{ic|wpa_supplicant}} only (see [https://lists.01.org/pipermail/connman/2018-August/022915.html]). To connect to wifi with iwd, [[enable]]/[[start]] {{ic|iwd.service}} and then either follow instructions in [[Iwd]] to connect to the wifi or you can also use any of the [[ConnMan#Front-ends|#Front-ends]]. In order to have Wifi Scanning support from within connman, install {{Pkg|wpa_supplicant}} and then [[restart]] {{ic|connman.service}} after you stop {{ic|iwd.service}}.<br />
<br />
=== Error /net/connman/technology/wifi: No carrier ===<br />
<br />
You have enabled your wifi with:<br />
<br />
$ connmanctl enable wifi<br />
<br />
If wireless scanning leads to above error, this may be due to an unresolved bug.[https://01.org/jira/browse/CM-670]<br />
If it does not resolve even though wireless [https://lists.01.org/pipermail/connman/2014-December/019203.html preconditions] are met, try again after disabling competing network managers and rebooting.<br />
<br />
This may also simply be caused by the wireless interface being blocked by [[rfkill]], which can occur after restarting wpa_supplicant. Use {{ic|rfkill list}} to check.<br />
<br />
=== "Not registered", or "Method "Connect" with signature ... doesn't exist" ===<br />
<br />
When issuing commands, you may see errors like the following:<br />
<br />
From a {{ic|connmanctl}} prompt:<br />
<br />
{{hc|connmanctl> connect ''service_id''|<br />
Error /net/connman/service/''SSID'': Method "Connect" with signature "" on interface "net.connman.Service" doesn't exist<br />
}}<br />
<br />
From the shell:<br />
<br />
{{hc|# connmanctl connect ''service_id''|<br />
Error /net/connman/service/''service_id'': Not registered<br />
}}<br />
<br />
These errors are produced because the agent is not running. Start the agent from a {{ic|connmanctl}} prompt with {{ic|agent on}}, and try again.<br />
<br />
=== Error Failed to set hostname/domainname ===<br />
<br />
connman can failed to set hostname or domainname due to lack of {{ic|CAP_SYS_ADMIN}}.<br />
<br />
You will need to [[edit]] {{ic|connman.service}} (and other like {{ic|connman-vpn.service}} , etc ...) to modify the {{ic|CapabilityBoundingSet}} line to add {{ic|CAP_SYS_ADMIN}}.<br />
<br />
See {{ic|EPERM}} under {{man|2|sethostname|ERRORS}} or {{man|2|setdomainname|ERRORS}} for more details.<br />
<br />
=== Unknown route on connection ===<br />
<br />
A log entry for an unknown route appears each time a connect is done. For example: <br />
<br />
...<br />
connmand[473]: wlp2s0 {add} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
connmand[473]: wlp2s0 {del} route 82.165.8.211 gw 10.20.30.4 scope 0 <UNIVERSE><br />
...<br />
<br />
It likely is Connman performing a connectivity check to the ipv4.connman.net host (which resolves to the IP address {{ic|82.165.8.211}} at current).[https://01.org/jira/browse/CM-657] See the [https://git.kernel.org/pub/scm/network/connman/connman.git/tree/README#n388 Connman README] for more information on why and what - apart from the connecting IP - it transmits.<br />
This behaviour can be prevented by adding the following to {{ic|/etc/connman/main.conf}}:<br />
<br />
[General]<br />
EnableOnlineCheck=false<br />
<br />
This setting will cause that the default device will not switch to ONLINE, but stay in READY state.{{man|5|connman.conf}} However, the connection will still be functional.<br />
<br />
The connection itself is also functional (unless behind a captive portal) if the check is blocked by a firewall rule: <br />
<br />
# ip6tables -A OUTPUT -d ipv6.connman.net -j REJECT<br />
# iptables -A OUTPUT -d ipv4.connman.net,ipv6.connman.net -j REJECT<br />
<br />
=== File /proc/net/pnp doesn't exist ===<br />
<br />
If you see this in your error log it is caused by bug in connman [https://bbs.archlinux.org/viewtopic.php?id=227689#p1766928] and can be ignored. [https://01.org/jira/browse/CM-690 Bug Report]<br />
<br />
== See also ==<br />
<br />
* [https://git.kernel.org/cgit/network/connman/connman.git/tree/doc Git repository documentation] — for further detailed documentation</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Iwd&diff=721876Iwd2022-03-08T08:03:37Z<p>RaZorr: Add note on enabling iwd.service along with other network manager services like NetworkManager.service or ConnMann.service</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Wireless networking]]<br />
[[Category:Network configuration]]<br />
[[ja:Iwd]]<br />
[[pt:Iwd]]<br />
[[ru:Iwd]]<br />
[[zh-hans:Iwd]]<br />
{{Related articles start}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|wpa_supplicant}}<br />
{{Related articles end}}<br />
[https://iwd.wiki.kernel.org/ iwd] (iNet wireless daemon) is a wireless daemon for Linux written by Intel. The core goal of the project is to optimize resource utilization by not depending on any external libraries and instead utilizing features provided by the Linux Kernel to the maximum extent possible.<br />
<br />
iwd can work in standalone mode or in combination with comprehensive network managers like [[ConnMan]], [[systemd-networkd]] and [[NetworkManager#Using iwd as the Wi-Fi backend|NetworkManager]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|iwd}} package.<br />
<br />
== Usage ==<br />
<br />
The {{Pkg|iwd}} package provides the client program {{ic|iwctl}}, the daemon {{ic|iwd}} and the Wi-Fi monitoring tool {{ic|iwmon}}.<br />
<br />
[[Start/enable]] {{ic|iwd.service}} so it can be controlled using the {{ic|iwctl}} command(may not be necessary if you are using it along with other [[Network_configuration#Network_managers|network managers]]).<br />
<br />
=== iwctl ===<br />
<br />
{{Note|As of version 1.23, only root and members of the {{ic|netdev}} or the {{ic|wheel}} [[user group]] are allowed to interact with ''iwd''. In order to use ''iwctl'', you need to [[Users and groups#Group management|add your user to one of those groups]].}}<br />
<br />
To get an interactive prompt do:<br />
<br />
$ iwctl<br />
<br />
The interactive prompt is then displayed with a prefix of {{ic|[iwd]#}}.<br />
<br />
{{Tip|<br />
* In the {{ic|iwctl}} prompt you can auto-complete commands and device names by hitting {{ic|Tab}}.<br />
* To exit the interactive prompt, send [[Wikipedia:EOF character|EOF]] by pressing {{ic|Ctrl+d}}.<br />
* You can use all commands as command line arguments without entering an interactive prompt. For example: {{ic|iwctl device wlan0 show}}.<br />
}}<br />
<br />
To list all available commands:<br />
<br />
[iwd]# help<br />
<br />
==== Connect to a network ====<br />
<br />
First, if you do not know your wireless device name, list all Wi-Fi devices:<br />
<br />
[iwd]# device list<br />
<br />
Then, to scan for networks:<br />
<br />
[iwd]# station ''device'' scan<br />
<br />
You can then list all available networks:<br />
<br />
[iwd]# station ''device'' get-networks<br />
<br />
Finally, to connect to a network:<br />
<br />
[iwd]# station ''device'' connect ''SSID''<br />
<br />
{{Tip|The user interface supports autocomplete, by typing {{ic|station }} and {{ic|Tab}} {{ic|Tab}}, the available devices are displayed, type the first letters of the device and {{ic|Tab}} to complete. The same way, type {{ic|connect }} and {{ic|Tab}} {{ic|Tab}} in order to have the list of available networks displayed. Then, type the first letters of the chosen network followed by {{ic|Tab}} in order to complete the command.}} <br />
<br />
If a passphrase is required, you will be prompted to enter it. Alternatively, you can supply it as a command line argument:<br />
<br />
$ iwctl --passphrase ''passphrase'' station ''device'' connect ''SSID''<br />
<br />
{{Note|<br />
* {{ic|iwd}} automatically stores network passphrases in the {{ic|/var/lib/iwd}} directory and uses them to auto-connect in the future. See [[#Network configuration]].<br />
* To connect to a network with spaces in the SSID, the network name should be double quoted when connecting.<br />
* iwd only supports PSK pass-phrases from 8 to 63 ASCII-encoded characters. The following error message will be given if the requirements are not met: {{ic|PMK generation failed. Ensure Crypto Engine is properly configured}}.<br />
}}<br />
<br />
==== Connect to a network using WPS/WSC ====<br />
<br />
If your network is configured such that you can connect to it by pressing a button ([[Wikipedia:Wi-Fi Protected Setup]]), check first that your network device is also capable of using this setup procedure.<br />
<br />
[iwd]# wsc list<br />
<br />
Then, provided that your device appeared in the above list,<br />
<br />
[iwd]# wsc ''device'' push-button<br />
<br />
and push the button on your router. The procedure works also if the button was pushed beforehand, less than 2 minutes earlier.<br />
<br />
If your network requires to validate a PIN number to connect that way, check the {{ic|help}} command output to see how to provide the right options to the {{ic|wsc}} command.<br />
<br />
==== Disconnect from a network ====<br />
<br />
To disconnect from a network:<br />
<br />
[iwd]# station ''device'' disconnect<br />
<br />
==== Show device and connection information ====<br />
<br />
To display the details of a WiFi device, like MAC address:<br />
<br />
[iwd]# device ''device'' show<br />
<br />
To display the connection state, including the connected network of a Wi-Fi device:<br />
<br />
[iwd]# station ''device'' show<br />
<br />
==== Manage known networks ====<br />
<br />
To list networks you have connected to previously:<br />
<br />
[iwd]# known-networks list<br />
<br />
To forget a known network:<br />
<br />
[iwd]# known-networks ''SSID'' forget<br />
<br />
== Network configuration ==<br />
<br />
By default, ''iwd'' stores the network configuration in the directory {{ic|/var/lib/iwd}}. The configuration file is named as {{ic|''network''.''type''}}, where ''network'' is the network SSID and ''.type'' is the network type, either ''.open'', ''.psk'' or ''.8021x''. The file is used to store the encrypted {{ic|PreSharedKey}} and optionally the cleartext {{ic|Passphrase}} and can also be created by the user without invoking {{ic|iwctl}}. The file can be used for other configuration pertaining to that network SSID as well. For more settings, see {{man|5|iwd.network}}.<br />
<br />
{{Note|In string values, including identities and passwords, certain characters may be backslash-escaped. Leading spaces, \n, \r, and literal backslashes must be escaped. See {{man|5|iwd.network}}.}}<br />
<br />
=== WPA-PSK ===<br />
<br />
A minimal example file to connect to a WPA-PSK or WPA2-PSK secured network with SSID "spaceship" and passphrase "test1234":<br />
<br />
{{hc|/var/lib/iwd/spaceship.psk|2=<br />
[Security]<br />
PreSharedKey=aafb192ce2da24d8c7805c956136f45dd612103f086034c402ed266355297295}}<br />
<br />
{{Note|The SSID of the network is used as a filename only when it contains only alphanumeric characters or one of {{ic|- _}}. If it contains any other characters, the name will instead be an {{ic|1==}}-character followed by the hex-encoded version of the SSID.<br />
}}<br />
<br />
To calculate the pre-shared key from the passphrase, one of these two methods can be used:<br />
* Enter the passphrase in cleartext in the configuration file:<br />
{{hc|/var/lib/iwd/spaceship.psk|2=<br />
[Security]<br />
Passphrase=test1234}}<br />
The pre-shared key will be appended to the file at the first connect:<br />
{{hc|/var/lib/iwd/spaceship.psk|2=<br />
[Security]<br />
Passphrase=test1234<br />
PreSharedKey=aafb192ce2da24d8c7805c956136f45dd612103f086034c402ed266355297295}}<br />
<br />
* Or the pre-shared key can be calculated from the SSID and the passphrase using ''wpa_passphrase'' (from {{Pkg|wpa_supplicant}}) or {{AUR|wpa-psk}}. See [[wpa_supplicant#Connecting with wpa_passphrase]] for more details.<br />
<br />
=== WPA Enterprise ===<br />
<br />
==== EAP-PWD ====<br />
<br />
For connecting to a EAP-PWD protected enterprise access point you need to create a file called: {{ic|''essid''.8021x}} in the {{ic|/var/lib/iwd}} directory with the following content:<br />
<br />
{{hc|/var/lib/iwd/''essid''.8021x|2=<br />
[Security]<br />
EAP-Method=PWD<br />
EAP-Identity=''your_enterprise_email''<br />
EAP-Password=''your_password''<br />
<br />
[Settings]<br />
AutoConnect=True<br />
}}<br />
<br />
If you do not want autoconnect to the AP you can set the option to False and connect manually to the access point via {{ic|iwctl}}. The same applies to the password, if you do not want to store it plaintext leave the option out of the file and just connect to the enterprise AP.<br />
<br />
==== EAP-PEAP ====<br />
<br />
Like EAP-PWD, you also need to create a {{ic|''essid''.8021x}} file in the directory. Before you proceed to write the configuration file, this is also a good time to find out which CA certificate your organization uses. This is an example configuration file that uses MSCHAPv2 password authentication:<br />
<br />
{{hc|/var/lib/iwd/''essid''.8021x|2=<br />
[Security]<br />
EAP-Method=PEAP<br />
EAP-Identity=anonymous@realm.edu<br />
EAP-PEAP-CACert=/path/to/root.crt<br />
EAP-PEAP-ServerDomainMask=radius.realm.edu<br />
EAP-PEAP-Phase2-Method=MSCHAPV2<br />
EAP-PEAP-Phase2-Identity=johndoe@realm.edu<br />
EAP-PEAP-Phase2-Password=hunter2<br />
<br />
[Settings]<br />
AutoConnect=true<br />
}}<br />
<br />
MsCHAPv2 passwords can also be stored as a encrypted hash. The correct md4 hash can be calculated with: (insert an EOF after your password, do not hit enter)<br />
$ iconv -t utf16le | openssl md4<br />
The resulting hash needs to be stored inside the {{ic|EAP-PEAP-Phase2-Password-Hash}} key.<br />
<br />
{{Tip|If you are planning on using ''eduroam'', see also [[#eduroam]].}}<br />
<br />
==== TTLS-PAP ====<br />
<br />
Like EAP-PWD, you also need to create a {{ic|''essid''.8021x}} file in the directory. Before you proceed to write the configuration file, this is also a good time to find out which CA certificate your organization uses. This is an example configuration file that uses PAP password authentication:<br />
<br />
{{hc|/var/lib/iwd/''essid''.8021x|2=<br />
[Security]<br />
EAP-Method=TTLS<br />
EAP-Identity=anonymous@uni-test.de<br />
EAP-TTLS-CACert=cert.pem<br />
EAP-TTLS-ServerDomainMask=*.uni-test.de<br />
EAP-TTLS-Phase2-Method=Tunneled-PAP<br />
EAP-TTLS-Phase2-Identity=user<br />
EAP-TTLS-Phase2-Password=password<br />
<br />
[Settings]<br />
AutoConnect=true<br />
}}<br />
<br />
==== eduroam ====<br />
<br />
eduroam offers a [https://cat.eduroam.org/ configuration assistant tool (CAT)], which unfortunately does not support iwd. However, the installer, which you can download by clicking on the download button then selecting your university, is just a Python script. It is easy to extract the necessary configuration options, including the certificate and server domain mask.<br />
<br />
The following table contains a mapping of iwd configuration options to eduroam CAT install script variables.<br />
<br />
{| class="wikitable<br />
! Iwd Configuration Option !! CAT Script Variable<br />
|-<br />
| file name || one of {{ic|Config.ssids}}<br />
|-<br />
| {{ic|EAP-Method}} || {{ic|Config.eap_outer}}<br />
|-<br />
| {{ic|EAP-Identity}} || {{ic|Config.anonymous_identity}}<br />
|-<br />
| {{ic|EAP-PEAP-CACert}} || {{ic|Config.CA}}<br />
|-<br />
| {{ic|EAP-PEAP-ServerDomainMask}} || one of {{ic|Config.servers}}<br />
|-<br />
| {{ic|EAP-PEAP-Phase2-Method}} || {{ic|Config.eap_inner}}<br />
|-<br />
| {{ic|EAP-PEAP-Phase2-Identity}} || username@{{ic|Config.user_realm}}<br />
|}<br />
<br />
{{Note|<br />
* {{ic|EAP-Identity}} may not be required by your eduroam provider, in which case you might have to use {{ic|anonymous@''Config.user_realm''}} in this field.<br />
* If your {{ic|EAP-PEAP-ServerDomainMask}} starts with {{ic|DNS:}}, use only the part after {{ic|DNS:}}.<br />
}}<br />
<br />
==== Other cases ====<br />
<br />
More example tests can be [https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/autotests found in the test cases] of the upstream repository.<br />
<br />
== Optional configuration ==<br />
<br />
File {{ic|/etc/iwd/main.conf}} can be used for main configuration. See {{man|5|iwd.config}}.<br />
<br />
=== Disable auto-connect for a particular network ===<br />
<br />
Create / edit file {{ic|/var/lib/iwd/''network''.''type''}}. Add the following section to it:<br />
<br />
{{hc|/var/lib/iwd/spaceship.psk (for example)|2=<br />
[Settings]<br />
AutoConnect=false<br />
}}<br />
<br />
=== Disable periodic scan for available networks ===<br />
<br />
By default when {{ic|iwd}} is in disconnected state, it periodically scans for available networks. To disable periodic scan (so as to always scan manually), create / edit file {{ic|/etc/iwd/main.conf}} and add the following section to it:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[Scan]<br />
DisablePeriodicScan=true<br />
}}<br />
<br />
=== Enable built-in network configuration ===<br />
<br />
Since version 0.19, iwd can assign IP address(es) and set up routes using a built-in DHCP client or with static configuration. It is a good alternative to [[Network configuration#DHCP|standalone DHCP clients]].<br />
<br />
To activate iwd's network configuration feature, create/edit {{ic|/etc/iwd/main.conf}} and add the following section to it:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[General]<br />
EnableNetworkConfiguration=true<br />
}}<br />
<br />
There is also ability to set route metric with {{ic|RoutePriorityOffset}}:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[Network]<br />
RoutePriorityOffset=300<br />
}}<br />
<br />
==== IPv6 support ====<br />
<br />
Since version 1.10, iwd supports IPv6, but it is disabled by default. To enable it, add the following to the configuration file:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[Network]<br />
EnableIPv6=true<br />
}}<br />
<br />
This setting is required whether you want to use DHCPv6 or static IPv6 configuration. It can also be set on a per-network basis.<br />
<br />
==== Setting static IP address in network configuration ====<br />
<br />
Add the following section to {{ic|/var/lib/iwd/''network''.''type''}} file. For example:<br />
<br />
{{hc|/var/lib/iwd/spaceship.psk|2=<br />
[IPv4]<br />
Address=192.168.1.10<br />
Netmask=255.255.255.0<br />
Gateway=192.168.1.1<br />
Broadcast=192.168.1.255<br />
DNS=192.168.1.1<br />
}}<br />
<br />
==== Select DNS manager ====<br />
<br />
At the moment, iwd supports two DNS managers—[[systemd-resolved]] and [[resolvconf]].<br />
<br />
Add the following section to {{ic|/etc/iwd/main.conf}} for {{ic|systemd-resolved}}:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[Network]<br />
NameResolvingService=systemd<br />
}}<br />
<br />
For {{ic|resolvconf}}:<br />
<br />
{{hc|/etc/iwd/main.conf|2=<br />
[Network]<br />
NameResolvingService=resolvconf<br />
}}<br />
<br />
{{Note|If not specified, [[systemd-resolved]] is used as default.}}<br />
<br />
=== Allow any user to read status information ===<br />
<br />
If you want to allow any user to read the status information, but not modify the settings, you can create the following [[D-Bus]] configuration file:<br />
<br />
{{hc|/etc/dbus-1/system.d/iwd-allow-read.conf|<nowiki><br />
<!-- Allow any user to read iwd status information. Overrides some part<br />
of /usr/share/dbus-1/system.d/iwd-dbus.conf. --><br />
<br />
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"<br />
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><br />
<busconfig><br />
<br />
<policy context="default"><br />
<deny send_destination="net.connman.iwd"/><br />
<allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.Properties" send_member="GetAll" /><br />
<allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.Properties" send_member="Get" /><br />
<allow send_destination="net.connman.iwd" send_interface="org.freedesktop.DBus.ObjectManager" send_member="GetManagedObjects" /><br />
<allow send_destination="net.connman.iwd" send_interface="net.connman.iwd.Device" send_member="RegisterSignalLevelAgent" /><br />
<allow send_destination="net.connman.iwd" send_interface="net.connman.iwd.Device" send_member="UnregisterSignalLevelAgent" /><br />
</policy><br />
<br />
</busconfig><br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Verbose TLS debugging ===<br />
<br />
This can be useful, if you have trouble setting up MSCHAPv2 or TTLS. You can set the following [[environment variable]] via a [[drop-in snippet]]:<br />
<br />
{{hc|/etc/systemd/system/iwd.service.d/tls-debug.conf|2=<br />
[Service]<br />
Environment=IWD_TLS_DEBUG=TRUE<br />
}}<br />
<br />
Check the iwd logs afterwards by running {{ic|journalctl -u iwd.service}} as root.<br />
<br />
=== Restarting iwd.service after boot ===<br />
<br />
On some machines, it is reported that {{ic|iwd.service}} has to be restarted to work after boot. See {{Bug|63912}} and [https://bbs.archlinux.org/viewtopic.php?id=251432 thread 251432]. This probably occurs because the Linux kernel and services start too early and ''iwd'' starts before wireless network card powers on. As a workaround, [[extend the unit]] to add a delay:<br />
<br />
[Service]<br />
ExecStartPre=/usr/bin/sleep 2<br />
<br />
Then [[reload]] the ''systemd'' manager configuration.<br />
<br />
=== Connect issues after reboot ===<br />
<br />
A low entropy pool can cause connection problems in particular noticeable after reboot. See [[Random number generation]] for suggestions to increase the entropy pool.<br />
<br />
=== Wireless device is not renamed by udev ===<br />
<br />
Since version 1.0, iwd disables predictable renaming of wireless device. It installs the following systemd network link configuration file which prevents udev from renaming the interface to {{ic|wlp#s#}}:<br />
<br />
{{hc|1=/usr/lib/systemd/network/80-iwd.link|2=<br />
[Match]<br />
Type=wlan<br />
<br />
[Link]<br />
NamePolicy=keep kernel<br />
}}<br />
<br />
As a result the wireless link name {{ic|wlan#}} is kept after boot. This resolved a race condition between ''iwd'' and [[udev]] on interface renaming as explained in [https://iwd.wiki.kernel.org/interface_lifecycle#udev_interface_renaming iwd udev interface renaming].<br />
<br />
If this results in issues try masking it with:<br />
<br />
# ln -s /dev/null /etc/systemd/network/80-iwd.link<br />
<br />
=== No DHCP in AP mode ===<br />
<br />
Clients may not receive an IP address via DHCP when connecting to ''iwd'' in AP mode. It is therefore necessary to enable network configuration by ''iwd'' on managed interfaces:<br />
<br />
{{hc|1=/etc/iwd/main.conf|2=<br />
[General]<br />
EnableNetworkConfiguration=True<br />
}}<br />
<br />
The mentioned file has to be created if it does not already exist.<br />
<br />
=== Wifi keeps disconnecting due to iwd crash ===<br />
<br />
Some users experience disconnections with WiFi, re-connecting continuously but stabilizing eventually and managing to connect. <br />
<br />
Users report crashes ([https://bbs.archlinux.org/viewtopic.php?id=273965]) of {{ic|iwd.service}} in their [[journal]]. <br />
<br />
The core issue is having multiple conflicting services for managing their network connections. Check that you do not have [[enable]]d them at the same time to fix this issue.<br />
<br />
== See also ==<br />
<br />
* [https://iwd.wiki.kernel.org/gettingstarted Getting Started with iwd]<br />
* [https://iwd.wiki.kernel.org/networkconfigurationsettings Network Configuration Settings]<br />
* [https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/autotests More Examples for WPA Enterprise]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=237074 The IWD thread on the Arch Linux Forums]<br />
* [https://www.youtube.com/watch?v=F2Q86cphKDo 2017 Update on new WiFi daemon for Linux by Marcel Holtmann - YouTube]<br />
* [https://www.youtube.com/watch?v=QIqT2obSPDk The New Wi-Fi Experience for Linux - Marcel Holtmann, Intel - YouTube]<br />
* [https://iwd.wiki.kernel.org/ap_mode How to set up a simple access point with iwd]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=721799Dm-crypt/Encrypting an entire system2022-03-07T14:08:30Z<p>RaZorr: There is only one top-level subvolume (ID 5).</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[Category:Installation process]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt (Español)/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
[[pl:Dm-crypt (Polski)/Encrypting an entire system]]<br />
[[pt:Dm-crypt (Português)/Encrypting an entire system]]<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://archlinux.org/download/ installation image].<br />
<br />
If you want to encrypt an existing unencrypted file system, see [[dm-crypt/Device encryption#Encrypt an existing unencrypted file system]].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.<br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:<br />
<br />
{| class="wikitable"<br />
! Scenarios<br />
! Advantages<br />
! Disadvantages<br />
|----------------------------------------------------------<br />
| [[#LUKS on a partition]]<br />
shows a basic and straightforward set-up for a fully LUKS encrypted root.<br />
|<br />
* Simple partitioning and setup<br />
* On a GPT partitioned disk, [[systemd#GPT partition automounting|systemd can auto-mount]] the root partition.<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated<br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not transparent when locked<br />
* Easiest method to allow [[dm-crypt/Swap encryption#With suspend-to-disk support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook<br />
* Less useful, if a singular volume should receive a separate key<br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup.<br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks<br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys<br />
* LVM layout is transparent when locked<br />
* Slower boot time; each encrypted LV must be unlocked seperately<br />
|----------------------------------------------------------<br />
| [[#LUKS on software RAID]]<br />
uses dm-crypt only after RAID is setup.<br />
|<br />
* Analogous to LUKS on LVM<br />
|<br />
* Analogous to LUKS on LVM<br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.<br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]<br />
* Helps addressing [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it<br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an EFI system partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|----------------------------------------------------------<br />
| [[#Btrfs subvolumes with swap]]<br />
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.<br />
|<br />
* Similar advantages as [[#Encrypted boot partition (GRUB)]]<br />
* Availability of Btrfs' features<br />
|<br />
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]<br />
|----------------------------------------------------------<br />
| [[#Root on ZFS]]<br />
|<br />
|<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of blockdevice and stacked filesystem encryption and reap the advantages of both. See [[Data-at-rest encryption]] to plan ahead.<br />
<br />
See [[dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
For [[solid state drive]]s you might want to consider enabling TRIM support, but be warned, there are potential security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.<br />
<br />
{{Warning|<br />
* In any scenario, never use file system repair software such as [[fsck]] directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.<br />
* For the LUKS2 format:<br />
** GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.<br />
** The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the {{ic|--pbkdf-memory}} option to control memory usage.[https://gitlab.com/cryptsetup/cryptsetup/issues/372]<br />
}}<br />
<br />
== LUKS on a partition ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS in a simple partition layout:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| Boot partition | LUKS2 encrypted system | Optional free space |<br />
| | partition | for additional |<br />
| | | partitions to be set |<br />
| /boot | / | up later |<br />
| | | |<br />
| | /dev/mapper/root | |<br />
| |------------------------| |<br />
| /dev/sda1 | /dev/sda2 | |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/boot}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command. For information on changing the default sector size, see [[dm-crypt/Device encryption#Sector size]].<br />
<br />
# cryptsetup -y -v luksFormat /dev/sda2<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
Check the mapping works as intended:<br />
<br />
# umount /mnt<br />
# cryptsetup close root<br />
# cryptsetup open /dev/sda2 root<br />
# mount /dev/mapper/root /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each blockdevice requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for an encrypted root. For an ordinary boot partition on BIOS systems, for example, execute:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
or for an [[EFI system partition]] on UEFI systems:<br />
<br />
# mkfs.fat -F32 /dev/sda1<br />
<br />
Afterwards create the directory for the mountpoint and mount the partition:<br />
<br />
# mkdir /mnt/boot<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|keyboard}}, {{ic|keymap}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]. If the default US keymap is fine for you, you can omit the {{ic|keymap}} hook.<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda2}}. See [[Persistent block device naming]] for details.<br />
<br />
== LVM on LUKS ==<br />
<br />
The straightforward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot.<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot partition |<br />
| | | | | |<br />
| [SWAP] | / | /home | | /boot |<br />
| | | | | |<br />
| /dev/MyVolGroup/swap | /dev/MyVolGroup/root | /dev/MyVolGroup/home | | |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS2 encrypted partition | | |<br />
| /dev/sda1 | | /dev/sdb1 |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Note|While using the {{ic|encrypt}} hook this method does not allow you to span the logical volumes over multiple disks; either use the [[sd-encrypt]] or see [[dm-crypt/Specialties#Modifying the encrypt hook for multiple partitions]].}}<br />
<br />
{{Tip|Two variants of this setup:<br />
* Instructions at [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.<br />
* Instructions at [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] use this setup with a detached LUKS header, encrypted {{ic|/boot}} partition, and encrypted keyfile all on a USB device.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
{{Tip|When using the [[GRUB]] boot loader for BIOS booting from a [[GPT]] disk, create a [[BIOS boot partition]].}}<br />
<br />
[[Installation guide#Partition the disks|Create a partition]] to be mounted at {{ic|/boot}} with a size of 200 MiB or more.<br />
<br />
{{Tip|UEFI systems can use the [[EFI system partition]] for {{ic|/boot}}.}}<br />
<br />
Create a partition which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/sda1<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda1 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
<br />
Create a volume group (in this example named {{ic|MyVolGroup}}, but it can be whatever you want) and add the previously created physical volume to it:<br />
<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
# lvcreate -L 8G MyVolGroup -n swap<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mkswap /dev/MyVolGroup/swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/MyVolGroup/home /mnt/home<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. Any filesystem on a disk that can be read by the bootloader is eligible.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
<br />
{{Tip|When opting to keep {{ic|/boot}} on an [[EFI system partition]] the recommended formatting is<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
<br />
}}<br />
<br />
Create the directory {{ic|/mnt/boot}}:<br />
<br />
# mkdir /mnt/boot<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following kernel parameter needs to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptlvm root=/dev/MyVolGroup/root<br />
<br />
If using the [[sd-encrypt]] hook, the following needs to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptlvm root=/dev/MyVolGroup/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda1}}. See [[Persistent block device naming]] for details.<br />
<br />
If using [[dracut]], you may need a more extensive list of parameters, try:<br />
<br />
kernel_cmdline="rd.luks.uuid=luks-''deviceUUID'' rd.lvm.lv=''MyVolGroup''/root rd.lvm.lv=''MyVolGroup''/swap root=/dev/mapper/''MyVolGroup''-root rootfstype=ext4 rootflags=rw,relatime"<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.<br />
{{tip|Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. }}<br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.<br />
<br />
If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for {{ic|/home}} (or any other volume), a procedure to do so is described in [[dm-crypt/Specialties#Expanding LVM on multiple disks]]. It is important to note that the LUKS encrypted container has to be resized as well.<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#LUKS on a partition]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
<br />
{{Text art|<nowiki><br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
| Boot partition | dm-crypt plain encrypted volume | LUKS2 encrypted volume | LUKS2 encrypted volume |<br />
| | | | |<br />
| /boot | [SWAP] | / | /home |<br />
| | | | |<br />
| | /dev/mapper/swap | /dev/mapper/root | /dev/mapper/home |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | /dev/MyVolGroup/cryptswap | /dev/MyVolGroup/cryptroot | /dev/MyVolGroup/crypthome |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | |<br />
| /dev/sda1 | /dev/sda2 |<br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[dm-crypt/Drive preparation#dm-crypt wipe on an empty disk or partition]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# pvcreate /dev/sda2<br />
# vgcreate MyVolGroup /dev/sda2<br />
# lvcreate -L 32G -n cryptroot MyVolGroup<br />
# lvcreate -L 500M -n cryptswap MyVolGroup<br />
# lvcreate -L 500M -n crypttmp MyVolGroup<br />
# lvcreate -l 100%FREE -n crypthome MyVolGroup<br />
<br />
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot<br />
# cryptsetup open /dev/MyVolGroup/cryptroot root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]].<br />
<br />
{{Tip|If you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show up|LVM shows up]].}}<br />
<br />
=== Preparing the boot partition ===<br />
<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress<br />
# mkfs.ext4 /dev/sda1<br />
# mkdir /mnt/boot<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''lvm2''' '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/MyVolGroup/cryptroot}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
Both [[crypttab]] and [[fstab]] entries are required to both unlock the device and mount the filesystems, respectively. The following lines will re-encrypt the temporary filesystems on each reboot:<br />
<br />
{{hc|/etc/crypttab|2=<br />
swap /dev/MyVolGroup/cryptswap /dev/urandom swap,cipher=aes-xts-plain64,size=256<br />
tmp /dev/MyVolGroup/crypttmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
=== Encrypting logical volume /home ===<br />
<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.<br />
To save on entering a second passphrase at boot, a [[dm-crypt/Device encryption#Keyfiles|keyfile]] is created:<br />
<br />
# mkdir -m 700 /etc/luks-keys<br />
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress<br />
<br />
The logical volume is encrypted with it:<br />
<br />
# cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
# cryptsetup -d /etc/luks-keys/home open /dev/MyVolGroup/crypthome home<br />
# mkfs.ext4 /dev/mapper/home<br />
# mount /dev/mapper/home /home<br />
<br />
The encrypted mount is configured in both [[crypttab]] and [[fstab]]:<br />
<br />
{{hc|/etc/crypttab|<br />
home /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2<br />
}}<br />
<br />
== LUKS on software RAID ==<br />
<br />
This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including {{ic|/boot}}) for all drives, with the SSDs in a [[RAID|RAID0]] array, and keyfiles used to unlock all encryption after [[GRUB]] is given a correct passphrase at boot.<br />
<br />
This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at {{ic|/}} (no separate {{ic|/boot}} partition), and the decrypted HDD being mounted at {{ic|/data}}.<br />
<br />
Please note that regular [[System backup|backups]] are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different [[RAID#Standard RAID levels|RAID level]] if fault tolerance is important to you. <br />
<br />
The encryption is not deniable in this setup.<br />
<br />
For the sake of the instructions below, the following block devices are used:<br />
<br />
/dev/sda = first SSD<br />
/dev/sdb = second SSD<br />
/dev/sdc = HDD<br />
<br />
{{Text art|<nowiki><br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
| BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | LUKS2 encrypted volume |<br />
| | | | | | | | | |<br />
| | /efi | / | | | /efi | / | | /data |<br />
| | | | | | | | | |<br />
| | | /dev/mapper/root | | | | /dev/mapper/root | | |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ | |<br />
| | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | | | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | | |<br />
| | | | | | | | | |<br />
| | /dev/md/ESP | /dev/md/root | | | /dev/md/ESP | /dev/md/root | | /dev/mapper/data |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ +---------------------------+<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 | | /dev/sdb1 | /dev/sdb2 | /dev/sdb3 | | /dev/sdc1 |<br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
</nowiki>}}<br />
<br />
Be sure to substitute them with the appropriate device designations for your setup, as they may be different.<br />
<br />
=== Preparing the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#BIOS systems|BIOS systems]] with GPT, create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
In the remaining space on the drive create a partition ({{ic|/dev/sda3}} in this example) for "Linux RAID". Choose partition type ID {{ic|fd}} for MBR or partition type GUID {{ic|A19D880F-05FC-4D3B-A006-743F0F84911E}} for GPT.<br />
<br />
Once partitions have been created on {{ic|/dev/sda}}, the following commands can be used to clone them to {{ic|/dev/sdb}}.<br />
<br />
# sfdisk -d /dev/sda > sda.dump<br />
# sfdisk /dev/sdb < sda.dump<br />
<br />
The HDD is prepared with a single Linux partition covering the whole drive at {{ic|/dev/sdc1}}.<br />
<br />
=== Building the RAID array ===<br />
<br />
Create the RAID array for the SSDs.<br />
<br />
{{Note|<br />
* All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.<br />
* The RAID superblock must be placed at the end of the EFI system partition using {{ic|1=--metadata=1.0}}, otherwise the firmware will not be able to access the partition.<br />
}}<br />
<br />
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2<br />
<br />
This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.<br />
<br />
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3<br />
<br />
=== Preparing the block devices ===<br />
<br />
As explained in [[dm-crypt/Drive preparation]], the devices are wiped with random data utilizing {{ic|/dev/zero}} and a crypt device with a random key. Alternatively, you could use {{ic|dd}} with {{ic|/dev/random}} or {{ic|/dev/urandom}}, though it will be much slower.<br />
<br />
# cryptsetup open --type plain /dev/md/root container --key-file /dev/random<br />
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress<br />
# cryptsetup close container<br />
<br />
And repeat above for the HDD ({{ic|/dev/sdc1}} in this example).<br />
<br />
Set up encryption for {{ic|/dev/md/root}}:<br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root<br />
# cryptsetup open /dev/md/root root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
And repeat for the HDD:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdc1<br />
# cryptsetup open /dev/sdc1 data<br />
# mkfs.ext4 /dev/mapper/data<br />
# mkdir /mnt/data<br />
# mount /dev/mapper/data /mnt/data<br />
<br />
For UEFI systems, set up the EFI system partition:<br />
<br />
# mkfs.fat -F32 /dev/md/ESP<br />
# mount /dev/md/ESP /mnt/efi<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure [[GRUB]] for the LUKS1 encrypted system by editing {{ic|/etc/default/grub}} with the following:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"<br />
GRUB_ENABLE_CRYPTODISK=y<br />
<br />
{{Move|GRUB#Troubleshooting|GRUB troubleshooting issues belong in the [[GRUB]] page. It should be moved there and simply linked from this section.}}<br />
<br />
If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_TERMINAL_INPUT="usb_keyboard"<br />
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"<br />
<br />
Otherwise you may not be able to use your keyboard at the LUKS prompt.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] and [[GRUB#Encrypted /boot]] for details.<br />
<br />
Complete the GRUB install to both SSDs (in reality, installing only to {{ic|/dev/sda}} will work).<br />
<br />
# grub-install --target=i386-pc /dev/sda<br />
# grub-install --target=i386-pc /dev/sdb<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Creating the keyfiles ===<br />
<br />
The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a [[dm-crypt/Device encryption#Keyfiles|keyfile]] for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] for details.<br />
<br />
* Create the [[dm-crypt/Device encryption#Keyfiles|keyfile]] and add the key to {{ic|/dev/md/root}}.<br />
* Create another keyfile for the HDD ({{ic|/dev/sdc1}}) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit {{ic|/etc/crypttab}} to decrypt the HDD at boot. See [[Dm-crypt/System configuration#Unlocking with a keyfile]].<br />
<br />
=== Configuring the system ===<br />
<br />
Edit [[fstab]] to mount the root and data block devices and the ESP:<br />
<br />
/dev/mapper/root / ext4 rw,noatime 0 1<br />
/dev/mapper/data /data ext4 defaults 0 2<br />
/dev/md/ESP /efi vfat rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro 0 2<br />
<br />
Save the RAID configuration:<br />
<br />
# mdadm --detail --scan >> /etc/mdadm.conf<br />
<br />
Edit [[mkinitcpio.conf]] to include your keyfile and add the proper hooks:<br />
<br />
FILES=(/crypto_keyfile.bin)<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''mdadm_udev''' '''encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details.<br />
<br />
== Plain dm-crypt ==<br />
<br />
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].<br />
<br />
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.<br />
<br />
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Data-at-rest encryption#Cryptographic metadata]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:<br />
* [[dm-crypt/Specialties#Encrypted system using a detached LUKS header|dm-crypt LUKS mode with a detached header]] by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook may be modified.<br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function.<br />
}}<br />
<br />
The scenario uses two USB sticks:<br />
<br />
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;<br />
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
The disk layout is:<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+ +----------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot device | | Encryption key |<br />
| | | | | | | file storage |<br />
| / | [SWAP] | /home | | /boot | | (unpartitioned |<br />
| | | | | | | in example) |<br />
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1 | | /dev/sdc |<br />
|----------------------+----------------------+----------------------| |----------------| |----------------|<br />
| disk drive /dev/sda encrypted using plain mode and LVM | | USB stick 1 | | USB stick 2 |<br />
+--------------------------------------------------------------------+ +----------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* It is also possible to use a single USB key physical device:<br />
** By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).<br />
** By copying the keyfile to the initramfs directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initramfs image by setting {{ic|1=FILES=(/etc/keyfile)}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initramfs image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|1=cryptkey=rootfs:/etc/keyfile}}.<br />
* Another option is using a passphrase with good [[Security#Choosing secure passwords|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.<br />
<br />
See [[dm-crypt/Drive preparation]] and [[dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for plain mode]] for details.<br />
<br />
Using the device {{ic|/dev/sda}}, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, and key file details.<br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/cryptlvm}}:<br />
<br />
# fdisk -l<br />
<br />
{{Tip|A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.}} <br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device. See [[Install Arch Linux on LVM]] for further details:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -L 10G MyVolGroup -n swap<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
We format and mount them and activate swap. See [[File systems#Create a file system]] for further details:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/MyVolGroup/home /mnt/home<br />
# mkswap /dev/MyVolGroup/swap<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a [[Partitioning#Partitioning tools|partitioning tool]] of your choice.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
# mkdir /mnt/boot<br />
# mount /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following [[kernel parameters]] need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):<br />
<br />
cryptdevice=/dev/disk/by-id/''disk-ID-of-sda'':cryptlvm cryptkey=/dev/disk/by-id/''disk-ID-of-sdc'':0:64 crypto=:aes-xts-plain64:512:0:<br />
<br />
The {{ic|''disk-ID-of-'''disk'''''}} refers to the id of the referenced disk. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
<br />
# grub-install --recheck /dev/sdb<br />
<br />
}}<br />
<br />
=== Post-installation ===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sdb1<br />
/dev/sdb1 /boot vfat '''noauto''',rw,noatime 0 2<br />
}}<br />
<br />
However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration as the previous [[#LVM on LUKS]] section, with the difference that the [[GRUB]] boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted {{ic|/boot}}. See also [[GRUB#Encrypted /boot]].<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 |----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS1 |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].<br />
* You can use {{ic|cryptboot}} script from {{AUR|cryptboot}} package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Evil Maid] attacks with [[Secure Boot#Using your own keys|UEFI Secure Boot]]. For more information and limitations see [https://github.com/kmille/cryptboot cryptboot project] page.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS/GPT systems]] create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition. For BIOS/MBR systems this is not necessary.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
Create a partition of type {{ic|8309}}, which will later contain the encrypted container for the LVM.<br />
<br />
Create the LUKS encrypted container:<br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
# cryptsetup luksFormat --type luks1 /dev/sda3<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
<br />
{{hc|# gdisk -l /dev/sda|<br />
...<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 4095 1024.0 KiB EF02 BIOS boot partition<br />
2 4096 1130495 550.0 MiB EF00 EFI System<br />
3 1130496 68239360 32.0 GiB 8309 Linux LUKS<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda3 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the [[#LVM on LUKS]] scenario. Therefore, please follow [[#Preparing the logical volumes]] above and adjust as required.<br />
<br />
If you plan to boot in UEFI mode, create a mountpoint for the [[EFI system partition]] at {{ic|/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mkdir /mnt/efi<br />
# mount /dev/sda2 /mnt/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
<br />
{{hc|$ lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk<br />
├─sda1 8:1 0 1M 0 part<br />
├─sda2 8:2 0 550M 0 part /mnt/efi<br />
└─sda3 8:3 0 100G 0 part<br />
└─cryptlvm 254:0 0 100G 0 crypt<br />
├─MyVolGroup-swap 254:1 0 8G 0 lvm [SWAP]<br />
├─MyVolGroup-root 254:2 0 32G 0 lvm /mnt<br />
└─MyVolGroup-home 254:3 0 60G 0 lvm /mnt/home<br />
}}<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure GRUB to allow booting from {{ic|/boot}} on a LUKS1 encrypted partition:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the {{ic|encrypt}} hook:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''device-UUID'':cryptlvm ..."<br />
}}<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... rd.luks.name=''device-UUID''=cryptlvm ..."<br />
}}<br />
<br />
See [[dm-crypt/System configuration#Boot loader]] and [[GRUB#Encrypted /boot]] for details. The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda3}} (the partition which holds the lvm containing the root filesystem). See [[Persistent block device naming]].<br />
<br />
[[GRUB#Installation_2|install GRUB]] to the mounted ESP for UEFI booting:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck<br />
<br />
[[GRUB#Installation|install GRUB]] to the disk for BIOS booting:<br />
<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
<br />
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If all commands finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/dev/sda3}} partition after the next reboot.<br />
<br />
=== Avoiding having to enter the passphrase twice ===<br />
<br />
{{Merge|Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|Too much duplicated content, too much detail here for this overview page.|section=Security Issue with Grub Keyfile}}<br />
<br />
While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.<br />
<br />
This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs|with a keyfile embedded in the initramfs]].<br />
<br />
First create a keyfile and add it as LUKS key:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock<br />
# chmod 000 /root/cryptlvm.keyfile<br />
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile<br />
<br />
Add the keyfile to the initramfs image:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/root/cryptlvm.keyfile)<br />
}}<br />
<br />
Recreate the initramfs image and secure the embedded keyfile:<br />
<br />
# chmod 600 /boot/initramfs-linux*<br />
<br />
Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the {{ic|encrypt}} hook:<br />
<br />
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"<br />
<br />
Or, using the [[sd-encrypt]] hook:<br />
<br />
GRUB_CMDLINE_LINUX="... rd.luks.key=''device-UUID''=/root/cryptlvm.keyfile"<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}<br />
<br />
== Btrfs subvolumes with swap ==<br />
<br />
{{Out of date|Btrfs [[Btrfs#Swap_file|supports swapfile]] since 5.0|Talk:Dm-crypt/Encrypting_an_entire_system#Complete_guide_of_Btrfs_on_LUKS_full_disk_encryption}}<br />
The following example creates a full system encryption with LUKS1 using [[Btrfs]] subvolumes to [[Btrfs#Mounting subvolumes|simulate partitions]].<br />
<br />
If using UEFI, an [[EFI system partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda1}} and is mounted at {{ic|/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda2}}.<br />
<br />
Since {{ic|/boot}} resides on the LUKS1 encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod).<br />
<br />
Additionally an optional plain-encrypted [[swap]] partition is shown.<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+<br />
| EFI system partition | System partition | Swap partition |<br />
| unencrypted | LUKS1-encrypted | plain-encrypted |<br />
| | | |<br />
| /efi | / | [SWAP] |<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 |<br />
|----------------------+----------------------+----------------------+<br />
</nowiki>}}<br />
<br />
=== Preparing the disk ===<br />
<br />
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI system partition]] with an appropriate size. It will later be mounted at {{ic|/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.<br />
<br />
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}). See the [[Partitioning]] article.<br />
<br />
=== Preparing the system partition ===<br />
<br />
==== Create LUKS container ====<br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda2}} for LUKS. See the [[dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.<br />
<br />
==== Unlock LUKS container ====<br />
<br />
Now follow [[dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.<br />
<br />
==== Format mapped device ====<br />
<br />
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|/dev/mapper/''root''}}) and '''not''' {{ic|/dev/sda2}}.<br />
<br />
==== Mount mapped device ====<br />
<br />
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/root}}) to {{ic|/mnt}}.<br />
<br />
=== Creating btrfs subvolumes ===<br />
<br />
{{Merge|Btrfs|The subvolume layout is not specific to an encrypted system.}}<br />
<br />
==== Layout ====<br />
<br />
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:<br />
<br />
{{Text art|<nowiki><br />
subvolid=5<br />
|<br />
├── @ -|<br />
| contained directories:<br />
| ├── /usr<br />
| ├── /bin<br />
| ├── /.snapshots<br />
| ├── ...<br />
|<br />
├── @home<br />
├── @snapshots<br />
├── @var_log<br />
└── @...<br />
</nowiki>}}<br />
<br />
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].<br />
<br />
==== Create subvolumes for initial mount ====<br />
<br />
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.<br />
<br />
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.<br />
<br />
Create any additional subvolumes you wish to use as mount points now.<br />
<br />
==== Create subvolumes for excludes ====<br />
<br />
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.<br />
<br />
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.<br />
<br />
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.<br />
<br />
==== Mount top-level subvolumes ====<br />
<br />
Unmount the system partition at {{ic|/mnt}}.<br />
<br />
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|root}}, the command would look like:<br />
<br />
# mount -o compress=zstd,subvol=@ /dev/mapper/root /mnt<br />
<br />
See [[Btrfs#Mounting subvolumes]] for more details.<br />
<br />
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.<br />
<br />
==== Mount ESP ====<br />
<br />
If you prepared an EFI system partition earlier, create its mount point and mount it now.<br />
<br />
{{Note|Btrfs snapshots will exclude {{ic|/efi}}, since it is not a btrfs file system.}}<br />
<br />
At the [[Installation guide#Install essential packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the {{Pkg|base}} [[meta package]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
==== Create keyfile ====<br />
<br />
In order for GRUB to open the LUKS partition without having the user enter their passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda2}} at the ''luksAddKey'' step.<br />
<br />
==== Edit mkinitcpio.conf ====<br />
<br />
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require. See [[dm-crypt/System configuration#mkinitcpio]] for detailed information.<br />
<br />
{{Tip|You may want to add {{ic|1=BINARIES=(btrfs)}} to your {{ic|/etc/mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}<br />
<br />
=== Configuring the boot loader ===<br />
<br />
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Additional arguments]], [[GRUB#Encrypted /boot]] and [[dm-crypt/System configuration#Using encrypt hook]], following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file. Note that you will need to pass kernel parameters for the root mount point as instructed in [[Btrfs#Mounting subvolume as root]].<br />
<br />
=== Configuring swap ===<br />
<br />
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[dm-crypt/Swap encryption]].<br />
<br />
== Root on ZFS ==<br />
<br />
Root on [[ZFS]] can be configured to encrypt everything except boot loader. See [https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Arch%20Linux%20Root%20on%20ZFS.html installation guide] on OpenZFS page.<br />
<br />
Boot loader can be verified with [[Secure Boot]] on UEFI-based systems.<br />
<br />
See also [[ZFS#Encryption in ZFS using dm-crypt]].</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:GnuPG&diff=718604Talk:GnuPG2022-02-16T15:48:30Z<p>RaZorr: Align text</p>
<hr />
<div>== System login with gnupg smartcard (yubikey, p-card, rsa token, etc) ==<br />
gnupg with [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=poldi.git poldi] can be used for system login. There is a [https://bbs.archlinux.org/viewtopic.php?id=215554 thread] asking whether it is possible to use gpg for system login.<br />
A new tip section explaining gnupg smartcard for logging into Arch Linux system is a nice addition here.<br />
<br />
[[User:Alive4ever|Alive4ever]] ([[User talk:Alive4ever|talk]]) 02:27, 4 August 2016 (UTC)<br />
<br />
== User configuration files not created ==<br />
<br />
Per the wiki, it states, "You will find skeleton files in /usr/share/gnupg. These files are copied to ~/.gnupg the first time gpg is run if they do not exist there."<br />
<br />
I could very well be doing something wrong so I'd ask that this could be verified. If we need to copy skel configuration files, it should be clearly explained in the wiki shouldn't it?<br />
<br />
I was unable to import public keys until I manually created a blank ~/.gnupg/gpg.conf with just keyserver pgp.mit.edu in it. <br />
<br />
I also found this when searching for info, https://manned.org/gpgv2/2862e42d. It states: There are no configuration files and only a few options are implemented.<br />
<br />
[[User:NuSkool|NuSkool]] ([[User talk:NuSkool|talk]]) 04:09, 26 September 2016 (UTC)<br />
<br />
:On the same topic but on a different note, update [[GnuPG#Configuration_files]] to remove ''out of date warning'' and add the following informtion:<br />
:1) '''~/.gnupg/gpg.conf''' and '''~/.gnupg/dirmngr.conf''' are not created by default. So, the user can create them to implement the changes.<br />
:2) global config file is located at '''/etc/gnupg/gpgconf.conf''' shown by command '''gpgconf --list-config'''. This is also not created by default. The example file is <br />
:at '''/usr/share/doc/gnupg/examples/gpgconf.conf'''<br />
:--[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 12:51, 16 January 2022 (UTC)<br />
<br />
== Recommendation to add ==<br />
<br />
By default, no skeleton files exist (as mentioned above) but in my case the lack of a dirmngr.conf meant that any --recv-keys failed with useful(?) errors like "gpg: keyserver receive failed: Server indicated a failure" or "gpg: error searching keyserver: Server indicated a failure". Route to get here was via makepkg, and so I skipped all the installation steps etc since gpg was already installed and went straight for a recv.<br />
<br />
echo > $HOME/.gnupg/dirmngr.conf 'standard-resolver'<br />
[[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 17:09, 22 March 2020 (UTC)<br />
<br />
== A comment on provided code snippet ==<br />
<br />
The test from [[GnuPG#Set_SSH_AUTH_SOCK|Set_SSH_AUTH_SOCK]] : <br />
<br />
[ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]<br />
<br />
would probably always fail, since [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/gpg-agent.c;hb=7bca3be65e510eda40572327b87922834ebe07eb#l1307] sets {{ic|gnupg_SSH_AUTH_SOCK_by}} to the process id of {{ic|gpg-agent}}, and the line above tests it for the process id of the {{ic|bash}} process.<br />
<br />
Therefore, <br />
<br />
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" <br />
<br />
will probably get executed every time. However, it most likely wouldn't break anything since at worst it will reset {{ic|SSH_AUTH_SOCK}} to the same value.<br />
<br />
{{Unsigned| 11:16, 1 May 2021 (UTC)|Thread13}}<br />
<br />
== Invalid IPC response and Inappropriate ioctl for device ==<br />
I solved this problem simply by removing an {{ic|#}} inside {{ic|/etc/pinentry/preexec}} enabling the desired option and then setting {{ic|/usr/bin/pinentry}} as default.<br />
[[User:Pavlov|Pavlov]] ([[User talk:Pavlov|talk]]) 15:19, 2 May 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:EFI_system_partition&diff=718403Talk:EFI system partition2022-02-14T17:43:00Z<p>RaZorr: /* Mention /boot/efi over /boot */ new section</p>
<hr />
<div>== Some firmware requires esp/EFI/BOOT/BOOTX64.EFI path ==<br />
<br />
Had an issue with "no bootable image found" on an HP Elitebook. It appears that someone else had a similar problem here:<br />
<br />
https://forums.opensuse.org/showthread.php/493175-Issues-with-booting-GPT-and-UEFI/page4<br />
<br />
The solution is to change the path from, e.g. esp/EFI/arch_grub/grubx64.efi to esp/EFI/BOOT/BOOTX64.EFI (simply by copying the efi file).<br />
<br />
Is this worth adding to the Troubleshooting section?<br />
<br />
{{unsigned|13:26, 1 June 2020|Kolo}}<br />
<br />
:The solution should already be in all boot loader pages ([[GRUB#Default/fallback boot path]], [[rEFInd#Installation with refind-install script]], [[Syslinux#Installation on UEFI]], etc.).<br />
:The default/fallback boot path is also briefly mentioned in [[Arch boot process#Under UEFI]] and [[Unified Extensible Firmware Interface]], though not in the context of this issue. Since the issue is not relevant to the [[EFI system partition]] page, it should not be added here. If you want to document it (in a boot-loader-agnostic way), feel free to do so in [[Unified Extensible Firmware Interface#Troubleshooting]].<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:55, 2 June 2020 (UTC)<br />
<br />
== Mounting the partition is not mandatory ==<br />
<br />
I run GRUB in my UEFI/GPT setup, and I don't mount the EFI partition when booting the OS. In fact, I created the {{ic|/efi}} directory but don't use it. This should be mentioned, IMO - [[User:Megver83|Megver83]] ([[User talk:Megver83|talk]]) 05:06, 3 August 2020 (UTC)<br />
<br />
:It could be mentioned, but It needs to be clear that it doesn't apply when mounting it to {{ic|/boot}}. E.g., something along the lines of: "If the EFI system partition's mountpoint (or bind mount) is not {{ic|/boot}}, it can be left unmounted during everyday system usage. For example, configure {{ic|/etc/fstab}} to [[fstab#Local partition|mount it on first access]]..." -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:26, 3 August 2020 (UTC)<br />
<br />
== Add systemd automatic intel-ucode.img moving under alternate mount points ==<br />
<br />
Under the systemd section of the alternate mount points part of the page, would it make sense to also add a task triggered on the changing of /boot/intel-ucode.img that copied /boot/intel-ucode.img to the esp?<br />
[[User:Dghosef|Dghosef]] ([[User talk:Dghosef|talk]]) 01:56, 2 December 2020 (UTC)Dghosef[[User:Dghosef|Dghosef]] ([[User talk:Dghosef|talk]]) 01:56, 2 December 2020 (UTC)<br />
<br />
:Since {{ic|/boot/intel-ucode.img}} and {{ic|/boot/amd-ucode.img}} are packaged, it would IMHO make more sense to copy them using a [[pacman hook]] instead of systemd path. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:37, 2 December 2020 (UTC)<br />
<br />
== systemctl daemon-reload required on .service ==<br />
<br />
To make changes on /etc/systemd/system/efistub-update.service its required a systemctl daemon-reload<br />
{{Unsigned|13:56, 20 January 2021 (UTC)|Angelettif}}<br />
<br />
== Mention /boot/efi over /boot ==<br />
<br />
Isn't {{ic|/boot/efi}} more preferred over {{ic|/boot}} as it saves more space in the ''esp'' from kernel images and on a multiboot system the ''esp'' and respective {{ic|/boot}} are relatively well-organized, allowing easier backup.<br />
<br />
# I know it's mentioned in the '''TIP''' box but I think it should be given more highlight.<br />
# More importantly, the example layouts in the [[Installation_guide]] should have either {{ic|/mnt/efi}} or {{ic|/mnt/boot/efi}} instead of {{ic|/mnt/boot}}.</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Stalonetray&diff=717748Stalonetray2022-02-11T13:48:27Z<p>RaZorr: Undo revision 717747</p>
<hr />
<div>[[Category:Eye candy]]<br />
[[ja:Stalonetray]]<br />
Stalonetray is a stand-alone freedesktop.org and KDE system tray for the [[X Window System]]. It has full XEMBED support, minimal dependencies and works with virtually any EWMH-compliant window manager. Window managers that are reported to work well with stalonetray are: [[FVWM]], [[Openbox]], [[Enlightenment]], [[Compiz]], [[Xmonad]], [[dwm]], and [[awesome]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|stalonetray}} package. Once installed, copy the {{ic|stalonetrayrc}} file to your home directory (it can also be placed in {{ic|XDG_CONFIG_HOME}} or {{ic|~/.config}}). Note that you should do this as a regular user.<br />
<br />
$ cp /etc/stalonetrayrc ~/.stalonetrayrc<br />
<br />
== Configuration ==<br />
<br />
=== Openbox ===<br />
<br />
To run Stalonetray in Openbox, {{ic|dockapp-mode}} must be set to {{ic|simple}}. This can be accomplished with either the command-line argument {{ic|--dockapp-mode simple}} or by modifying {{ic|~/.stalonetrayrc}}.<br />
<br />
Openbox now treats the tray as the dock, and you can adjust its position by using the Openbox Configuration Tool. To run Stalonetray on start up, add the following to {{ic|~/.config/openbox/autostart}}:<br />
stalonetray --dockapp-mode simple &<br />
<br />
See also [http://stalonetray.sourceforge.net/wmhints.html#openbox Stalonetray WM hints for OpenBox]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Icons do not have the desired size ===<br />
<br />
To force the size of the icons to be equal to icon_size, launch stalonetray with the following arguments:<br />
<br />
stalonetray --icon-size=16 --kludges=force_icons_size<br />
<br />
This will force the size of all icons to 16×16 pixels.<br />
<br />
Alternatively, one could add the following to the configuration file:<br />
<br />
icon_size 16<br />
kludges force_icons_size<br />
<br />
== See also ==<br />
<br />
* http://stalonetray.sourceforge.net/manpage.html - Stalonetray manual page</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Stalonetray&diff=717747Stalonetray2022-02-11T13:46:50Z<p>RaZorr: .stalonetrayrc to stalonetrayrc</p>
<hr />
<div>[[Category:Eye candy]]<br />
[[ja:Stalonetray]]<br />
Stalonetray is a stand-alone freedesktop.org and KDE system tray for the [[X Window System]]. It has full XEMBED support, minimal dependencies and works with virtually any EWMH-compliant window manager. Window managers that are reported to work well with stalonetray are: [[FVWM]], [[Openbox]], [[Enlightenment]], [[Compiz]], [[Xmonad]], [[dwm]], and [[awesome]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|stalonetray}} package. Once installed, copy the {{ic|stalonetrayrc}} file to your home directory (it can also be placed in {{ic|XDG_CONFIG_HOME}} or {{ic|~/.config}}). Note that you should do this as a regular user.<br />
<br />
$ cp /etc/stalonetrayrc ~/stalonetrayrc<br />
<br />
== Configuration ==<br />
<br />
=== Openbox ===<br />
<br />
To run Stalonetray in Openbox, {{ic|dockapp-mode}} must be set to {{ic|simple}}. This can be accomplished with either the command-line argument {{ic|--dockapp-mode simple}} or by modifying {{ic|~/.stalonetrayrc}}.<br />
<br />
Openbox now treats the tray as the dock, and you can adjust its position by using the Openbox Configuration Tool. To run Stalonetray on start up, add the following to {{ic|~/.config/openbox/autostart}}:<br />
stalonetray --dockapp-mode simple &<br />
<br />
See also [http://stalonetray.sourceforge.net/wmhints.html#openbox Stalonetray WM hints for OpenBox]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Icons do not have the desired size ===<br />
<br />
To force the size of the icons to be equal to icon_size, launch stalonetray with the following arguments:<br />
<br />
stalonetray --icon-size=16 --kludges=force_icons_size<br />
<br />
This will force the size of all icons to 16×16 pixels.<br />
<br />
Alternatively, one could add the following to the configuration file:<br />
<br />
icon_size 16<br />
kludges force_icons_size<br />
<br />
== See also ==<br />
<br />
* http://stalonetray.sourceforge.net/manpage.html - Stalonetray manual page</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Stalonetray&diff=717691Stalonetray2022-02-11T11:37:36Z<p>RaZorr: Config file location changes</p>
<hr />
<div>[[Category:Eye candy]]<br />
[[ja:Stalonetray]]<br />
Stalonetray is a stand-alone freedesktop.org and KDE system tray for the [[X Window System]]. It has full XEMBED support, minimal dependencies and works with virtually any EWMH-compliant window manager. Window managers that are reported to work well with stalonetray are: [[FVWM]], [[Openbox]], [[Enlightenment]], [[Compiz]], [[Xmonad]], [[dwm]], and [[awesome]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|stalonetray}} package. Once installed, copy the {{ic|stalonetrayrc}} file to your home directory (it can also be placed in {{ic|XDG_CONFIG_HOME}} or {{ic|~/.config}}). Note that you should do this as a regular user.<br />
<br />
$ cp /etc/stalonetrayrc ~/.stalonetrayrc<br />
<br />
== Configuration ==<br />
<br />
=== Openbox ===<br />
<br />
To run Stalonetray in Openbox, {{ic|dockapp-mode}} must be set to {{ic|simple}}. This can be accomplished with either the command-line argument {{ic|--dockapp-mode simple}} or by modifying {{ic|~/.stalonetrayrc}}.<br />
<br />
Openbox now treats the tray as the dock, and you can adjust its position by using the Openbox Configuration Tool. To run Stalonetray on start up, add the following to {{ic|~/.config/openbox/autostart}}:<br />
stalonetray --dockapp-mode simple &<br />
<br />
See also [http://stalonetray.sourceforge.net/wmhints.html#openbox Stalonetray WM hints for OpenBox]<br />
<br />
== Troubleshooting ==<br />
<br />
=== Icons do not have the desired size ===<br />
<br />
To force the size of the icons to be equal to icon_size, launch stalonetray with the following arguments:<br />
<br />
stalonetray --icon-size=16 --kludges=force_icons_size<br />
<br />
This will force the size of all icons to 16×16 pixels.<br />
<br />
Alternatively, one could add the following to the configuration file:<br />
<br />
icon_size 16<br />
kludges force_icons_size<br />
<br />
== See also ==<br />
<br />
* http://stalonetray.sourceforge.net/manpage.html - Stalonetray manual page</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:ConnMan&diff=710595Talk:ConnMan2022-01-17T10:01:11Z<p>RaZorr: spelling mistake</p>
<hr />
<div>== An unintelligible sentence ==<br />
<br />
<div style="border-style: dashed; border-width: 1px; background-color: #ECEBFA">To connect to an open network simple use the enter the second field beginning with '''wifi_''':</div><br />
What is that supposed to mean? [[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:34, 13 June 2014 (UTC)<br />
<br />
:Is [https://wiki.archlinux.org/index.php?title=Connman&curid=9462&diff=356332&oldid=356124] better? The article has other clarity issues, though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:50, 12 January 2015 (UTC)<br />
<br />
== Resume connection after suspend ==<br />
<br />
On my laptop ([[HCL/Laptops/Lenovo|Thinkpad X61]]) connman doesn't restore the wifi connection after resuming from suspend. To have it working again I have to un/set the physical wifi switch. I've found a workaround, but it's crude and the issue may be hardware-related (though wicd works just fine, maybe because it has resume scripts) so I'm leaving it here for review.<br />
<br />
{{hc|/etc/systemd/system/connman-resume.service|2=<br />
[Unit]<br />
Description=Connman resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart connman.service<br />
ExecStart=/usr/bin/sh -c 'sleep 1; /usr/bin/rfkill unblock 0 1'<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
# systemctl enable connman-resume<br />
<br />
edit: There's a setting in {{ic|connman.conf}}, {{ic|PersistentTetheringMode}}, but it doesn't seem to work. I'll bring this up to the connman mailing list. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 3 February 2015 (UTC)<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 12 January 2015 (UTC)<br />
<br />
== Much of this wiki really old ==<br />
<br />
I just struggled to get this working properly on my laptops and RPIs and there are a couple of details which are important and are not in this wiki.<br />
# the 'using iwd' portion of the wiki is way out of date. No longer required to use the {{ic|1=--wifi=iwd_agent}}. IMO best is to disable wpa_supplicant with {{ic|systemctl disable wpa_supplicant}} if you cannot uninstall it (i.e if you don't want to or cannot uninstall NetworkManager). If you can uninstall it, it is best to do so. In most cases the default iwd and connman services are fine, IMO.<br />
<s># If you want connman to reconnect when the SSID drops and reappears, you must add a line to the /etc/connman/main.conf: {{ic|1=BackgroundScanning = true}}. If this is not added, connman will never tell iwd to re-scan to see if/when the SSID returns and will, therefore, never reconnect.</s> This is wrong according to the connman list, this setting is only for wpa_supplicant and not for iwd. They are working on rescan.<br />
# the Arch package has no tmpfile, for some reason so the connman cannot create /run/connman/resolv.conf. One option is to add a line to the connman.service file: {{ic|1=ExecStartPre=/bin/mkdir -p /run/connman}}, but this is frowned upon in the systemd group and the 'right way', apparently, is to add a file /etc/tmpfiles.d/connman_resolvconf.conf which has the contents:<br />
{{bc|<br />
1=d /run/connman - - - -<br />
L /etc/resolv.conf - - - - /run/connman/resolv.conf}} this way connman can create its resolv.conf and not complain in the journal that the folder does not exist and can nod do DNS lookups.<br />
<br />
:As someone who has repeatedly tried to use connman together with [[iwd]] using the this wiki page and has failed again and again, I think that the information is indeed outdated. I would appreciate if someone with more knowledge took the time write a working {{ic|iwd}} section. [[User:Wlhlm|Wlhlm]] ([[User talk:Wlhlm|talk]]) 17:26, 3 November 2020 (UTC)<br />
<br />
::I agree. [[User:Keithspg|Keithspg]] ([[User talk:Keithspg|talk]])<br />
<br />
== DNS and ntp information ==<br />
<br />
There is information on setting up custom [[NetworkManager#Custom_DNS_servers|DNS for NetworkManager]] and I think the same could be provided for connman. Also, connman is menioned in [[System_time#Time_synchronization]] section. So, a section for configuring ntp servers for connman would also be nice. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 10:00, 17 January 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:ConnMan&diff=710594Talk:ConnMan2022-01-17T10:00:31Z<p>RaZorr: Signature</p>
<hr />
<div>== An unintelligible sentence ==<br />
<br />
<div style="border-style: dashed; border-width: 1px; background-color: #ECEBFA">To connect to an open network simple use the enter the second field beginning with '''wifi_''':</div><br />
What is that supposed to mean? [[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:34, 13 June 2014 (UTC)<br />
<br />
:Is [https://wiki.archlinux.org/index.php?title=Connman&curid=9462&diff=356332&oldid=356124] better? The article has other clarity issues, though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:50, 12 January 2015 (UTC)<br />
<br />
== Resume connection after suspend ==<br />
<br />
On my laptop ([[HCL/Laptops/Lenovo|Thinkpad X61]]) connman doesn't restore the wifi connection after resuming from suspend. To have it working again I have to un/set the physical wifi switch. I've found a workaround, but it's crude and the issue may be hardware-related (though wicd works just fine, maybe because it has resume scripts) so I'm leaving it here for review.<br />
<br />
{{hc|/etc/systemd/system/connman-resume.service|2=<br />
[Unit]<br />
Description=Connman resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart connman.service<br />
ExecStart=/usr/bin/sh -c 'sleep 1; /usr/bin/rfkill unblock 0 1'<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
# systemctl enable connman-resume<br />
<br />
edit: There's a setting in {{ic|connman.conf}}, {{ic|PersistentTetheringMode}}, but it doesn't seem to work. I'll bring this up to the connman mailing list. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 3 February 2015 (UTC)<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 12 January 2015 (UTC)<br />
<br />
== Much of this wiki really old ==<br />
<br />
I just struggled to get this working properly on my laptops and RPIs and there are a couple of details which are important and are not in this wiki.<br />
# the 'using iwd' portion of the wiki is way out of date. No longer required to use the {{ic|1=--wifi=iwd_agent}}. IMO best is to disable wpa_supplicant with {{ic|systemctl disable wpa_supplicant}} if you cannot uninstall it (i.e if you don't want to or cannot uninstall NetworkManager). If you can uninstall it, it is best to do so. In most cases the default iwd and connman services are fine, IMO.<br />
<s># If you want connman to reconnect when the SSID drops and reappears, you must add a line to the /etc/connman/main.conf: {{ic|1=BackgroundScanning = true}}. If this is not added, connman will never tell iwd to re-scan to see if/when the SSID returns and will, therefore, never reconnect.</s> This is wrong according to the connman list, this setting is only for wpa_supplicant and not for iwd. They are working on rescan.<br />
# the Arch package has no tmpfile, for some reason so the connman cannot create /run/connman/resolv.conf. One option is to add a line to the connman.service file: {{ic|1=ExecStartPre=/bin/mkdir -p /run/connman}}, but this is frowned upon in the systemd group and the 'right way', apparently, is to add a file /etc/tmpfiles.d/connman_resolvconf.conf which has the contents:<br />
{{bc|<br />
1=d /run/connman - - - -<br />
L /etc/resolv.conf - - - - /run/connman/resolv.conf}} this way connman can create its resolv.conf and not complain in the journal that the folder does not exist and can nod do DNS lookups.<br />
<br />
:As someone who has repeatedly tried to use connman together with [[iwd]] using the this wiki page and has failed again and again, I think that the information is indeed outdated. I would appreciate if someone with more knowledge took the time write a working {{ic|iwd}} section. [[User:Wlhlm|Wlhlm]] ([[User talk:Wlhlm|talk]]) 17:26, 3 November 2020 (UTC)<br />
<br />
::I agree. [[User:Keithspg|Keithspg]] ([[User talk:Keithspg|talk]])<br />
<br />
== DNS and ntp information ==<br />
<br />
There is information on setting up custom [[NetworkManager#Custom_DNS_servers|DNS for NetworkManager]] and I think the same could be provided for connman. Also, connman in menioned in [[System_time#Time_synchronization]] section. So, a section for configuring ntp servers for connman would also be nice. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 10:00, 17 January 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:GnuPG&diff=710489Talk:GnuPG2022-01-16T12:52:02Z<p>RaZorr: Add info on gpg config files</p>
<hr />
<div>== System login with gnupg smartcard (yubikey, p-card, rsa token, etc) ==<br />
gnupg with [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=poldi.git poldi] can be used for system login. There is a [https://bbs.archlinux.org/viewtopic.php?id=215554 thread] asking whether it is possible to use gpg for system login.<br />
A new tip section explaining gnupg smartcard for logging into Arch Linux system is a nice addition here.<br />
<br />
[[User:Alive4ever|Alive4ever]] ([[User talk:Alive4ever|talk]]) 02:27, 4 August 2016 (UTC)<br />
<br />
== User configuration files not created ==<br />
<br />
Per the wiki, it states, "You will find skeleton files in /usr/share/gnupg. These files are copied to ~/.gnupg the first time gpg is run if they do not exist there."<br />
<br />
I could very well be doing something wrong so I'd ask that this could be verified. If we need to copy skel configuration files, it should be clearly explained in the wiki shouldn't it?<br />
<br />
I was unable to import public keys until I manually created a blank ~/.gnupg/gpg.conf with just keyserver pgp.mit.edu in it. <br />
<br />
I also found this when searching for info, https://manned.org/gpgv2/2862e42d. It states: There are no configuration files and only a few options are implemented.<br />
<br />
[[User:NuSkool|NuSkool]] ([[User talk:NuSkool|talk]]) 04:09, 26 September 2016 (UTC)<br />
<br />
:On the same topic but on a different note, update [[GnuPG#Configuration_files]] to remove ''out of date warning'' and add the following informtion:<br />
1) '''~/.gnupg/gpg.conf''' and '''~/.gnupg/dirmngr.conf''' are not created by default. So, the user can create them to implement the changes.<br />
2) global config file is located at '''/etc/gnupg/gpgconf.conf''' shown by command '''gpgconf --list-config'''. This is also not created by default. The example file is <br />
at '''/usr/share/doc/gnupg/examples/gpgconf.conf'''<br />
--[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 12:51, 16 January 2022 (UTC)<br />
== Recommendation to add ==<br />
<br />
By default, no skeleton files exist (as mentioned above) but in my case the lack of a dirmngr.conf meant that any --recv-keys failed with useful(?) errors like "gpg: keyserver receive failed: Server indicated a failure" or "gpg: error searching keyserver: Server indicated a failure". Route to get here was via makepkg, and so I skipped all the installation steps etc since gpg was already installed and went straight for a recv.<br />
<br />
echo > $HOME/.gnupg/dirmngr.conf 'standard-resolver'<br />
[[User:Beepboo|Beepboo]] ([[User talk:Beepboo|talk]]) 17:09, 22 March 2020 (UTC)<br />
<br />
== A comment on provided code snippet ==<br />
<br />
The test from [[GnuPG#Set_SSH_AUTH_SOCK|Set_SSH_AUTH_SOCK]] : <br />
<br />
[ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]<br />
<br />
would probably always fail, since [https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/gpg-agent.c;hb=7bca3be65e510eda40572327b87922834ebe07eb#l1307] sets {{ic|gnupg_SSH_AUTH_SOCK_by}} to the process id of {{ic|gpg-agent}}, and the line above tests it for the process id of the {{ic|bash}} process.<br />
<br />
Therefore, <br />
<br />
export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" <br />
<br />
will probably get executed every time. However, it most likely wouldn't break anything since at worst it will reset {{ic|SSH_AUTH_SOCK}} to the same value.<br />
<br />
{{Unsigned| 11:16, 1 May 2021 (UTC)|Thread13}}<br />
<br />
== Invalid IPC response and Inappropriate ioctl for device ==<br />
I solved this problem simply by removing an {{ic|#}} inside {{ic|/etc/pinentry/preexec}} enabling the desired option and then setting {{ic|/usr/bin/pinentry}} as default.<br />
[[User:Pavlov|Pavlov]] ([[User talk:Pavlov|talk]]) 15:19, 2 May 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:ConnMan&diff=709975Talk:ConnMan2022-01-14T10:17:12Z<p>RaZorr: /* DNS and ntp information */ new section</p>
<hr />
<div>== An unintelligible sentence ==<br />
<br />
<div style="border-style: dashed; border-width: 1px; background-color: #ECEBFA">To connect to an open network simple use the enter the second field beginning with '''wifi_''':</div><br />
What is that supposed to mean? [[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:34, 13 June 2014 (UTC)<br />
<br />
:Is [https://wiki.archlinux.org/index.php?title=Connman&curid=9462&diff=356332&oldid=356124] better? The article has other clarity issues, though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:50, 12 January 2015 (UTC)<br />
<br />
== Resume connection after suspend ==<br />
<br />
On my laptop ([[HCL/Laptops/Lenovo|Thinkpad X61]]) connman doesn't restore the wifi connection after resuming from suspend. To have it working again I have to un/set the physical wifi switch. I've found a workaround, but it's crude and the issue may be hardware-related (though wicd works just fine, maybe because it has resume scripts) so I'm leaving it here for review.<br />
<br />
{{hc|/etc/systemd/system/connman-resume.service|2=<br />
[Unit]<br />
Description=Connman resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart connman.service<br />
ExecStart=/usr/bin/sh -c 'sleep 1; /usr/bin/rfkill unblock 0 1'<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
# systemctl enable connman-resume<br />
<br />
edit: There's a setting in {{ic|connman.conf}}, {{ic|PersistentTetheringMode}}, but it doesn't seem to work. I'll bring this up to the connman mailing list. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 3 February 2015 (UTC)<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 12 January 2015 (UTC)<br />
<br />
== Much of this wiki really old ==<br />
<br />
I just struggled to get this working properly on my laptops and RPIs and there are a couple of details which are important and are not in this wiki.<br />
# the 'using iwd' portion of the wiki is way out of date. No longer required to use the {{ic|1=--wifi=iwd_agent}}. IMO best is to disable wpa_supplicant with {{ic|systemctl disable wpa_supplicant}} if you cannot uninstall it (i.e if you don't want to or cannot uninstall NetworkManager). If you can uninstall it, it is best to do so. In most cases the default iwd and connman services are fine, IMO.<br />
<s># If you want connman to reconnect when the SSID drops and reappears, you must add a line to the /etc/connman/main.conf: {{ic|1=BackgroundScanning = true}}. If this is not added, connman will never tell iwd to re-scan to see if/when the SSID returns and will, therefore, never reconnect.</s> This is wrong according to the connman list, this setting is only for wpa_supplicant and not for iwd. They are working on rescan.<br />
# the Arch package has no tmpfile, for some reason so the connman cannot create /run/connman/resolv.conf. One option is to add a line to the connman.service file: {{ic|1=ExecStartPre=/bin/mkdir -p /run/connman}}, but this is frowned upon in the systemd group and the 'right way', apparently, is to add a file /etc/tmpfiles.d/connman_resolvconf.conf which has the contents:<br />
{{bc|<br />
1=d /run/connman - - - -<br />
L /etc/resolv.conf - - - - /run/connman/resolv.conf}} this way connman can create its resolv.conf and not complain in the journal that the folder does not exist and can nod do DNS lookups.<br />
<br />
:As someone who has repeatedly tried to use connman together with [[iwd]] using the this wiki page and has failed again and again, I think that the information is indeed outdated. I would appreciate if someone with more knowledge took the time write a working {{ic|iwd}} section. [[User:Wlhlm|Wlhlm]] ([[User talk:Wlhlm|talk]]) 17:26, 3 November 2020 (UTC)<br />
<br />
::I agree. [[User:Keithspg|Keithspg]] ([[User talk:Keithspg|talk]])<br />
<br />
== DNS and ntp information ==<br />
<br />
There is information on setting up custom [[NetworkManager#Custom_DNS_servers|DNS for NetworkManager]] and I think the same could be provided for connman. Also, connman in menioned in [[System_time#Time_synchronization]] section. So, a section for configuring ntp servers for connman would also be nice.</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:REFInd&diff=709204Talk:REFInd2022-01-09T13:51:50Z<p>RaZorr: added signature</p>
<hr />
<div>== add a paragraph with simple installation ==<br />
rEFInd changed in 2017 which allows to run with a minimal configuration as it now auto-detects the img file fitting the kernel. with it a minimal, configuration less install is possible by:<br />
# cp /usr/share/refind/refind_x64.efi /esp/EFI/Boot/bootx64.efi<br />
# cp -r /usr/share/refind/drivers_x64/ /esp/EFI/Boot/<br />
# echo 'extra_kernel_version_strings linux,linux-hardened,linux-lts,linux-zen,linux-git;' > /esp/EFI/Boot/refind.conf<br />
# echo 'fold_linux_kernels false' >> /esp/EFI/Boot/refind.conf<br />
can we add this? the upgrade works the same way. the refind-install script is more complex as it tries to change additional things which make it fail sometimes. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 06:52, 19 March 2018 (UTC)<br />
<br />
:: So you just add a few lines to {{ic|refind.conf}}? It would be better to use this style in the wiki and say something like "[[Append]] the following lines to the refind configuration file":<br />
<br />
::{{hc|''esp''/EFI/Boot/refind.conf|<br />
extra_kernel_version_strings linux<br />
fold_linux_kernels false}}<br />
<br />
::Also, is it really recommended to copy {{ic|refind_x64.efi}} to {{ic|bootx64.efi}}. Isn't that used as a last resort if the other methods of adding an EFI entry don't work? -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:30, 31 March 2018 (UTC)<br />
<br />
your first question [[User:Rdeckard|Rdeckard]]: if you add a few lines? no, the refind.conf is [[Append|created from scratch or overwritten]] if there, contains only these 2 lines. your second question, use the default location is the simple way, for refind, as well for [[systemd-boot]] mentioned in the documentation there. the main difference between systemd-boot and refind is that refind can auto-create the boot-loader menu, while one has to create a file containing the boot loaders for systemd-boot. the exception cases that there exists a more complex approach for refind having multiple boot managers in the efi partition should still be mentioned though. this then needs configuration. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:::The {{ic|extra_kernel_version_strings}} option is mentioned in [[rEFInd#For kernels automatically detected by rEFInd]], if needed, the {{ic|fold_linux_kernels}} could also be added somewhere under [[rEFInd#Configuration]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
<br />
:::As previously discussed in [[User talk:nl6720#rEFInd]], I am against mixing installation with configuration, they should remain separate. I also added the [[rEFInd#Without configuration]] section for the configuration without specifying kernel options.-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
a section "without configuration" within the section "configuration" *rotfl* --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:I admit that the "Without configuration" section could use a better title. Any suggestions? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:50, 30 April 2018 (UTC)<br />
<br />
let me make a proposal, which fixes the main problem: arch linux names the kernel and its fallback image different than most other linux distributions. refind-install ignores this fact. also refinds sample-conf file. we currently do not mention that copying the refind image and adding the 2 lines into refind.conf is the only thing needed. we do not mention that after running refind-install if would be good to add the 2 lines. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 14:07, 29 December 2018 (UTC)<br />
<br />
== template:move at refind#tools: to uefi ==<br />
<br />
There is a [[template:move]] [[refind#tools]] to [[uefi]]. I think the refind specific details should be left here, while everything else should be move to uefi. Aren't most, if not all, of these tools are not refind specific? Isn't this list of tools the most extensive list, if not the only list, in the wiki for such tools? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 15:05, 22 May 2019 (UTC)<br />
<br />
== Btrfs: Add same warning to Btrfs section as in the general configuration section ==<br />
<br />
This warning is shown in the general configuration section (under [[refind#refind_linux.conf]] and [[refind#Manual_boot_stanzas]]). <br />
<br />
{{Warning|<br />
* {{ic|loader}} and {{ic|initrd}} paths are relative to the root of {{ic|volume}}. If {{ic|/boot}} is a separate partition (e.g. the ESP), the loader and initrd paths would be {{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}, respectively.<br />
* Use backslashes ({{ic|\}}) as path separators in all quoted {{ic|initrd}} parameters, otherwise the kernel may fail to find the initramfs image(s): {{ic|EFI stub: ERROR: Failed to open file: /boot/initramfs-linux.img}}.<br />
* If using [[Booster]] generated initramfs images, replace {{ic|initramfs}} with {{ic|booster}} in the initramfs files name. E.g. {{ic|initrd /boot/booster-linux.img}}.<br />
}}<br />
<br />
At least the first or first two points (can't confirm for the last one) are also relevant to the Btrfs section for both [[refind#Auto_detection]] as well as [[refind#Manual_boot_stanza]] but they're currently missing there. <br />
<br />
''Can I suggest adding it there as well?'' <br />
<br />
I recently tried to install Arch with Btrfs, refind, and dual boot with Windows by reusing Windows' boot partition. This means the first point applied to me but it was missing in the Btrfs section. Since I thought what's shown in the Btrfs section is basically a special case of what's shown in the general configuration section, I did exactly as the Btrfs section says which didn't work for me.<br />
<br />
The warning explains that, in my case, the initrd paths should be just <br>{{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}<br>and '''not'''<br>{{ic|/ROOT/boot/vmlinuz-linux}} and {{ic|/ROOT/boot/initramfs-linux.img}} or {{ic|''subvolume''\boot\initramfs-%v.img}}<br>as is currently shown in the Btrfs section.<br />
<br />
It seems other people have stumbled over this step before as well, such as [https://www.reddit.com/r/archlinux/comments/fov9mv/cant_get_refind_to_boot_arch_failed_to_open_file/ this reddit post].<br />
<br />
I think adding this warning to the Btrfs section would make it more foolproof against people like me and more in line with the rest of the article.<br />
<br />
Apologies for any formal mistakes, this is my first edit to the wiki. <br />
<br />
[[User:Munzu|Munzu]] ([[User talk:Munzu|talk]]) 15:16, 28 November 2021 (UTC)<br />
<br />
:If you mount the ESP to {{ic|/boot}}, then almost nothing from [[rEFInd#Btrfs subvolume support]] is relevant to you since you're not using the {{ic|btrfs_x64.efi}} driver. You'd only need to set the {{ic|1=rootflags=subvol=}} kernel parameter (if required). [[rEFInd#Btrfs subvolume support]] should be clarified to explain this. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:23, 28 November 2021 (UTC)<br />
<br />
== Minor Corrections/Additions ==<br />
<br />
In [[REFInd#refind_linux.conf|refind_linux.conf]] section add a warning or note to '''not include both''' amd-ucode and intel-ucode. Like either ''initrd=boot\intel-ucode.img'' or ''initrd=boot\amd-ucode.img'' -- [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 19:14, 8 January 2022 (UTC)<br />
<br />
:Why? It may not be common, but it's perfectly valid to include both for e.g. [[Install Arch Linux on a removable medium]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:16, 9 January 2022 (UTC)<br />
<br />
::The one given in [[REFInd#refind_linux.conf|refind_linux.conf]] will give error and won't boot if either one of amd and intel microde is not found. It only makes sense to give them both as seperate boot entries, and not in the same line. Please provide it as a note or warning as it is definetly important. Why would one system have to load both microcodes? --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 13:51, 9 January 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:REFInd&diff=709203Talk:REFInd2022-01-09T13:51:20Z<p>RaZorr: refind_linux.conf edit</p>
<hr />
<div>== add a paragraph with simple installation ==<br />
rEFInd changed in 2017 which allows to run with a minimal configuration as it now auto-detects the img file fitting the kernel. with it a minimal, configuration less install is possible by:<br />
# cp /usr/share/refind/refind_x64.efi /esp/EFI/Boot/bootx64.efi<br />
# cp -r /usr/share/refind/drivers_x64/ /esp/EFI/Boot/<br />
# echo 'extra_kernel_version_strings linux,linux-hardened,linux-lts,linux-zen,linux-git;' > /esp/EFI/Boot/refind.conf<br />
# echo 'fold_linux_kernels false' >> /esp/EFI/Boot/refind.conf<br />
can we add this? the upgrade works the same way. the refind-install script is more complex as it tries to change additional things which make it fail sometimes. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 06:52, 19 March 2018 (UTC)<br />
<br />
:: So you just add a few lines to {{ic|refind.conf}}? It would be better to use this style in the wiki and say something like "[[Append]] the following lines to the refind configuration file":<br />
<br />
::{{hc|''esp''/EFI/Boot/refind.conf|<br />
extra_kernel_version_strings linux<br />
fold_linux_kernels false}}<br />
<br />
::Also, is it really recommended to copy {{ic|refind_x64.efi}} to {{ic|bootx64.efi}}. Isn't that used as a last resort if the other methods of adding an EFI entry don't work? -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:30, 31 March 2018 (UTC)<br />
<br />
your first question [[User:Rdeckard|Rdeckard]]: if you add a few lines? no, the refind.conf is [[Append|created from scratch or overwritten]] if there, contains only these 2 lines. your second question, use the default location is the simple way, for refind, as well for [[systemd-boot]] mentioned in the documentation there. the main difference between systemd-boot and refind is that refind can auto-create the boot-loader menu, while one has to create a file containing the boot loaders for systemd-boot. the exception cases that there exists a more complex approach for refind having multiple boot managers in the efi partition should still be mentioned though. this then needs configuration. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:::The {{ic|extra_kernel_version_strings}} option is mentioned in [[rEFInd#For kernels automatically detected by rEFInd]], if needed, the {{ic|fold_linux_kernels}} could also be added somewhere under [[rEFInd#Configuration]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
<br />
:::As previously discussed in [[User talk:nl6720#rEFInd]], I am against mixing installation with configuration, they should remain separate. I also added the [[rEFInd#Without configuration]] section for the configuration without specifying kernel options.-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
a section "without configuration" within the section "configuration" *rotfl* --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:I admit that the "Without configuration" section could use a better title. Any suggestions? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:50, 30 April 2018 (UTC)<br />
<br />
let me make a proposal, which fixes the main problem: arch linux names the kernel and its fallback image different than most other linux distributions. refind-install ignores this fact. also refinds sample-conf file. we currently do not mention that copying the refind image and adding the 2 lines into refind.conf is the only thing needed. we do not mention that after running refind-install if would be good to add the 2 lines. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 14:07, 29 December 2018 (UTC)<br />
<br />
== template:move at refind#tools: to uefi ==<br />
<br />
There is a [[template:move]] [[refind#tools]] to [[uefi]]. I think the refind specific details should be left here, while everything else should be move to uefi. Aren't most, if not all, of these tools are not refind specific? Isn't this list of tools the most extensive list, if not the only list, in the wiki for such tools? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 15:05, 22 May 2019 (UTC)<br />
<br />
== Btrfs: Add same warning to Btrfs section as in the general configuration section ==<br />
<br />
This warning is shown in the general configuration section (under [[refind#refind_linux.conf]] and [[refind#Manual_boot_stanzas]]). <br />
<br />
{{Warning|<br />
* {{ic|loader}} and {{ic|initrd}} paths are relative to the root of {{ic|volume}}. If {{ic|/boot}} is a separate partition (e.g. the ESP), the loader and initrd paths would be {{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}, respectively.<br />
* Use backslashes ({{ic|\}}) as path separators in all quoted {{ic|initrd}} parameters, otherwise the kernel may fail to find the initramfs image(s): {{ic|EFI stub: ERROR: Failed to open file: /boot/initramfs-linux.img}}.<br />
* If using [[Booster]] generated initramfs images, replace {{ic|initramfs}} with {{ic|booster}} in the initramfs files name. E.g. {{ic|initrd /boot/booster-linux.img}}.<br />
}}<br />
<br />
At least the first or first two points (can't confirm for the last one) are also relevant to the Btrfs section for both [[refind#Auto_detection]] as well as [[refind#Manual_boot_stanza]] but they're currently missing there. <br />
<br />
''Can I suggest adding it there as well?'' <br />
<br />
I recently tried to install Arch with Btrfs, refind, and dual boot with Windows by reusing Windows' boot partition. This means the first point applied to me but it was missing in the Btrfs section. Since I thought what's shown in the Btrfs section is basically a special case of what's shown in the general configuration section, I did exactly as the Btrfs section says which didn't work for me.<br />
<br />
The warning explains that, in my case, the initrd paths should be just <br>{{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}<br>and '''not'''<br>{{ic|/ROOT/boot/vmlinuz-linux}} and {{ic|/ROOT/boot/initramfs-linux.img}} or {{ic|''subvolume''\boot\initramfs-%v.img}}<br>as is currently shown in the Btrfs section.<br />
<br />
It seems other people have stumbled over this step before as well, such as [https://www.reddit.com/r/archlinux/comments/fov9mv/cant_get_refind_to_boot_arch_failed_to_open_file/ this reddit post].<br />
<br />
I think adding this warning to the Btrfs section would make it more foolproof against people like me and more in line with the rest of the article.<br />
<br />
Apologies for any formal mistakes, this is my first edit to the wiki. <br />
<br />
[[User:Munzu|Munzu]] ([[User talk:Munzu|talk]]) 15:16, 28 November 2021 (UTC)<br />
<br />
:If you mount the ESP to {{ic|/boot}}, then almost nothing from [[rEFInd#Btrfs subvolume support]] is relevant to you since you're not using the {{ic|btrfs_x64.efi}} driver. You'd only need to set the {{ic|1=rootflags=subvol=}} kernel parameter (if required). [[rEFInd#Btrfs subvolume support]] should be clarified to explain this. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:23, 28 November 2021 (UTC)<br />
<br />
== Minor Corrections/Additions ==<br />
<br />
In [[REFInd#refind_linux.conf|refind_linux.conf]] section add a warning or note to '''not include both''' amd-ucode and intel-ucode. Like either ''initrd=boot\intel-ucode.img'' or ''initrd=boot\amd-ucode.img'' -- [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 19:14, 8 January 2022 (UTC)<br />
<br />
:Why? It may not be common, but it's perfectly valid to include both for e.g. [[Install Arch Linux on a removable medium]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:16, 9 January 2022 (UTC)<br />
<br />
::The one given in [[REFInd#refind_linux.conf|refind_linux.conf]] will give error and won't boot if either one of amd and intel microde is not found. It only makes sense to give them both as seperate boot entries, and not in the same line. Please provide it as a note or warning as it is definetly important. Why would one system have to load both microcodes?</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:REFInd&diff=709048Talk:REFInd2022-01-08T19:14:59Z<p>RaZorr: /* Minor Corrections/Additions */ new section</p>
<hr />
<div>== add a paragraph with simple installation ==<br />
rEFInd changed in 2017 which allows to run with a minimal configuration as it now auto-detects the img file fitting the kernel. with it a minimal, configuration less install is possible by:<br />
# cp /usr/share/refind/refind_x64.efi /esp/EFI/Boot/bootx64.efi<br />
# cp -r /usr/share/refind/drivers_x64/ /esp/EFI/Boot/<br />
# echo 'extra_kernel_version_strings linux,linux-hardened,linux-lts,linux-zen,linux-git;' > /esp/EFI/Boot/refind.conf<br />
# echo 'fold_linux_kernels false' >> /esp/EFI/Boot/refind.conf<br />
can we add this? the upgrade works the same way. the refind-install script is more complex as it tries to change additional things which make it fail sometimes. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 06:52, 19 March 2018 (UTC)<br />
<br />
:: So you just add a few lines to {{ic|refind.conf}}? It would be better to use this style in the wiki and say something like "[[Append]] the following lines to the refind configuration file":<br />
<br />
::{{hc|''esp''/EFI/Boot/refind.conf|<br />
extra_kernel_version_strings linux<br />
fold_linux_kernels false}}<br />
<br />
::Also, is it really recommended to copy {{ic|refind_x64.efi}} to {{ic|bootx64.efi}}. Isn't that used as a last resort if the other methods of adding an EFI entry don't work? -- [[User:Rdeckard|Rdeckard]] ([[User_talk:Rdeckard|talk]]) 18:30, 31 March 2018 (UTC)<br />
<br />
your first question [[User:Rdeckard|Rdeckard]]: if you add a few lines? no, the refind.conf is [[Append|created from scratch or overwritten]] if there, contains only these 2 lines. your second question, use the default location is the simple way, for refind, as well for [[systemd-boot]] mentioned in the documentation there. the main difference between systemd-boot and refind is that refind can auto-create the boot-loader menu, while one has to create a file containing the boot loaders for systemd-boot. the exception cases that there exists a more complex approach for refind having multiple boot managers in the efi partition should still be mentioned though. this then needs configuration. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:::The {{ic|extra_kernel_version_strings}} option is mentioned in [[rEFInd#For kernels automatically detected by rEFInd]], if needed, the {{ic|fold_linux_kernels}} could also be added somewhere under [[rEFInd#Configuration]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
<br />
:::As previously discussed in [[User talk:nl6720#rEFInd]], I am against mixing installation with configuration, they should remain separate. I also added the [[rEFInd#Without configuration]] section for the configuration without specifying kernel options.-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 19:00, 31 March 2018 (UTC)<br />
a section "without configuration" within the section "configuration" *rotfl* --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 19:01, 28 April 2018 (UTC)<br />
<br />
:I admit that the "Without configuration" section could use a better title. Any suggestions? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:50, 30 April 2018 (UTC)<br />
<br />
let me make a proposal, which fixes the main problem: arch linux names the kernel and its fallback image different than most other linux distributions. refind-install ignores this fact. also refinds sample-conf file. we currently do not mention that copying the refind image and adding the 2 lines into refind.conf is the only thing needed. we do not mention that after running refind-install if would be good to add the 2 lines. --[[User:Soloturn|Soloturn]] ([[User talk:Soloturn|talk]]) 14:07, 29 December 2018 (UTC)<br />
<br />
== template:move at refind#tools: to uefi ==<br />
<br />
There is a [[template:move]] [[refind#tools]] to [[uefi]]. I think the refind specific details should be left here, while everything else should be move to uefi. Aren't most, if not all, of these tools are not refind specific? Isn't this list of tools the most extensive list, if not the only list, in the wiki for such tools? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 15:05, 22 May 2019 (UTC)<br />
<br />
== Btrfs: Add same warning to Btrfs section as in the general configuration section ==<br />
<br />
This warning is shown in the general configuration section (under [[refind#refind_linux.conf]] and [[refind#Manual_boot_stanzas]]). <br />
<br />
{{Warning|<br />
* {{ic|loader}} and {{ic|initrd}} paths are relative to the root of {{ic|volume}}. If {{ic|/boot}} is a separate partition (e.g. the ESP), the loader and initrd paths would be {{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}, respectively.<br />
* Use backslashes ({{ic|\}}) as path separators in all quoted {{ic|initrd}} parameters, otherwise the kernel may fail to find the initramfs image(s): {{ic|EFI stub: ERROR: Failed to open file: /boot/initramfs-linux.img}}.<br />
* If using [[Booster]] generated initramfs images, replace {{ic|initramfs}} with {{ic|booster}} in the initramfs files name. E.g. {{ic|initrd /boot/booster-linux.img}}.<br />
}}<br />
<br />
At least the first or first two points (can't confirm for the last one) are also relevant to the Btrfs section for both [[refind#Auto_detection]] as well as [[refind#Manual_boot_stanza]] but they're currently missing there. <br />
<br />
''Can I suggest adding it there as well?'' <br />
<br />
I recently tried to install Arch with Btrfs, refind, and dual boot with Windows by reusing Windows' boot partition. This means the first point applied to me but it was missing in the Btrfs section. Since I thought what's shown in the Btrfs section is basically a special case of what's shown in the general configuration section, I did exactly as the Btrfs section says which didn't work for me.<br />
<br />
The warning explains that, in my case, the initrd paths should be just <br>{{ic|/vmlinuz-linux}} and {{ic|/initramfs-linux.img}}<br>and '''not'''<br>{{ic|/ROOT/boot/vmlinuz-linux}} and {{ic|/ROOT/boot/initramfs-linux.img}} or {{ic|''subvolume''\boot\initramfs-%v.img}}<br>as is currently shown in the Btrfs section.<br />
<br />
It seems other people have stumbled over this step before as well, such as [https://www.reddit.com/r/archlinux/comments/fov9mv/cant_get_refind_to_boot_arch_failed_to_open_file/ this reddit post].<br />
<br />
I think adding this warning to the Btrfs section would make it more foolproof against people like me and more in line with the rest of the article.<br />
<br />
Apologies for any formal mistakes, this is my first edit to the wiki. <br />
<br />
[[User:Munzu|Munzu]] ([[User talk:Munzu|talk]]) 15:16, 28 November 2021 (UTC)<br />
<br />
:If you mount the ESP to {{ic|/boot}}, then almost nothing from [[rEFInd#Btrfs subvolume support]] is relevant to you since you're not using the {{ic|btrfs_x64.efi}} driver. You'd only need to set the {{ic|1=rootflags=subvol=}} kernel parameter (if required). [[rEFInd#Btrfs subvolume support]] should be clarified to explain this. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:23, 28 November 2021 (UTC)<br />
<br />
== Minor Corrections/Additions ==<br />
<br />
In [[REFInd#refind_linux.conf|refind_linux.conf]] section add a warning or note to '''not include both''' amd-ucode and intel-ucode. Like either ''initrd=boot\intel-ucode.img'' or ''initrd=boot\amd-ucode.img'' -- [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 19:14, 8 January 2022 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=User:RaZorr&diff=707396User:RaZorr2021-12-24T10:46:50Z<p>RaZorr: Created page with "{| style="text-align: left;" ! Name: | Razorr |- ! Role: | Arch fan |- ! Email: | rayz0rr@protonmail.com &nbsp; |- ! Languages: | English. |- ! Programming Languages: | Python, C++, Bash. |- ! style="padding: 0em 1em 0em 0em" | Other profiles: | [https://bbs.archlinux.org/profile.php?id=140316 BBS] :: [https://github.com/RaZ0rr-Two Github] |}"</p>
<hr />
<div>{| style="text-align: left;"<br />
! Name:<br />
| Razorr<br />
|-<br />
! Role:<br />
| Arch fan<br />
|-<br />
! Email:<br />
| rayz0rr@protonmail.com &nbsp;<br />
|-<br />
! Languages: <br />
| English.<br />
|-<br />
! Programming Languages: <br />
| Python, C++, Bash.<br />
|-<br />
! style="padding: 0em 1em 0em 0em" | Other profiles:<br />
| [https://bbs.archlinux.org/profile.php?id=140316 BBS] :: [https://github.com/RaZ0rr-Two Github]<br />
|}</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Users_and_groups&diff=707395Talk:Users and groups2021-12-24T10:34:03Z<p>RaZorr: </p>
<hr />
<div>== Group list ==<br />
It is a good idea to add a column with the default gid to every group in the wiki table ? e.g. what is group 102 ?<br />
# ls -la /usr/share/polkit-1<br />
# drwxr-x--- 1 root 102 44 Dec 22 02:14 rules.d<br />
Also I found in my cups directory files owned by 9xx. My first idea was to look in the wiki article...<br />
<br />
[[User:Ua4000|Ua4000]] ([[User talk:Ua4000|talk]]) 09:03, 24 December 2017 (UTC)<br />
<br />
:You can find those in [[DeveloperWiki:UID / GID Database]]. Also note that there were recently some changes towards dynamic allocation of the IDs [https://wiki.archlinux.org/index.php/Talk:DeveloperWiki:UID_/_GID_Database#GIDs_are_now_generated_dynamically_.2F_the_static_GIDs_here_are_not_valid_anymore], so the table may not be entirely correct. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:09, 24 December 2017 (UTC)<br />
<br />
== useradd primary / secondary group ==<br />
I am noticing that the group created (with gid=uid) is empty by default in /etc/groups, is that expected or is it safer to also add manually the user in the group?<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 07:20, 20 May 2018 (UTC)<br />
<br />
:The primary group is set in /etc/passwd, so it's fine that it appears empty in /etc/groups. Run {{ic|groups}} to see all current groups. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 20 May 2018 (UTC)<br />
<br />
== Utilities to handle the shadow file in acrh ==<br />
<br />
Referring the [[template:accuracy]] in the [[users and groups#Other tools related to these databases]] section: {{ic|chage}} is just an example how one can modify the shadow file in arch. There are other utilties to modify other aspects of the shadow file. The versions of {{ic|vipw}} and {{ic|vigr}} in arch has far less options compared to Debian, for example. On arch, {{ic|vipw -s}} exits with an error code of 1. Also compare {{man|8|vipw}} to [https://manpages.debian.org/unstable/passwd/vipw.8.en.html debian's man page]. At the bottom of the later there is a reference to shadow-utils, as well as a link to [http://snapshot.debian.org/package/shadow/1:4.5-1.1/ passwd 1:4.5-1.1]. shadow-utils is also mentioned for [https://pkgs.org/download/shadow-utils other distributions]. Which is confusing. Can it be that shadow-utils has cease to exist at the upstream level, but continues to exist at the distributions level? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 17:01, 28 January 2019 (UTC)<br />
<br />
:I'm not even sure how to parse any of this *or* the disputed section.<br />
:{{Pkg|shadow}} is the only thing there is to discuss at all -- the upstream "shadow" project is mildly schizophrenic in that it calls itself "shadow" everywhere *except* the manpages which mention "shadow-utils". Debian packages the source package "shadow" as the split binary packages "login", passwd", and "uidmap" and does not package a binary package for either "shadow" or "shadow-utils" or anything else of the sort, while Fedora packages it as "shadow-utils". Arch Linux, Void Linux, Gentoo, OpenSUSE, Slackware, Solus, all have the "shadow" package.<br />
:The bug report plainly states that vigr, vipw ''specifically'' from {{Pkg|util-linux}} are considered deprecated in favor acquiring those programs from the shadow project instead. (Then it was rejected in favor of un-deprecating the util-linux versions due to the shadow project not being responsible developers.) -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 21:25, 3 February 2019 (UTC)<br />
:: See [https://github.com/karelzak/util-linux/commit/2831866ed6e452a2255373a2499e3647f06bbfb5 this] link for detail. {{ic|chage}},{{ic|vigr}} and {{ic|vipw}} them self are not deprecated. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:26, 2 April 2020 (UTC)<br />
<br />
== systemd-homed ==<br />
<br />
Hi,<br />
<br />
The installation guide points to this page at the user creation step. Shouldn't this page talk about the possibility of using systemd-homed to manage users and a link to the appropriate article ?<br />
<br />
Have a good day<br />
<br />
{{unsigned|08:52, 4 September 2020|Cvlc}}<br />
<br />
:[[systemd-homed]] is completely optional and its page is already linked from the "Related articles" box at the top. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:07, 4 September 2020 (UTC)<br />
<br />
== Unclear note ==<br />
<br />
At the very bottom of [[Users_and_groups#Group_management]], there is a small note<br />
<br />
{{Note|If the user is currently logged in, they must log out and in again for the change to take effect.}}<br />
<br />
This seems to apply to the comment right above it. However, it actually applies to all of the group remove or add commands above. I suggest the wording is at least changed to "the'''se''' change'''s'''"; or the note is made into a normal paragraph, optionally at the very top of the section (my personally preferred solution, since this is important information and without this knowledge the user will unavoidably wonder why the commands appear to do nothing).<br />
<br />
[[User:PrinzVogelfrei|PrinzVogelfrei]] ([[User talk:PrinzVogelfrei|talk]]) 14:15, 8 April 2021 (UTC)<br />
<br />
== Clarification in shared data info ==<br />
<br />
In the second last paragraph in [[Users_and_groups#Example_adding_a_user|Example_adding_a_user]], the wording can be improved a little perhaps. I had to reread it many times in order to understand what it meant. I could also suggest edits if required. <br />
# May be an example group name like '''sdata''' can be used.<br />
# Also mention about [[Access_Control_Lists]] as it is also a neat little way to give shared access to folders among multiple users or creating shared partition across multiple distros.<br />
Let me know if I was being unclear with something due to my own bad english :p -- [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 10:33, 24 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Users_and_groups&diff=707394Talk:Users and groups2021-12-24T10:33:00Z<p>RaZorr: /* Clarification in shared data info */ new section</p>
<hr />
<div>== Group list ==<br />
It is a good idea to add a column with the default gid to every group in the wiki table ? e.g. what is group 102 ?<br />
# ls -la /usr/share/polkit-1<br />
# drwxr-x--- 1 root 102 44 Dec 22 02:14 rules.d<br />
Also I found in my cups directory files owned by 9xx. My first idea was to look in the wiki article...<br />
<br />
[[User:Ua4000|Ua4000]] ([[User talk:Ua4000|talk]]) 09:03, 24 December 2017 (UTC)<br />
<br />
:You can find those in [[DeveloperWiki:UID / GID Database]]. Also note that there were recently some changes towards dynamic allocation of the IDs [https://wiki.archlinux.org/index.php/Talk:DeveloperWiki:UID_/_GID_Database#GIDs_are_now_generated_dynamically_.2F_the_static_GIDs_here_are_not_valid_anymore], so the table may not be entirely correct. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:09, 24 December 2017 (UTC)<br />
<br />
== useradd primary / secondary group ==<br />
I am noticing that the group created (with gid=uid) is empty by default in /etc/groups, is that expected or is it safer to also add manually the user in the group?<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 07:20, 20 May 2018 (UTC)<br />
<br />
:The primary group is set in /etc/passwd, so it's fine that it appears empty in /etc/groups. Run {{ic|groups}} to see all current groups. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 20 May 2018 (UTC)<br />
<br />
== Utilities to handle the shadow file in acrh ==<br />
<br />
Referring the [[template:accuracy]] in the [[users and groups#Other tools related to these databases]] section: {{ic|chage}} is just an example how one can modify the shadow file in arch. There are other utilties to modify other aspects of the shadow file. The versions of {{ic|vipw}} and {{ic|vigr}} in arch has far less options compared to Debian, for example. On arch, {{ic|vipw -s}} exits with an error code of 1. Also compare {{man|8|vipw}} to [https://manpages.debian.org/unstable/passwd/vipw.8.en.html debian's man page]. At the bottom of the later there is a reference to shadow-utils, as well as a link to [http://snapshot.debian.org/package/shadow/1:4.5-1.1/ passwd 1:4.5-1.1]. shadow-utils is also mentioned for [https://pkgs.org/download/shadow-utils other distributions]. Which is confusing. Can it be that shadow-utils has cease to exist at the upstream level, but continues to exist at the distributions level? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 17:01, 28 January 2019 (UTC)<br />
<br />
:I'm not even sure how to parse any of this *or* the disputed section.<br />
:{{Pkg|shadow}} is the only thing there is to discuss at all -- the upstream "shadow" project is mildly schizophrenic in that it calls itself "shadow" everywhere *except* the manpages which mention "shadow-utils". Debian packages the source package "shadow" as the split binary packages "login", passwd", and "uidmap" and does not package a binary package for either "shadow" or "shadow-utils" or anything else of the sort, while Fedora packages it as "shadow-utils". Arch Linux, Void Linux, Gentoo, OpenSUSE, Slackware, Solus, all have the "shadow" package.<br />
:The bug report plainly states that vigr, vipw ''specifically'' from {{Pkg|util-linux}} are considered deprecated in favor acquiring those programs from the shadow project instead. (Then it was rejected in favor of un-deprecating the util-linux versions due to the shadow project not being responsible developers.) -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 21:25, 3 February 2019 (UTC)<br />
:: See [https://github.com/karelzak/util-linux/commit/2831866ed6e452a2255373a2499e3647f06bbfb5 this] link for detail. {{ic|chage}},{{ic|vigr}} and {{ic|vipw}} them self are not deprecated. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:26, 2 April 2020 (UTC)<br />
<br />
== systemd-homed ==<br />
<br />
Hi,<br />
<br />
The installation guide points to this page at the user creation step. Shouldn't this page talk about the possibility of using systemd-homed to manage users and a link to the appropriate article ?<br />
<br />
Have a good day<br />
<br />
{{unsigned|08:52, 4 September 2020|Cvlc}}<br />
<br />
:[[systemd-homed]] is completely optional and its page is already linked from the "Related articles" box at the top. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:07, 4 September 2020 (UTC)<br />
<br />
== Unclear note ==<br />
<br />
At the very bottom of [[Users_and_groups#Group_management]], there is a small note<br />
<br />
{{Note|If the user is currently logged in, they must log out and in again for the change to take effect.}}<br />
<br />
This seems to apply to the comment right above it. However, it actually applies to all of the group remove or add commands above. I suggest the wording is at least changed to "the'''se''' change'''s'''"; or the note is made into a normal paragraph, optionally at the very top of the section (my personally preferred solution, since this is important information and without this knowledge the user will unavoidably wonder why the commands appear to do nothing).<br />
<br />
[[User:PrinzVogelfrei|PrinzVogelfrei]] ([[User talk:PrinzVogelfrei|talk]]) 14:15, 8 April 2021 (UTC)<br />
<br />
== Clarification in shared data info ==<br />
<br />
In the second last paragraph in [[Example_adding_a_user]], the wording can be improved a little perhaps. I had to reread it many times in order to understand what it meant. I could also suggest edits if required. <br />
# May be an example group name like '''sdata''' can be used.<br />
# Also mention about [[Access_Control_Lists]] as it is also a neat little way to give shared access to folders among multiple users or creating shared partition across multiple distros.<br />
Let me know if I was being unclear with something due to my own bad english :p -- [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 10:33, 24 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:List_of_applications&diff=706952Talk:List of applications2021-12-21T14:19:41Z<p>RaZorr: /* New suggestions */ new section</p>
<hr />
<div>== Categorization ==<br />
=== Link subpages instead of transcluding them ===<br />
Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:<br />
<br />
{{META Box | | This page has various categories of programs and points to lists of programs in those categories. It is a useful starting point for finding a program for a specific application. [Introduce console versus graphical.]<br />
<br />
'''[[Common Applications/Internet | Internet]]''' including network configuration, and clients or browsers for web sites, FTP, file sharing, chat and email messaging, web feeds, and microblogging<br />
<br />
'''[[Common Applications/Multimedia | Multimedia]]''' including viewers, players and editors for raster, vector, 3D, CAD, audio and video, GUI capture, systems for accessing audio devices, audio CD rippers, and e-book programs.<br />
<br />
'''[[Common Applications/Utilities | Utilities]]''', which covers package management, file managers including space usage, compression and merge tools, optical disc burning, clipboards, GUI taskbars.<br />
<br />
'''[[Common Applications/Documents | Documents]]''': readers for printable files like PDFs, office suites, word processors, spreadsheets, text search, OCR<br />
<br />
'''[[Common Applications/Security | Security]]''': firewalls; file, network and log monitoring, scanning and analysis; backup<br />
<br />
'''[[Common Applications/Games | Games]]''': native and emulators<br />
<br />
'''[[Common Applications/Science | Science]]''': calculators, visualisation, design, programming environments and other tools for maths, chemistry, biology, astronomy, electronics and physics<br />
<br />
'''[[Common Applications/Other | Other]]''': note taking and scheduling; translation; desktop environments and window managers; terminals; OS monitors; text editors<br />
<br />
'''See also''' [other general lists of programs]}}<br />
<br />
Smaller individual pages would be nicer, because often I’m only interested in programs for a specific application, such as (in the past) [[Common Applications/Science#Electronics | Science#Electronics]], and [[Common Applications/Multimedia#GUI players | Multimedia#GUI players]] (audio). Even using the TOC, I think currently it’s too easy to get lost or overwhelmed. [[User:Vadmium|Vadmium]] 00:18, 26 January 2012 (EST).<br />
<br />
:I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 26 January 2012 (EST)<br />
<br />
: The page is gigantic and loads very slowly on my internet connection, so I think splitting into subpages is a good idea. Maybe the page length could also be reduced by only having the top 5 most used/useful apps for each category. I am hesitate about that suggestion as I have also found some more obscure but very useful things on this page, but it has gotten to be so unwieldy to navigate now. We could also have the "alternative to" website under a "see also" section as well as links to other external linux package lists.[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 20:34, 12 August 2018 (UTC)<br />
<br />
::155KB isn't that much on the modern web, every website containing a large image is larger. The page is already split in subpages, which you can access using the top navigation. Reducing the apps per category is not in question. Navigating the pages shouldn't be an issue if you use the ToC / Ctrl+F. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:39, 13 August 2018 (UTC)<br />
<br />
:::155KB may be the size of the wikicode, but the resulting HTML version of [[List of applications]] is about 1.1MB, which is a lot even for "modern web"... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]])<br />
<br />
::::Wrong, 155KB is the transferred size of the HTML if it's [[Wikipedia:Brotli|br]] compressed. For gzip it's 170KB. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 07:27, 13 August 2018 (UTC)<br />
<br />
== List dead projects or not? ==<br />
[https://wiki.archlinux.org/index.php?title=List_of_Applications/Multimedia&diff=next&oldid=296040 Kino is dead], it doesn't even have a maintainer in the AUR. Is it OK to remove dead-but-still-working applications from the list in the wiki? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 14:16, 3 February 2014 (UTC)<br />
<br />
:I wouldn't really know what's best to do, but if the application is confirmed to be still working, ''keep''ing it in the list should be the default action until somebody proves that listing it is counterproductive in some way. Of course a note about the EOL should be added if restored. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:50, 4 February 2014 (UTC)<br />
<br />
[http://www.afterstep.org/aterm.php The aterm project website] has been directing people to use urxvt instead since 2008. I've noticed quite a few projects in the maintainer-doesn't-even-advise-using-it category on this page and I don't see what purpose they serve. [[User:RyneEverett|Ryne Everett]] ([[User talk:RyneEverett|talk]]) 02:26, 13 December 2014 (UTC)<br />
<br />
:Well, the apps whose ''upstream'' maintainers explicitly discourage using them can indeed be removed, possibly making sure that any indicated alternative is already present in this list, adding it otherwise. Just note that, taking your post literally, "not advising to" is different from "discouraging to" (the aterm case falls indeed in the latter case) :) Please state the reason for removing applications from the list using the edit summary. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:32, 14 December 2014 (UTC)<br />
<br />
::I propose a deprecation warning, especially in the security subpage. there are numerous projects listed, that might still work, but are not developed anymore. this renders them insecure, as malware recognition needs to keep up with developement. This concerns rkhunter, chkrootkit and also the currently unlisted unhide. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 12:35, 2 September 2016 (UTC)<br />
<br />
:::I think it's too soon to talk on warnings like that when there's hundreds of dead AUR packages on the list... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:41, 2 September 2016 (UTC)<br />
<br />
::::Well, for packages meant to improve security concerning malware, frequent updates are no bonus, but crucial. a simple note would help users distinguish more and less active projects. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 17:17, 2 September 2016 (UTC)<br />
<br />
:::::At least rkhunter is still in the official repos, and John Horne, the [http://rkhunter.cvs.sourceforge.net/viewvc/rkhunter/rkhunter/files/ACKNOWLEDGMENTS current] main developer is still answering posts in the [https://sourceforge.net/p/rkhunter/mailman/rkhunter-users/ mailing list]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:12, 3 September 2016 (UTC)<br />
<br />
[https://github.com/muennich/sxiv sxiv] is not being maintained anymore. [https://github.com/nsxiv/nsxiv nsxiv] has been created as a drop-in replacement for it. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 14:16, 21 December 2021 (UTC)<br />
<br />
== Scope of the page ==<br />
<br />
It seems that this page is becoming a bloated index for all possible "lists" on the wiki, or maybe even the whole wiki itself. There are other pages to help users find what they are looking for, e.g. [[Table of contents]], [[General recommendations]] and of course the full-text search. Therefore I think that the [[List of applications]] should be a ''comprehensible'' list of the most common categories of application software and not a ''comprehensive'' list of everything. I believe that the index pages can have separate targets and cooperate with each other to provide a complete picture instead of overlapping and hindering readability by linking to each other.<br />
<br />
I propose the following:<br />
<br />
* remove [[List_of_applications/Workspace#Command_shells]] - one does not look for an alternative shell "just because", but to solve some specific problem or inconvenience, which is out of the reach of this page ([[General_recommendations#Console_improvements]] covers it quite nicely)<br />
* <s>I do not consider the things linked from [[List_of_applications/Workspace#Bootsplash]] to be "applications" and would like it removed. An explicit link to [[:Category:Bootsplash]] could be added to [[General_recommendations#Appearance]], although it already links to its parent category: [[:Category:Eye candy]].</s><br />
* remove [[List_of_applications/Workspace#Display_managers]], [[List_of_applications/Workspace#Desktop_environments]], [[List_of_applications/Workspace#Window_managers]] and [[List_of_applications/Workspace#Composite_managers]] - the topic is much better covered in [[General_recommendations#Graphical_user_interface]] (the two packages from [[List_of_applications/Workspace#Window_managers]] could be moved to [[General_recommendations#Console_improvements]])<br />
* <s>remove [[List_of_applications/Workspace#Accessibility]]</s> - it is a topic of its own, not just about selecting applications<br />
* <s>remove [[List_of_applications/Utilities#Databases]]</s> - they are certainly not utilities (so much less applications), but complex systems consisting of many deamons, utilities and interfaces designed to work together<br />
* <s>remove the [[List_of_applications/Internet#Web_Servers]] section:</s><br />
** <s>merge [[List_of_applications/Internet#LAMP_stack]] to [[Server#LAMP]]</s> - I doubt it is useful for an average user<br />
** <s>remove [[List_of_applications/Internet#Wiki_engines]]</s> - it is very incomplete and like above, not useful<br />
** <s>move [[List_of_applications/Internet#Content_management.2C_social_networks.2C_blog_publishers]] back to [[List_of_applications/Internet#Blog_engines]]</s><br />
** <s>move [[List_of_applications/Internet#Cloud_storage_servers]] under [[List_of_applications/Internet#File_sharing]]</s><br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:44, 2 March 2017 (UTC)<br />
<br />
:I've undone most of the structural changes to [[List of applications]] (starting with [https://wiki.archlinux.org/index.php?title=List_of_applications/Workspace&oldid=469393]) due to their one-sided nature. A radical restructure of one of the most popular wiki articles requires a consensus that isn't (yet) reached here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:38, 15 March 2017 (UTC)<br />
<br />
:About Display managers et al., perhaps we should just have a general header such as "Graphical user interface" and link to [[General recommendations#Graphical user interface]]. The idea is that the sections in question contain little more than single wiki links and as such add TOC entries to little benefit. As touched upon in [[#Merge sections to category pages]], a comprehensive TOC is already served by [[Table of Contents]] and there's no need for this page to compete. We could remind users of this by placing a link to [[Table of contents]] somewhere at the top.<br />
:Other sections such as [[List_of_applications/Other#Window_tilers]] could further be moved to their respective articles (here [[Window manager]]) to have all information in one place.<br />
:If this approach works out, we could use it to reduce [[List of applications/Other]] and [[List of applications/Utilities]] in size and merge the articles accordingly, as a compromise until a better approach is agreed upon in [[#Merge sections to category pages]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 15 March 2017 (UTC)<br />
<br />
::I think that "Graphical user interface" is too general, it might attract items or crosslinks to other sections for anything with a GUI. We might call it "Custom desktop environment" or something like that to group [[List_of_applications#Taskbars_.2F_panels_.2F_docks]], [[List_of_applications#Application_launchers]], [[List_of_applications#Wallpaper_setters]], [[List_of_applications#Virtual_desktop_pagers]], [[List_of_applications#Logout_dialogue]] and probably also [[List_of_applications#Screen_lockers]]. It could contain links to [[General recommendations]], [[Window manager]] etc. but I wouldn't merge them anywhere until the recategorization discussed in [[#Merge sections to category pages]] is finished. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 15 March 2017 (UTC)<br />
<br />
:::See [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470830&oldid=470804], [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470831&oldid=470830].<br />
:::I've kept [[List of applications/Other#Window managers]], [[List of applications/Other#Window tilers]] and [[List_of_applications/Other#Taskbars_.2F_panels_.2F_docks]] (latter could use a simpler name?) under the same [[List of applications#Desktop environments]] header because they're equally a part of a [[Desktop environment]] just like e.g. an application launcher is. We can always remove those items later on a restructure. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:10, 15 March 2017 (UTC)<br />
<br />
::::Some more candidates:<br />
::::*[[List of applications/Utilities#Files]]. Naming the header "files" is ambiguous at best; "File management" would be better but there's already [[List of applications/Utilities#File managers]]...<br />
::::*[[List_of_applications/Utilities#Disk_usage_display]] could fit under the more general [[List of applications/Utilities#System monitoring]], however [[List_of_applications/Utilities#Disk_usage_display]] is right next to it. However, [[List_of_applications/Utilities#Partitioning_tools]] is also a "disk" related topic.<br />
::::*[[List_of_applications/Utilities#Keyboard_layout_switchers]] may be better suited for [[List_of_applications/Other#Desktop_environments]]. Then again it's related to [[List_of_applications/Utilities#Input_methods]]<br />
::::So yes, I've also taken on the hard task of properly classifying entries in the "Other" categories. Though I would say completing this will make discussing proper alternatives easier. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:41, 15 March 2017 (UTC)<br />
<br />
=== Merge sections to category pages ===<br />
<br />
Warning: extreme brainstorming, join at your own risk.<br />
<br />
I agree with Lahwaacz about the fact that this page is becoming bloated and overlapping with the other index pages. However I also think that the very existence of this article (and its subsections) encourages Idomeneo1's approach, and honestly I don't think it's Simple anymore to understand what to keep here and what not, what to interlink where and what not etc., any solution still looks a bit arbitrary to me.<br />
<br />
I was thinking, perhaps we could kill this page completely and merge the various sections in the appropriate Category pages, taking the chance to improve the [[Table of contents|Category tree]], possibly also creating empty categories if needed, which would function as placeholders in that case, or each Category could still contain a main section and some subsections. I think that our current [[Table of contents]] already has some resemblance with the ToC of this article, so that scope overlapping/duplication may be the root cause of the parent discussion. Categories can also have multiple parents, which would address the current problem of having to interlink sections of this article with each other. Another advantage is that users would get more used to look into the Category page of an article, not only to find related articles, but now also to find related software that may not have wiki articles. Another advantage is that when creating an article about a piece of software it's already clear where to categorize it.<br />
<br />
Disadvantages: we lose the ability to see all the applications in the same page. (and...?)<br />
<br />
Last thing, I think that this idea would look the best if the app lists were changed to tables, as we discussed a long time ago in [[Talk:List of games]] and now I tried in [[User:Kynikos/App]]. [[Template:App]] can be changed to create a table row very easily, but I'd also like to discuss restructuring it as shown at the bottom of [[User:Kynikos/App#Terminal emulators]], which IMO gives info less redundantly.<br />
<br />
Enough :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:12, 5 March 2017 (UTC)<br />
<br />
:Currently we have a rule that if category A has a subcategory B, pages in B cannot be categorized also in A. I'd imagine that the application lists/tables would follow similar rule to avoid duplication, so we'd also lose the ability to see all applications in category A on the same page. Depending on how the actual categorization would look like, this might be important disadvantage - consider e.g. the subsections of [[List_of_applications#File_sharing]].<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)<br />
<br />
::Personally I don't think that viewing the whole [[List of applications#File sharing]] section in the same page is so useful; seeing its section structure in the ToC is useful, but that would be preserved in the automated category tree. As I wrote, we could allow subsections in Category pages, for example to keep non-specific distinctions like console/graphical or client/server. We could also instruct toc.py to read section headings in Category pages and show them in the generated ToC (perhaps only under [[:Category:Applications]]). Finally, it wouldn't be a violation of the DRY principle if we also generated pages that collate the contents of some Categories and their descendants, of course protecting them from manual editing. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:56, 6 March 2017 (UTC)<br />
<br />
:::On second thought, [[:Category:Applications]] currently has only 2 levels of subcategories so I think the problem mentioned above does not apply. If more levels appear in the future, I'd imagine it would be for a reason and even then it might not be so terrible. The parent tables or their captions might even contain a link to the subcategory tables to make them more visible instead of duplicating them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:25, 8 March 2017 (UTC)<br />
<br />
:::On third thought, we might even start with splitting up this very page, i.e. do [[#Link subpages instead of transcluding them]] + an autogenerated ToC list of sections on all subpages. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:33, 8 March 2017 (UTC)<br />
<br />
::::I'm still in favor of [[#Link subpages instead of transcluding them]], it works as an improvement and a compromise for me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:I was actually thinking that for applications which have a wiki page, browsing [[:Category:Applications]] instead of this page should give basically the same results (maybe some small subsections are squashed together, but that's not a problem). To make things simple(r), we might just say that topics which have most pages outside of [[:Category:Applications]] don't belong here and should be linked externally. Usually such topics have an introduction page, such as [[Server]], [[Xorg]] or [[Desktop environments]]. There would be a huge problem with "Utilities" and "Security" though. Also this approach would probably not cut the bloat enough.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)<br />
<br />
::As I said, I think that trying to find a clear rule to define what belongs in this page or not is too hard, there are too many blurred cases, as also seen in the parent discussion. IMHO the bloat problem of this article can't be reduced to only some sections in [[List of applications/Workspace]]: I like your "I think that the List of applications should be a comprehensible list of the most common categories of application software and not a comprehensive list of everything", but to me "List of applications" practically does sound like "List of everything", which is why I say that the problem is the whole article itself. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:19, 8 March 2017 (UTC)<br />
<br />
:::Well think that we can cut it in halves: I don't see many problems with [[List of applications/Internet]], [[List of applications/Multimedia]], [[List of applications/Documents]] and [[List of applications/Science]] - they are all with individual sections or even list entries, but the overall scope is clear. On the other hand, most of the "applications" listed on the remaining pages, [[List of applications/Workspace]], [[List of applications/Utilities]], [[List of applications/Security]] and [[List of applications/Other]], fall simply under "Utilities". From what the current page looks like, I think it's roughly like "Desktop utilities", "System administration utilities", "Security utilities" and (shrugs) "Other utilities", but there are many overlaps so it's probably not very useful to make this differentiation and it would be better to call them just "Utilities". Btw. I think that the category tree has generally the same problem with arbitrary decisions: somehow I don't see a common idea behind [[:Category:Command-line shells]] under [[:Category:Applications]] and [[:Category:Desktop environments]] under [[:Category:System administration]]. So that's the problem - do you see a way out? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:29, 8 March 2017 (UTC)<br />
<br />
::::Let's use the branch above about the destiny of this article.<br />
::::About the categories, as you say the problem is similar, I don't think there's much to do other than solve case by case: I'm in favor of moving [[:Category:Command-line shells]] and also [[:Category:Status monitoring and notification]] and [[:Category:Terminal emulators]] under [[:Category:System administration]]. Another thing that I'd do is rename [[:Category:Networking]] to [[:Category:Network administration]], and move only to [[:Category:Applications]] what doesn't fit there anymore, in particular [[:Category:Internet applications]], [[:Category:Telephony and voice]] and probably also [[:Category:Remote desktop]], plus possibly recategorize some articles which are currently directly under [[:Category:Networking]]. At that stage I would also consider renaming [[:Category:System administration]] to [[:Category:Host administration]] to remark the ''ideal'' complementarity of the two *_administration categories.<br />
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:The category tree / table of contents lists wiki pages, not apps - an app would have to have a special wiki page just to be mentioned, and even then, there is old cruft in the wiki pages as well. And that is ''much'' harder to clean up than a list.<br />
:I definitely agree the categories need improvement.<br />
:--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:09, 7 March 2017 (UTC)<br />
<br />
::Probably I didn't explain it very clearly, but my idea would be to merge the various lists here (turned into tables) in the editable part of Category pages, e.g. [[Getting and installing Arch]], so applications wouldn't need a wiki page to be mentioned there. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:49, 7 March 2017 (UTC)<br />
<br />
:::I like tables, especially sortable ones, though I'm not sure how they simplify things.<br />
:::An option could be to break the lists down into smaller sections, which could then be included in their respective wiki pages, as well as in a master list-of-apps page.<br />
:::An issue I see with the current [[Table of Contents]] is that it is entirely manually structured - no headings. How is a category tree "automated"? Does this automation preserve included lists/tables/cross-links?<br />
:::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:00, 8 March 2017 (UTC)<br />
<br />
::::Tables in this case more than simplifying would reduce bloat, since many entries would be reduced to one line (at least on wide screens), and the various fields (name, description, website, packages) would be neatly and rationally separated, making it much easier to scan for the needed info. Tables are also a more standard and often preferred way to list and compare applications e.g. on Wikipedia.<br />
::::About breaking the lists further and merging them into specific wiki pages, I'd be in favor if you want to discuss specific cases. However what is merged into other articles can't be duplicated in a "master list-of-apps page".<br />
::::[[Table of contents]] is completely generated by a [https://github.com/lahwaacz/wiki-scripts/blob/master/toc.py bot], there's no manual structuring. I'm not sure what you mean with your question about preserving included lists etc.<br />
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 8 March 2017 (UTC)<br />
<br />
:::::Your [[User:Kynikos/App]] trial is a great approach, but I'm unconvinced tables being a good format for this information. If you look at the sections, each table has different column widths (for a reason, but not neat). There are too many other variances: the current template app allows for short or longer descriptions, a single bot comment may shift column width for a whole table, etc. Worst: Even on a wide screen (which can't be a precondition in my view) table data would always break URLs, which is neither readable nor a neat, positive presentation. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:07, 8 March 2017 (UTC)<br />
<br />
::::::Just clarifying that my plan was to eventually switch to the format at the bottom of [[User:Kynikos/App#Terminal_emulators]], which doesn't display urls explicitly. Other modifications in the 3-column table solution that I see as advantages would be to resolve the current [[Template:App]]'s redundancy of always requiring to show the app's packages even when there is a dedicated article which already lists them. However I acknowledge that the idea of using tables isn't attracting much positive feedback, so ok, I'll keep it for the future generations ^^ — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:12, 9 March 2017 (UTC)<br />
<br />
::::::: Ok, thanks. Not displaying URLs would help, yes. Still I don't believe we would be able to make column width look neat across sections. Nested tables (for neatness) are not an option re maintainability. I see your point about showing duplication with the packages, but particularly in this list it can also be quite helpful to click through to content of alternative packages directly. It's not that a dedicated article would have immediate info on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:23, 15 March 2017 (UTC)<br />
<br />
:::::What I was suggesting was to break these lists up further into smaller "include" pages, such as Browsers, Window managers, File managers, etc etc, on separate, single "include" pages that could be simply "included" on the respective wiki pages, as well as the category pages, as well as the list of apps. This would provide simplicity, visibility, and coherence, so a whole bunch of app lists don't need to be maintained separately.<br />
:::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 23:56, 8 March 2017 (UTC)<br />
<br />
::::::Hmmm every time that you added, split or removed an included page you'd have to remember to update all the articles that include it, and also you wouldn't be able to include section headings because their levels would have to adapt to the host articles, so it wouldn't be very easy to maintain. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:::::::That would be true of any new wiki pages. The idea is to break the lists up into logical units that could be included on multiple pages and categories. Then, when you update the actual lists, such as fixing/removing broken links, you would only need to do it once, instead of editing multiple pages for every list edit.<br />
:::::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 01:33, 10 March 2017 (UTC)<br />
<br />
:::::::: I think to a large extent the app list in this article is it's own meta information, and that diminishes the more we break it down into smaller (&detached) units. When I try to apply your idea to e.g. [[List of applications#Screen lockers]] (same goes for "file manager", "browsers" examples to me), it's hard to picture where we would want to include that list but easy to imagine it can be helpful to link to from, say, a window manager article. Even '''if''' that "screen locker" unit would list 100% applicable packages for window manager A and B, is it really that helpful to include the full list in A and B? Likewise I don't see how that section can be broken down into more units, such attempt is bound to be very arbitrary in every case. Not simple. What would be a practical example of an include unit with two targets? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:30, 15 March 2017 (UTC)<br />
<br />
:I have to disagree. Categories pose an important way to navigate wiki articles. Placing long lists of applications (that mostly don't have wiki articles) at the top of category pages would mean that you often have to scroll down category pages to reach their index and thus preventing you from quickly navigating the wiki by categories. –[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 09:19, 31 December 2017 (UTC)<br />
<br />
::I agree with [[User:Larivact|Larivact]] points. On main topic, I favour splitting existing list pages in separate articles like [[Web browser]], [[Screen locker]] etc. This would give us more space to have sufficiently detailed explanation what each type of software is and does and would make more sense in context of topic-based wiki. As for respective categories we can have {{ic|The main article for this category is [[Web browser]].}} disclaimer like on [[w:Category:Web_browsers|wikipedia]]. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:42, 26 February 2018 (UTC)<br />
<br />
:::I concur, I created [[#Merge sections to dedicated articles]] and [[Template:Cat main]]. On a side note I don't think we need to explain what each type of software is, linking the respective Wikipedia article should suffice.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:29, 11 May 2018 (UTC)<br />
<br />
:''[The following related post was copied here from [https://wiki.archlinux.org/index.php?title=Talk:Bottle&oldid=490503#Archive Talk:Bottle#Archive]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:45, 27 April 2018 (UTC)]''<br />
:In general I think it's a bit unfair and counterintuitive though that the better documentation a piece of software has (or the better it works in general), the lesser visibility (and search references) it gets in our wiki (the software runs fine out of the box (good!) => no need for installation/configuration/troubleshooting sections => no wiki article; the software needs distro-specific guidance to be set up (less good / bad) => need for installation/configuration/troubleshooting sections => wiki article allowed). This may also be related to [[Talk:List_of_applications#Merge sections to category pages]], i.e. our Categories could link all current/popular options and point to the upstream docs, and ''possibly'' also to our articles for Arch-specific adaptations.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:27, 17 September 2017 (UTC)<br />
<br />
::The purpose of the ArchWiki is to provide information, not SEO. If we list all current/popular options on category pages we obstruct the navigability of our information (see my point above).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:21, 10 May 2018 (UTC)<br />
<br />
=== Merge sections to dedicated articles ===<br />
<br />
[[User:Svito|Svito]] proposed to split up [[List of applications]] into separate articles like [[Web browser]], [[Screen locker]] etc.<br />
<br />
I think that's the best approach because of the following advantages:<br />
<br />
* no two co-existing categorization systems like we currently have ([[List of applications]] and MediaWiki categories), instead just MediaWiki categories<br />
* articles can easily be linked and found via search<br />
* it does not obstruct navigating the wiki by categories like [[#Merge sections to category pages]] does<br />
<br />
As this approach would make categories more important, I think we should firstly implement [[Mediawiki talk:Common.css#Move categories under h1]].<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:25, 11 May 2018 (UTC)<br />
<br />
:[[#Merge sections to category pages]] would have required to reproduce a tree of categories under [[:Category:Applications]] similar to the ToC of this article. I don't mind this solution, but would you still create the additional categories, which in several cases would of course only contain the respective List page, or would you for example put all the split list articles from [[List of applications#Multimedia]] under the same [[:Category:Multimedia]]? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:45, 20 May 2018 (UTC)<br />
<br />
::Latter would make sense as having category for just one article would be odd. I would still keep this page to have list of links to all lists of applications. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:18, 21 May 2018 (UTC)<br />
<br />
:::Opposite for me, I support the category-tree way, at the cost of having one- (this proposal) or zero-article ([[#Merge sections to category pages]]) categories.<br />
:::If this page ends up still being required to show the tree of application lists which reside under common categories, then splitting loses much of its point in my view.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:32, 22 May 2018 (UTC)<br />
<br />
::::We wouldn't need to keep a page linking all lists, the category tree suffices and we could also use [[:Category:Lists of software]]. Do you still oppose this, considering that your proposal goes against semantics and common practice? Categories are for categorization, pages for content. Furthermore categories would require redirects to be maintained to facilitate linking and discovering. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:07, 17 October 2018 (UTC)<br />
<br />
=== Replace with external interface ===<br />
<br />
On second thought I am not convinced of [[#Merge sections to dedicated articles]] either. MediaWiki is just unsuited for a well-categorized list of applications. Especially since applications can be in multiple categories. A real radical alternative would be to <ins>outsource &</ins> convert the List of applications to text files in a Git repository. A text file would have the name of the package and could look like this:<br />
{{bc|<nowiki>name=Thunderbird<br />
description=Feature-rich email client from Mozilla written in GTK+.<br />
url=http://www.mozilla.org/thunderbird/<br />
tags=email client,news aggregator,usenet client,irc client,xmpp client,twitter client</nowiki>}}<br />
These files could then be converted to a static HTML site or queried via a hypothetical command-line interface.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:46, 20 May 2018 (UTC)<br />
<br />
:I would not dismiss original subject of how and where we want to display application lists on the wiki. You touch on entirely different topic that is browsing application lists outside the wiki, for which existing web interfaces could be improved for. It is inevitable that we would want to use upstream metadata from packages themselves and periodically generate application lists without editor intervention. I strongly believe we can take baby steps and reuse existing standards as much as possible:<br />
:* Merge sections to dedicated articles, leave links to all of them here<br />
:* Transform all lists into tables, fill in all metadata<br />
:* Explore if we can use [https://www.freedesktop.org/wiki/Distributions/AppStream/ AppStream] for our metadata, if not - contribute to AppStream spec so we can<br />
:* Push our metadata to upstream projects using AppStream, so we don't have to maintain it<br />
:* <s>Write scripts to periodically generate specific application tables on pages</s><br />
:* Add AppStream support to existing web interfaces<br />
:* Have a root beer with [[User:City-busz|City-busz]]<br />
:<s>Before any of it let's agree to split this discussion first(again)</s><br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:41, 20 May 2018 (UTC)<br />
<br />
::I think you missed my point, I proposed to outsource the list of applications from MediaWiki. It's not an entirely different topic, it's an entirely different solution to our categorization problem.<br />
::The main feature and biggest problem of the [[List of applications]] is categorization, upstream metadata won't help us with this because <ins>advanced</ins> categorization needs to be done centrally.<br />
::I regard AppStream as irrelevant as it doesn't deal with advanced categorization like the [[List of applications]] does.<br />
::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:11, 21 May 2018 (UTC)<br />
<br />
:::Defining category structure is not AppStream job and neither of [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification]. It is completely up to the software if and how to display and organize those and there is no restrictions on number of categories software can belong to. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:04, 21 May 2018 (UTC)<br />
<br />
:::I did miss your point. Can you be more specific what that would mean for fate of this article, its content and existing category structure? -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:51, 21 May 2018 (UTC)<br />
<br />
::::The [[List of applications]] would no longer be on the ArchWiki but a different website, perhaps {{ic|archlinux.org/apps}}. It would still link to the ArchWiki. The metadata from which the website gets generated could be on GitHub <s>or, perhaps a better idea, in a single page on the ArchWiki</s>. The existing content & categorization would need to be converted by a script (with some human intervention required to map sections to tags and merge apps present in multiple categories).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 17:42, 21 May 2018 (UTC)<br />
<br />
:::::Then AppStream would be more than suitable for this. See [https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent GenericComponent] for example, relying on [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification] for valid Category definitions. Contributing missing category definitions should not be a problem provided we will have multiple examples in our wiki needing them, especially because we as [[Arch Linux]] community have always worked upstream rather than downstream. In the end this benefits not just Arch Linux, but everyone who already uses AppStream and upstream projects. Many applications already support the spec with existing categories, and ArchLinux already supports AppStream for official repositories with {{Pkg|archlinux-appstream-data}}. Finding a way to use AppStream with AUR would be a next step.<br />
:::::If we to terminate this article and to use GitHub or dedicated page to maintain our metadata, this would still require people to create pull requests or wiki accounts just to add their software to the list and we would still be manually adding and removing software when it goes in or out of repositories or AUR. If we to use AppStream for metadata and contribute it to upstream projects, projects using it would automatically appear in our generated lists as they enter the repo or AUR, but also software center applications across all distributions. Of course we would still need to contribute our metadata to new projects without it.<br />
:::::I understand your reluctance to not deal with any existing solution, I like your idea, <s>but I hate any prospect of downstream metadata, damned it be</s>.<br />
:::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:34, 21 May 2018 (UTC)<br />
<br />
::::::While the [[List of applications]] tries to meticulously categorize the whole software world, the Desktop Menu Specification strives get you a nice little GUI menu of your installed applications. These are two completely different motives. The Desktop Menu Specification lacks so many categories that it is utterly unsuitable for the [[List of applications]]. And they will not accept our categories as they do not make sense for a desktop menu. Like I said advanced categorization needs to be done centrally.<br />
::::::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 05:08, 22 May 2018 (UTC)<br />
<br />
:::::::You seem to be mistaken Main categories with [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Additional categories], which I link description of from previous page here just for convenience: {{ic|can be used to provide more fine grained information about the application}}. They are just "tags" in conventional sense, but better yet explicitly defined as a standard. We are exactly ones in position to add more Additional categories to the spec, as application developers can't really have a say in it individually, nor they have any real incentive (yet) to bother adding them. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:17, 22 May 2018 (UTC)<br />
<br />
::::::::Outsourcing the metadata to upstream would mean that we could no longer effectively maintain or control it. This would reduce its quality and objectiveness.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:26, 22 May 2018 (UTC)<br />
<br />
:::::::::I created [[User:Svito/List of applications|draft with tentative additional categories]] I will be working on, but I changed my mind on idea of using it to generate tables on the wiki, which you just proven to me is terrible idea. I completely agree we don't need this article if we to have better means of finding software and its alternatives. I will try to improve existing specs for metadata we would like exposed by applications, but in the meanwhile I'm not opposed to your solution as well. Sorry for my stormy language before. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:24, 22 May 2018 (UTC)<br />
<br />
::::::::::Usually console applications don't have AppStream metadata, nor desktop file. The categories of Desktop Menu Specification don't give us the details and flexibility what we need, and upstream give sometimes inaccurate details that we need to fix from an objective view.<br />
<br />
::::::::::Personally I like the simplicity what MediaWiki provides, and I don't see much benefit from using a custom metadata system. Of course if anyone create and setup a better interface for listing and comparing applications, we can consider to remove application lists from Arch Wiki.--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 14:03, 22 May 2018 (UTC)<br />
<br />
== Marking Wayland-native GUI applications? ==<br />
<br />
I'm using Sway with {{ic|xwayland disabled}} most of the time nowadays and a lot of GUI applications simply work out of the box - Evolution, FileZilla, Firefox, Termite etc. I had to find them by trial and error though (check which programs are using GTK3/QT5/wxWidgets/etc -> install -> try) which is time consuming. Maybe if we mark applications that can run under Wayland without XWayland it would help people who are considering Sway/etc. Some sort of style guideline for marking such applications perhaps? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 19:23, 17 April 2019 (UTC)<br />
: This sounds like a good idea, but something more thorough would be better: the App template should maybe support marking the app as having a graphical user interface implementation on X Windows, a Wayland compositor, or multiple of those.<br />
: Is the App template specific to the Archlinux wiki? Can we change it? Who writes it? [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 19:10, 13 February 2020 (UTC)<br />
<br />
::Everything on this wiki is specific to this wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:12, 13 February 2020 (UTC)<br />
<br />
== Network Services removal ==<br />
<br />
I don't understand why my last edit was undone, there are some sections linking to the dedicated articles (for example: [[List_of_applications#Mail_servers]], [[List_of_applications#Screenshot]], [[List_of_applications#CD_ripping]]). Furthermore, the [[Network_configuration]] article doesn't mention any DHCP servers, only clients.<br />
<br />
To me, one the main usage of this page is to just search it when I am searching for a particular kind of application (for example I searched for SIP client this week), instead of having to look in both the official repos and the AUR. I think it is misleading when a kind of application is missing, because it could mean that there is no such application in archlinux.<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 08:00, 4 July 2019 (UTC)<br />
<br />
:Sorry I did not notice that DHCP servers are not mentioned in [[Network configuration]], but I still think the list is better suited for that page. The argument that this page should contain everything is completely wrong, the only way to really check if something exists as a package for Arch is to search both the official repos and AUR. This page can get out of date very easily, so you never know if something does not exist or is just missing. Or if it is covered on another page if there is any for the topic, like [[Network configuration]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:30, 11 July 2019 (UTC)<br />
<br />
== New suggestions ==<br />
<br />
A suggestion to [[List_of_applications#Sticky_notes]]. [https://github.com/linuxmint/sticky sticky] is sticky note app in linux mint. But I think it is compatible with all linux systems. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 14:19, 21 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:List_of_applications&diff=706951Talk:List of applications2021-12-21T14:16:10Z<p>RaZorr: sxiv alternative suggestion</p>
<hr />
<div>== Categorization ==<br />
=== Link subpages instead of transcluding them ===<br />
Just wondering if it would be better to completely split the article up into separate articles, rather than transcluding everything back in as templates. Perhaps just include links and a brief summary of each category in the top-level page, maybe something along the lines of:<br />
<br />
{{META Box | | This page has various categories of programs and points to lists of programs in those categories. It is a useful starting point for finding a program for a specific application. [Introduce console versus graphical.]<br />
<br />
'''[[Common Applications/Internet | Internet]]''' including network configuration, and clients or browsers for web sites, FTP, file sharing, chat and email messaging, web feeds, and microblogging<br />
<br />
'''[[Common Applications/Multimedia | Multimedia]]''' including viewers, players and editors for raster, vector, 3D, CAD, audio and video, GUI capture, systems for accessing audio devices, audio CD rippers, and e-book programs.<br />
<br />
'''[[Common Applications/Utilities | Utilities]]''', which covers package management, file managers including space usage, compression and merge tools, optical disc burning, clipboards, GUI taskbars.<br />
<br />
'''[[Common Applications/Documents | Documents]]''': readers for printable files like PDFs, office suites, word processors, spreadsheets, text search, OCR<br />
<br />
'''[[Common Applications/Security | Security]]''': firewalls; file, network and log monitoring, scanning and analysis; backup<br />
<br />
'''[[Common Applications/Games | Games]]''': native and emulators<br />
<br />
'''[[Common Applications/Science | Science]]''': calculators, visualisation, design, programming environments and other tools for maths, chemistry, biology, astronomy, electronics and physics<br />
<br />
'''[[Common Applications/Other | Other]]''': note taking and scheduling; translation; desktop environments and window managers; terminals; OS monitors; text editors<br />
<br />
'''See also''' [other general lists of programs]}}<br />
<br />
Smaller individual pages would be nicer, because often I’m only interested in programs for a specific application, such as (in the past) [[Common Applications/Science#Electronics | Science#Electronics]], and [[Common Applications/Multimedia#GUI players | Multimedia#GUI players]] (audio). Even using the TOC, I think currently it’s too easy to get lost or overwhelmed. [[User:Vadmium|Vadmium]] 00:18, 26 January 2012 (EST).<br />
<br />
:I think the main problem here is that if I'm looking for a particular subcategory I have to guess under which main category it can be, while currently, with the comprehensive ToC, that task is easier. Possible compromise: maintain a "manual" Table of Contents in the top-level page, with links to the various subpages/subsections. Let's hear more opinions. -- [[User:Kynikos|Kynikos]] 07:53, 26 January 2012 (EST)<br />
<br />
: The page is gigantic and loads very slowly on my internet connection, so I think splitting into subpages is a good idea. Maybe the page length could also be reduced by only having the top 5 most used/useful apps for each category. I am hesitate about that suggestion as I have also found some more obscure but very useful things on this page, but it has gotten to be so unwieldy to navigate now. We could also have the "alternative to" website under a "see also" section as well as links to other external linux package lists.[[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 20:34, 12 August 2018 (UTC)<br />
<br />
::155KB isn't that much on the modern web, every website containing a large image is larger. The page is already split in subpages, which you can access using the top navigation. Reducing the apps per category is not in question. Navigating the pages shouldn't be an issue if you use the ToC / Ctrl+F. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 03:39, 13 August 2018 (UTC)<br />
<br />
:::155KB may be the size of the wikicode, but the resulting HTML version of [[List of applications]] is about 1.1MB, which is a lot even for "modern web"... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]])<br />
<br />
::::Wrong, 155KB is the transferred size of the HTML if it's [[Wikipedia:Brotli|br]] compressed. For gzip it's 170KB. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 07:27, 13 August 2018 (UTC)<br />
<br />
== List dead projects or not? ==<br />
[https://wiki.archlinux.org/index.php?title=List_of_Applications/Multimedia&diff=next&oldid=296040 Kino is dead], it doesn't even have a maintainer in the AUR. Is it OK to remove dead-but-still-working applications from the list in the wiki? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 14:16, 3 February 2014 (UTC)<br />
<br />
:I wouldn't really know what's best to do, but if the application is confirmed to be still working, ''keep''ing it in the list should be the default action until somebody proves that listing it is counterproductive in some way. Of course a note about the EOL should be added if restored. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:50, 4 February 2014 (UTC)<br />
<br />
[http://www.afterstep.org/aterm.php The aterm project website] has been directing people to use urxvt instead since 2008. I've noticed quite a few projects in the maintainer-doesn't-even-advise-using-it category on this page and I don't see what purpose they serve. [[User:RyneEverett|Ryne Everett]] ([[User talk:RyneEverett|talk]]) 02:26, 13 December 2014 (UTC)<br />
<br />
:Well, the apps whose ''upstream'' maintainers explicitly discourage using them can indeed be removed, possibly making sure that any indicated alternative is already present in this list, adding it otherwise. Just note that, taking your post literally, "not advising to" is different from "discouraging to" (the aterm case falls indeed in the latter case) :) Please state the reason for removing applications from the list using the edit summary. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:32, 14 December 2014 (UTC)<br />
<br />
::I propose a deprecation warning, especially in the security subpage. there are numerous projects listed, that might still work, but are not developed anymore. this renders them insecure, as malware recognition needs to keep up with developement. This concerns rkhunter, chkrootkit and also the currently unlisted unhide. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 12:35, 2 September 2016 (UTC)<br />
<br />
:::I think it's too soon to talk on warnings like that when there's hundreds of dead AUR packages on the list... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:41, 2 September 2016 (UTC)<br />
<br />
::::Well, for packages meant to improve security concerning malware, frequent updates are no bonus, but crucial. a simple note would help users distinguish more and less active projects. [[User:Fordprefect|Fordprefect]] ([[User talk:Fordprefect|talk]]) 17:17, 2 September 2016 (UTC)<br />
<br />
:::::At least rkhunter is still in the official repos, and John Horne, the [http://rkhunter.cvs.sourceforge.net/viewvc/rkhunter/rkhunter/files/ACKNOWLEDGMENTS current] main developer is still answering posts in the [https://sourceforge.net/p/rkhunter/mailman/rkhunter-users/ mailing list]. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:12, 3 September 2016 (UTC)<br />
<br />
[https://github.com/muennich/sxiv sxiv] is not being maintained anymore. [https://github.com/nsxiv/nsxiv nsxiv] has been created as a drop-in replacement for it. --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 14:16, 21 December 2021 (UTC)<br />
<br />
== Scope of the page ==<br />
<br />
It seems that this page is becoming a bloated index for all possible "lists" on the wiki, or maybe even the whole wiki itself. There are other pages to help users find what they are looking for, e.g. [[Table of contents]], [[General recommendations]] and of course the full-text search. Therefore I think that the [[List of applications]] should be a ''comprehensible'' list of the most common categories of application software and not a ''comprehensive'' list of everything. I believe that the index pages can have separate targets and cooperate with each other to provide a complete picture instead of overlapping and hindering readability by linking to each other.<br />
<br />
I propose the following:<br />
<br />
* remove [[List_of_applications/Workspace#Command_shells]] - one does not look for an alternative shell "just because", but to solve some specific problem or inconvenience, which is out of the reach of this page ([[General_recommendations#Console_improvements]] covers it quite nicely)<br />
* <s>I do not consider the things linked from [[List_of_applications/Workspace#Bootsplash]] to be "applications" and would like it removed. An explicit link to [[:Category:Bootsplash]] could be added to [[General_recommendations#Appearance]], although it already links to its parent category: [[:Category:Eye candy]].</s><br />
* remove [[List_of_applications/Workspace#Display_managers]], [[List_of_applications/Workspace#Desktop_environments]], [[List_of_applications/Workspace#Window_managers]] and [[List_of_applications/Workspace#Composite_managers]] - the topic is much better covered in [[General_recommendations#Graphical_user_interface]] (the two packages from [[List_of_applications/Workspace#Window_managers]] could be moved to [[General_recommendations#Console_improvements]])<br />
* <s>remove [[List_of_applications/Workspace#Accessibility]]</s> - it is a topic of its own, not just about selecting applications<br />
* <s>remove [[List_of_applications/Utilities#Databases]]</s> - they are certainly not utilities (so much less applications), but complex systems consisting of many deamons, utilities and interfaces designed to work together<br />
* <s>remove the [[List_of_applications/Internet#Web_Servers]] section:</s><br />
** <s>merge [[List_of_applications/Internet#LAMP_stack]] to [[Server#LAMP]]</s> - I doubt it is useful for an average user<br />
** <s>remove [[List_of_applications/Internet#Wiki_engines]]</s> - it is very incomplete and like above, not useful<br />
** <s>move [[List_of_applications/Internet#Content_management.2C_social_networks.2C_blog_publishers]] back to [[List_of_applications/Internet#Blog_engines]]</s><br />
** <s>move [[List_of_applications/Internet#Cloud_storage_servers]] under [[List_of_applications/Internet#File_sharing]]</s><br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:44, 2 March 2017 (UTC)<br />
<br />
:I've undone most of the structural changes to [[List of applications]] (starting with [https://wiki.archlinux.org/index.php?title=List_of_applications/Workspace&oldid=469393]) due to their one-sided nature. A radical restructure of one of the most popular wiki articles requires a consensus that isn't (yet) reached here. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:38, 15 March 2017 (UTC)<br />
<br />
:About Display managers et al., perhaps we should just have a general header such as "Graphical user interface" and link to [[General recommendations#Graphical user interface]]. The idea is that the sections in question contain little more than single wiki links and as such add TOC entries to little benefit. As touched upon in [[#Merge sections to category pages]], a comprehensive TOC is already served by [[Table of Contents]] and there's no need for this page to compete. We could remind users of this by placing a link to [[Table of contents]] somewhere at the top.<br />
:Other sections such as [[List_of_applications/Other#Window_tilers]] could further be moved to their respective articles (here [[Window manager]]) to have all information in one place.<br />
:If this approach works out, we could use it to reduce [[List of applications/Other]] and [[List of applications/Utilities]] in size and merge the articles accordingly, as a compromise until a better approach is agreed upon in [[#Merge sections to category pages]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:48, 15 March 2017 (UTC)<br />
<br />
::I think that "Graphical user interface" is too general, it might attract items or crosslinks to other sections for anything with a GUI. We might call it "Custom desktop environment" or something like that to group [[List_of_applications#Taskbars_.2F_panels_.2F_docks]], [[List_of_applications#Application_launchers]], [[List_of_applications#Wallpaper_setters]], [[List_of_applications#Virtual_desktop_pagers]], [[List_of_applications#Logout_dialogue]] and probably also [[List_of_applications#Screen_lockers]]. It could contain links to [[General recommendations]], [[Window manager]] etc. but I wouldn't merge them anywhere until the recategorization discussed in [[#Merge sections to category pages]] is finished. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 15 March 2017 (UTC)<br />
<br />
:::See [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470830&oldid=470804], [https://wiki.archlinux.org/index.php?title=List_of_applications/Other&diff=470831&oldid=470830].<br />
:::I've kept [[List of applications/Other#Window managers]], [[List of applications/Other#Window tilers]] and [[List_of_applications/Other#Taskbars_.2F_panels_.2F_docks]] (latter could use a simpler name?) under the same [[List of applications#Desktop environments]] header because they're equally a part of a [[Desktop environment]] just like e.g. an application launcher is. We can always remove those items later on a restructure. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:10, 15 March 2017 (UTC)<br />
<br />
::::Some more candidates:<br />
::::*[[List of applications/Utilities#Files]]. Naming the header "files" is ambiguous at best; "File management" would be better but there's already [[List of applications/Utilities#File managers]]...<br />
::::*[[List_of_applications/Utilities#Disk_usage_display]] could fit under the more general [[List of applications/Utilities#System monitoring]], however [[List_of_applications/Utilities#Disk_usage_display]] is right next to it. However, [[List_of_applications/Utilities#Partitioning_tools]] is also a "disk" related topic.<br />
::::*[[List_of_applications/Utilities#Keyboard_layout_switchers]] may be better suited for [[List_of_applications/Other#Desktop_environments]]. Then again it's related to [[List_of_applications/Utilities#Input_methods]]<br />
::::So yes, I've also taken on the hard task of properly classifying entries in the "Other" categories. Though I would say completing this will make discussing proper alternatives easier. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:41, 15 March 2017 (UTC)<br />
<br />
=== Merge sections to category pages ===<br />
<br />
Warning: extreme brainstorming, join at your own risk.<br />
<br />
I agree with Lahwaacz about the fact that this page is becoming bloated and overlapping with the other index pages. However I also think that the very existence of this article (and its subsections) encourages Idomeneo1's approach, and honestly I don't think it's Simple anymore to understand what to keep here and what not, what to interlink where and what not etc., any solution still looks a bit arbitrary to me.<br />
<br />
I was thinking, perhaps we could kill this page completely and merge the various sections in the appropriate Category pages, taking the chance to improve the [[Table of contents|Category tree]], possibly also creating empty categories if needed, which would function as placeholders in that case, or each Category could still contain a main section and some subsections. I think that our current [[Table of contents]] already has some resemblance with the ToC of this article, so that scope overlapping/duplication may be the root cause of the parent discussion. Categories can also have multiple parents, which would address the current problem of having to interlink sections of this article with each other. Another advantage is that users would get more used to look into the Category page of an article, not only to find related articles, but now also to find related software that may not have wiki articles. Another advantage is that when creating an article about a piece of software it's already clear where to categorize it.<br />
<br />
Disadvantages: we lose the ability to see all the applications in the same page. (and...?)<br />
<br />
Last thing, I think that this idea would look the best if the app lists were changed to tables, as we discussed a long time ago in [[Talk:List of games]] and now I tried in [[User:Kynikos/App]]. [[Template:App]] can be changed to create a table row very easily, but I'd also like to discuss restructuring it as shown at the bottom of [[User:Kynikos/App#Terminal emulators]], which IMO gives info less redundantly.<br />
<br />
Enough :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:12, 5 March 2017 (UTC)<br />
<br />
:Currently we have a rule that if category A has a subcategory B, pages in B cannot be categorized also in A. I'd imagine that the application lists/tables would follow similar rule to avoid duplication, so we'd also lose the ability to see all applications in category A on the same page. Depending on how the actual categorization would look like, this might be important disadvantage - consider e.g. the subsections of [[List_of_applications#File_sharing]].<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)<br />
<br />
::Personally I don't think that viewing the whole [[List of applications#File sharing]] section in the same page is so useful; seeing its section structure in the ToC is useful, but that would be preserved in the automated category tree. As I wrote, we could allow subsections in Category pages, for example to keep non-specific distinctions like console/graphical or client/server. We could also instruct toc.py to read section headings in Category pages and show them in the generated ToC (perhaps only under [[:Category:Applications]]). Finally, it wouldn't be a violation of the DRY principle if we also generated pages that collate the contents of some Categories and their descendants, of course protecting them from manual editing. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:56, 6 March 2017 (UTC)<br />
<br />
:::On second thought, [[:Category:Applications]] currently has only 2 levels of subcategories so I think the problem mentioned above does not apply. If more levels appear in the future, I'd imagine it would be for a reason and even then it might not be so terrible. The parent tables or their captions might even contain a link to the subcategory tables to make them more visible instead of duplicating them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:25, 8 March 2017 (UTC)<br />
<br />
:::On third thought, we might even start with splitting up this very page, i.e. do [[#Link subpages instead of transcluding them]] + an autogenerated ToC list of sections on all subpages. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:33, 8 March 2017 (UTC)<br />
<br />
::::I'm still in favor of [[#Link subpages instead of transcluding them]], it works as an improvement and a compromise for me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:I was actually thinking that for applications which have a wiki page, browsing [[:Category:Applications]] instead of this page should give basically the same results (maybe some small subsections are squashed together, but that's not a problem). To make things simple(r), we might just say that topics which have most pages outside of [[:Category:Applications]] don't belong here and should be linked externally. Usually such topics have an introduction page, such as [[Server]], [[Xorg]] or [[Desktop environments]]. There would be a huge problem with "Utilities" and "Security" though. Also this approach would probably not cut the bloat enough.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:33, 5 March 2017 (UTC)<br />
<br />
::As I said, I think that trying to find a clear rule to define what belongs in this page or not is too hard, there are too many blurred cases, as also seen in the parent discussion. IMHO the bloat problem of this article can't be reduced to only some sections in [[List of applications/Workspace]]: I like your "I think that the List of applications should be a comprehensible list of the most common categories of application software and not a comprehensive list of everything", but to me "List of applications" practically does sound like "List of everything", which is why I say that the problem is the whole article itself. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:19, 8 March 2017 (UTC)<br />
<br />
:::Well think that we can cut it in halves: I don't see many problems with [[List of applications/Internet]], [[List of applications/Multimedia]], [[List of applications/Documents]] and [[List of applications/Science]] - they are all with individual sections or even list entries, but the overall scope is clear. On the other hand, most of the "applications" listed on the remaining pages, [[List of applications/Workspace]], [[List of applications/Utilities]], [[List of applications/Security]] and [[List of applications/Other]], fall simply under "Utilities". From what the current page looks like, I think it's roughly like "Desktop utilities", "System administration utilities", "Security utilities" and (shrugs) "Other utilities", but there are many overlaps so it's probably not very useful to make this differentiation and it would be better to call them just "Utilities". Btw. I think that the category tree has generally the same problem with arbitrary decisions: somehow I don't see a common idea behind [[:Category:Command-line shells]] under [[:Category:Applications]] and [[:Category:Desktop environments]] under [[:Category:System administration]]. So that's the problem - do you see a way out? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:29, 8 March 2017 (UTC)<br />
<br />
::::Let's use the branch above about the destiny of this article.<br />
::::About the categories, as you say the problem is similar, I don't think there's much to do other than solve case by case: I'm in favor of moving [[:Category:Command-line shells]] and also [[:Category:Status monitoring and notification]] and [[:Category:Terminal emulators]] under [[:Category:System administration]]. Another thing that I'd do is rename [[:Category:Networking]] to [[:Category:Network administration]], and move only to [[:Category:Applications]] what doesn't fit there anymore, in particular [[:Category:Internet applications]], [[:Category:Telephony and voice]] and probably also [[:Category:Remote desktop]], plus possibly recategorize some articles which are currently directly under [[:Category:Networking]]. At that stage I would also consider renaming [[:Category:System administration]] to [[:Category:Host administration]] to remark the ''ideal'' complementarity of the two *_administration categories.<br />
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:The category tree / table of contents lists wiki pages, not apps - an app would have to have a special wiki page just to be mentioned, and even then, there is old cruft in the wiki pages as well. And that is ''much'' harder to clean up than a list.<br />
:I definitely agree the categories need improvement.<br />
:--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:09, 7 March 2017 (UTC)<br />
<br />
::Probably I didn't explain it very clearly, but my idea would be to merge the various lists here (turned into tables) in the editable part of Category pages, e.g. [[Getting and installing Arch]], so applications wouldn't need a wiki page to be mentioned there. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:49, 7 March 2017 (UTC)<br />
<br />
:::I like tables, especially sortable ones, though I'm not sure how they simplify things.<br />
:::An option could be to break the lists down into smaller sections, which could then be included in their respective wiki pages, as well as in a master list-of-apps page.<br />
:::An issue I see with the current [[Table of Contents]] is that it is entirely manually structured - no headings. How is a category tree "automated"? Does this automation preserve included lists/tables/cross-links?<br />
:::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 00:00, 8 March 2017 (UTC)<br />
<br />
::::Tables in this case more than simplifying would reduce bloat, since many entries would be reduced to one line (at least on wide screens), and the various fields (name, description, website, packages) would be neatly and rationally separated, making it much easier to scan for the needed info. Tables are also a more standard and often preferred way to list and compare applications e.g. on Wikipedia.<br />
::::About breaking the lists further and merging them into specific wiki pages, I'd be in favor if you want to discuss specific cases. However what is merged into other articles can't be duplicated in a "master list-of-apps page".<br />
::::[[Table of contents]] is completely generated by a [https://github.com/lahwaacz/wiki-scripts/blob/master/toc.py bot], there's no manual structuring. I'm not sure what you mean with your question about preserving included lists etc.<br />
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 8 March 2017 (UTC)<br />
<br />
:::::Your [[User:Kynikos/App]] trial is a great approach, but I'm unconvinced tables being a good format for this information. If you look at the sections, each table has different column widths (for a reason, but not neat). There are too many other variances: the current template app allows for short or longer descriptions, a single bot comment may shift column width for a whole table, etc. Worst: Even on a wide screen (which can't be a precondition in my view) table data would always break URLs, which is neither readable nor a neat, positive presentation. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:07, 8 March 2017 (UTC)<br />
<br />
::::::Just clarifying that my plan was to eventually switch to the format at the bottom of [[User:Kynikos/App#Terminal_emulators]], which doesn't display urls explicitly. Other modifications in the 3-column table solution that I see as advantages would be to resolve the current [[Template:App]]'s redundancy of always requiring to show the app's packages even when there is a dedicated article which already lists them. However I acknowledge that the idea of using tables isn't attracting much positive feedback, so ok, I'll keep it for the future generations ^^ — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:12, 9 March 2017 (UTC)<br />
<br />
::::::: Ok, thanks. Not displaying URLs would help, yes. Still I don't believe we would be able to make column width look neat across sections. Nested tables (for neatness) are not an option re maintainability. I see your point about showing duplication with the packages, but particularly in this list it can also be quite helpful to click through to content of alternative packages directly. It's not that a dedicated article would have immediate info on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:23, 15 March 2017 (UTC)<br />
<br />
:::::What I was suggesting was to break these lists up further into smaller "include" pages, such as Browsers, Window managers, File managers, etc etc, on separate, single "include" pages that could be simply "included" on the respective wiki pages, as well as the category pages, as well as the list of apps. This would provide simplicity, visibility, and coherence, so a whole bunch of app lists don't need to be maintained separately.<br />
:::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 23:56, 8 March 2017 (UTC)<br />
<br />
::::::Hmmm every time that you added, split or removed an included page you'd have to remember to update all the articles that include it, and also you wouldn't be able to include section headings because their levels would have to adapt to the host articles, so it wouldn't be very easy to maintain. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:31, 9 March 2017 (UTC)<br />
<br />
:::::::That would be true of any new wiki pages. The idea is to break the lists up into logical units that could be included on multiple pages and categories. Then, when you update the actual lists, such as fixing/removing broken links, you would only need to do it once, instead of editing multiple pages for every list edit.<br />
:::::::--[[User:Idomeneo1|Idomeneo1]] ([[User talk:Idomeneo1|talk]]) 01:33, 10 March 2017 (UTC)<br />
<br />
:::::::: I think to a large extent the app list in this article is it's own meta information, and that diminishes the more we break it down into smaller (&detached) units. When I try to apply your idea to e.g. [[List of applications#Screen lockers]] (same goes for "file manager", "browsers" examples to me), it's hard to picture where we would want to include that list but easy to imagine it can be helpful to link to from, say, a window manager article. Even '''if''' that "screen locker" unit would list 100% applicable packages for window manager A and B, is it really that helpful to include the full list in A and B? Likewise I don't see how that section can be broken down into more units, such attempt is bound to be very arbitrary in every case. Not simple. What would be a practical example of an include unit with two targets? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:30, 15 March 2017 (UTC)<br />
<br />
:I have to disagree. Categories pose an important way to navigate wiki articles. Placing long lists of applications (that mostly don't have wiki articles) at the top of category pages would mean that you often have to scroll down category pages to reach their index and thus preventing you from quickly navigating the wiki by categories. –[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 09:19, 31 December 2017 (UTC)<br />
<br />
::I agree with [[User:Larivact|Larivact]] points. On main topic, I favour splitting existing list pages in separate articles like [[Web browser]], [[Screen locker]] etc. This would give us more space to have sufficiently detailed explanation what each type of software is and does and would make more sense in context of topic-based wiki. As for respective categories we can have {{ic|The main article for this category is [[Web browser]].}} disclaimer like on [[w:Category:Web_browsers|wikipedia]]. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:42, 26 February 2018 (UTC)<br />
<br />
:::I concur, I created [[#Merge sections to dedicated articles]] and [[Template:Cat main]]. On a side note I don't think we need to explain what each type of software is, linking the respective Wikipedia article should suffice.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:29, 11 May 2018 (UTC)<br />
<br />
:''[The following related post was copied here from [https://wiki.archlinux.org/index.php?title=Talk:Bottle&oldid=490503#Archive Talk:Bottle#Archive]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:45, 27 April 2018 (UTC)]''<br />
:In general I think it's a bit unfair and counterintuitive though that the better documentation a piece of software has (or the better it works in general), the lesser visibility (and search references) it gets in our wiki (the software runs fine out of the box (good!) => no need for installation/configuration/troubleshooting sections => no wiki article; the software needs distro-specific guidance to be set up (less good / bad) => need for installation/configuration/troubleshooting sections => wiki article allowed). This may also be related to [[Talk:List_of_applications#Merge sections to category pages]], i.e. our Categories could link all current/popular options and point to the upstream docs, and ''possibly'' also to our articles for Arch-specific adaptations.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:27, 17 September 2017 (UTC)<br />
<br />
::The purpose of the ArchWiki is to provide information, not SEO. If we list all current/popular options on category pages we obstruct the navigability of our information (see my point above).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:21, 10 May 2018 (UTC)<br />
<br />
=== Merge sections to dedicated articles ===<br />
<br />
[[User:Svito|Svito]] proposed to split up [[List of applications]] into separate articles like [[Web browser]], [[Screen locker]] etc.<br />
<br />
I think that's the best approach because of the following advantages:<br />
<br />
* no two co-existing categorization systems like we currently have ([[List of applications]] and MediaWiki categories), instead just MediaWiki categories<br />
* articles can easily be linked and found via search<br />
* it does not obstruct navigating the wiki by categories like [[#Merge sections to category pages]] does<br />
<br />
As this approach would make categories more important, I think we should firstly implement [[Mediawiki talk:Common.css#Move categories under h1]].<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:25, 11 May 2018 (UTC)<br />
<br />
:[[#Merge sections to category pages]] would have required to reproduce a tree of categories under [[:Category:Applications]] similar to the ToC of this article. I don't mind this solution, but would you still create the additional categories, which in several cases would of course only contain the respective List page, or would you for example put all the split list articles from [[List of applications#Multimedia]] under the same [[:Category:Multimedia]]? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:45, 20 May 2018 (UTC)<br />
<br />
::Latter would make sense as having category for just one article would be odd. I would still keep this page to have list of links to all lists of applications. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 17:18, 21 May 2018 (UTC)<br />
<br />
:::Opposite for me, I support the category-tree way, at the cost of having one- (this proposal) or zero-article ([[#Merge sections to category pages]]) categories.<br />
:::If this page ends up still being required to show the tree of application lists which reside under common categories, then splitting loses much of its point in my view.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:32, 22 May 2018 (UTC)<br />
<br />
::::We wouldn't need to keep a page linking all lists, the category tree suffices and we could also use [[:Category:Lists of software]]. Do you still oppose this, considering that your proposal goes against semantics and common practice? Categories are for categorization, pages for content. Furthermore categories would require redirects to be maintained to facilitate linking and discovering. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:07, 17 October 2018 (UTC)<br />
<br />
=== Replace with external interface ===<br />
<br />
On second thought I am not convinced of [[#Merge sections to dedicated articles]] either. MediaWiki is just unsuited for a well-categorized list of applications. Especially since applications can be in multiple categories. A real radical alternative would be to <ins>outsource &</ins> convert the List of applications to text files in a Git repository. A text file would have the name of the package and could look like this:<br />
{{bc|<nowiki>name=Thunderbird<br />
description=Feature-rich email client from Mozilla written in GTK+.<br />
url=http://www.mozilla.org/thunderbird/<br />
tags=email client,news aggregator,usenet client,irc client,xmpp client,twitter client</nowiki>}}<br />
These files could then be converted to a static HTML site or queried via a hypothetical command-line interface.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:46, 20 May 2018 (UTC)<br />
<br />
:I would not dismiss original subject of how and where we want to display application lists on the wiki. You touch on entirely different topic that is browsing application lists outside the wiki, for which existing web interfaces could be improved for. It is inevitable that we would want to use upstream metadata from packages themselves and periodically generate application lists without editor intervention. I strongly believe we can take baby steps and reuse existing standards as much as possible:<br />
:* Merge sections to dedicated articles, leave links to all of them here<br />
:* Transform all lists into tables, fill in all metadata<br />
:* Explore if we can use [https://www.freedesktop.org/wiki/Distributions/AppStream/ AppStream] for our metadata, if not - contribute to AppStream spec so we can<br />
:* Push our metadata to upstream projects using AppStream, so we don't have to maintain it<br />
:* <s>Write scripts to periodically generate specific application tables on pages</s><br />
:* Add AppStream support to existing web interfaces<br />
:* Have a root beer with [[User:City-busz|City-busz]]<br />
:<s>Before any of it let's agree to split this discussion first(again)</s><br />
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:41, 20 May 2018 (UTC)<br />
<br />
::I think you missed my point, I proposed to outsource the list of applications from MediaWiki. It's not an entirely different topic, it's an entirely different solution to our categorization problem.<br />
::The main feature and biggest problem of the [[List of applications]] is categorization, upstream metadata won't help us with this because <ins>advanced</ins> categorization needs to be done centrally.<br />
::I regard AppStream as irrelevant as it doesn't deal with advanced categorization like the [[List of applications]] does.<br />
::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 16:11, 21 May 2018 (UTC)<br />
<br />
:::Defining category structure is not AppStream job and neither of [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification]. It is completely up to the software if and how to display and organize those and there is no restrictions on number of categories software can belong to. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 20:04, 21 May 2018 (UTC)<br />
<br />
:::I did miss your point. Can you be more specific what that would mean for fate of this article, its content and existing category structure? -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:51, 21 May 2018 (UTC)<br />
<br />
::::The [[List of applications]] would no longer be on the ArchWiki but a different website, perhaps {{ic|archlinux.org/apps}}. It would still link to the ArchWiki. The metadata from which the website gets generated could be on GitHub <s>or, perhaps a better idea, in a single page on the ArchWiki</s>. The existing content & categorization would need to be converted by a script (with some human intervention required to map sections to tags and merge apps present in multiple categories).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 17:42, 21 May 2018 (UTC)<br />
<br />
:::::Then AppStream would be more than suitable for this. See [https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent GenericComponent] for example, relying on [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Desktop Menu Specification] for valid Category definitions. Contributing missing category definitions should not be a problem provided we will have multiple examples in our wiki needing them, especially because we as [[Arch Linux]] community have always worked upstream rather than downstream. In the end this benefits not just Arch Linux, but everyone who already uses AppStream and upstream projects. Many applications already support the spec with existing categories, and ArchLinux already supports AppStream for official repositories with {{Pkg|archlinux-appstream-data}}. Finding a way to use AppStream with AUR would be a next step.<br />
:::::If we to terminate this article and to use GitHub or dedicated page to maintain our metadata, this would still require people to create pull requests or wiki accounts just to add their software to the list and we would still be manually adding and removing software when it goes in or out of repositories or AUR. If we to use AppStream for metadata and contribute it to upstream projects, projects using it would automatically appear in our generated lists as they enter the repo or AUR, but also software center applications across all distributions. Of course we would still need to contribute our metadata to new projects without it.<br />
:::::I understand your reluctance to not deal with any existing solution, I like your idea, <s>but I hate any prospect of downstream metadata, damned it be</s>.<br />
:::::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:34, 21 May 2018 (UTC)<br />
<br />
::::::While the [[List of applications]] tries to meticulously categorize the whole software world, the Desktop Menu Specification strives get you a nice little GUI menu of your installed applications. These are two completely different motives. The Desktop Menu Specification lacks so many categories that it is utterly unsuitable for the [[List of applications]]. And they will not accept our categories as they do not make sense for a desktop menu. Like I said advanced categorization needs to be done centrally.<br />
::::::--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 05:08, 22 May 2018 (UTC)<br />
<br />
:::::::You seem to be mistaken Main categories with [https://standards.freedesktop.org/menu-spec/menu-spec-latest.html#additional-category-registry Additional categories], which I link description of from previous page here just for convenience: {{ic|can be used to provide more fine grained information about the application}}. They are just "tags" in conventional sense, but better yet explicitly defined as a standard. We are exactly ones in position to add more Additional categories to the spec, as application developers can't really have a say in it individually, nor they have any real incentive (yet) to bother adding them. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:17, 22 May 2018 (UTC)<br />
<br />
::::::::Outsourcing the metadata to upstream would mean that we could no longer effectively maintain or control it. This would reduce its quality and objectiveness.--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:26, 22 May 2018 (UTC)<br />
<br />
:::::::::I created [[User:Svito/List of applications|draft with tentative additional categories]] I will be working on, but I changed my mind on idea of using it to generate tables on the wiki, which you just proven to me is terrible idea. I completely agree we don't need this article if we to have better means of finding software and its alternatives. I will try to improve existing specs for metadata we would like exposed by applications, but in the meanwhile I'm not opposed to your solution as well. Sorry for my stormy language before. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:24, 22 May 2018 (UTC)<br />
<br />
::::::::::Usually console applications don't have AppStream metadata, nor desktop file. The categories of Desktop Menu Specification don't give us the details and flexibility what we need, and upstream give sometimes inaccurate details that we need to fix from an objective view.<br />
<br />
::::::::::Personally I like the simplicity what MediaWiki provides, and I don't see much benefit from using a custom metadata system. Of course if anyone create and setup a better interface for listing and comparing applications, we can consider to remove application lists from Arch Wiki.--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 14:03, 22 May 2018 (UTC)<br />
<br />
== Marking Wayland-native GUI applications? ==<br />
<br />
I'm using Sway with {{ic|xwayland disabled}} most of the time nowadays and a lot of GUI applications simply work out of the box - Evolution, FileZilla, Firefox, Termite etc. I had to find them by trial and error though (check which programs are using GTK3/QT5/wxWidgets/etc -> install -> try) which is time consuming. Maybe if we mark applications that can run under Wayland without XWayland it would help people who are considering Sway/etc. Some sort of style guideline for marking such applications perhaps? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 19:23, 17 April 2019 (UTC)<br />
: This sounds like a good idea, but something more thorough would be better: the App template should maybe support marking the app as having a graphical user interface implementation on X Windows, a Wayland compositor, or multiple of those.<br />
: Is the App template specific to the Archlinux wiki? Can we change it? Who writes it? [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 19:10, 13 February 2020 (UTC)<br />
<br />
::Everything on this wiki is specific to this wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:12, 13 February 2020 (UTC)<br />
<br />
== Network Services removal ==<br />
<br />
I don't understand why my last edit was undone, there are some sections linking to the dedicated articles (for example: [[List_of_applications#Mail_servers]], [[List_of_applications#Screenshot]], [[List_of_applications#CD_ripping]]). Furthermore, the [[Network_configuration]] article doesn't mention any DHCP servers, only clients.<br />
<br />
To me, one the main usage of this page is to just search it when I am searching for a particular kind of application (for example I searched for SIP client this week), instead of having to look in both the official repos and the AUR. I think it is misleading when a kind of application is missing, because it could mean that there is no such application in archlinux.<br />
<br />
-- [[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 08:00, 4 July 2019 (UTC)<br />
<br />
:Sorry I did not notice that DHCP servers are not mentioned in [[Network configuration]], but I still think the list is better suited for that page. The argument that this page should contain everything is completely wrong, the only way to really check if something exists as a package for Arch is to search both the official repos and AUR. This page can get out of date very easily, so you never know if something does not exist or is just missing. Or if it is covered on another page if there is any for the topic, like [[Network configuration]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:30, 11 July 2019 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Sxiv&diff=706950Talk:Sxiv2021-12-21T14:16:01Z<p>RaZorr: /* sxiv alternative */ new section</p>
<hr />
<div>== Broken image-info? ==<br />
<br />
The line {{ic|1=geometry=$(identify -format '%wx%h' "$1[0]")}} seems to be broken as of imagemagick 6.9.6.8-1 (or maybe before). Removing {{ic|[0]}} fixes it.<br />
<br />
So why was {{ic|[0]}} there in the first place?<br />
{{unsigned|14:51, 23 December 2016|Ambrevar}}<br />
<br />
:It was added with the rest of the section with [https://wiki.archlinux.org/index.php?title=Sxiv&diff=282622&oldid=277759]. I'm guessing the editor didn't understand how bash works? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:37, 23 December 2016 (UTC)<br />
<br />
::Got it: the [0] stands for the index of the frame, which is useful for multi-frame pictures (e.g. gif). The code was correct and it is still working now, so I suppose that it broke and imagemagick 6.9.6.8 and got fixed on 6.9.7.5. -- [[User:Ambrevar|Ambrevar]] ([[User talk:Ambrevar|talk]]) 08:48, 9 February 2017 (UTC)<br />
<br />
:::Actually, it wasn't a bug on imagemagick's side, it is simply that indexing will fail on some formats like PNG. Any clue on how to make this universal? -- [[User:Ambrevar|Ambrevar]] ([[User talk:Ambrevar|talk]]) 15:13, 18 February 2017 (UTC)<br />
<br />
== sxiv alternative ==<br />
<br />
[https://github.com/muennich/sxiv sxiv] is not being maintained anymore. [https://github.com/nsxiv/nsxiv nsxiv] has been created as a drop-in replacement for it. Maybe mention this somewhere in the wiki? --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 14:16, 21 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Synchronization_and_backup_programs&diff=706770Talk:Synchronization and backup programs2021-12-20T13:23:18Z<p>RaZorr: </p>
<hr />
<div>== should we mention par2cmdline? ==<br />
<br />
I had used parchive before and was looking for its packagename for it here. Maybe it should be mentioned. Feels backup-related enough to me.<br />
<br />
Thanks<br />
--[[User:Kristianlm|Kristianlm]] ([[User talk:Kristianlm|talk]]) 13:01, 15 October 2012 (UTC)<br />
<br />
== Guidelines for adding programs? ==<br />
Should a particular program (assuming it is open source) already have a package created for ArchLinux before adding it to this list? Also, what if it is relatively new, and doesn't have a lot of users yet, should it go through a minimum amount of other user testing before adding it? In the interest of full disclosure, I have recently contributed a backup system as open source (currently hosted on github), that I've personally used for a while -- it is similar in concept to the rsync-based backups, but it includes full file level deduplication (even across multiple clients), an SQLite-based catalog, and the client side uses standard GNU tar, find, and a wrapper shell script (no binaries to install on the client side). So you end up with the simplicity of rsync, with some of the features of the heavy-weight backup programs.<br />
<br />
Thought I would ask here first before posting a writeup on the main wiki page -- don't want to appear like I'm spamming links or anything. [[User:Derekp7|Derekp7]] ([[User talk:Derekp7|talk]]) 01:48, 17 February 2013 (UTC)<br />
: You are free to add your tool. But since this is an Arch Wiki, the tool should be easily accessed by Arch user. I think at least a [[AUR]] package is needed. Create a [[AUR]] package is very easy. See the [[AUR]] and [[PKGBUILD]] for how to. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:42, 17 February 2013 (UTC)<br />
<br />
== Cloud backups ==<br />
<br />
Can I add these tree other options or they are not suitable by any reason?<br />
<br />
- Drive[https://tools.google.com/dlpage/drive] - AUR[https://aur.archlinux.org/packages/grive/]<br />
- Copy[https://www1.copy.com/home/] - AUR[https://aur.archlinux.org/packages/copy/]<br />
- Bitcasa[http://www.bitcasa.com/] - AUR[https://aur.archlinux.org/packages/bitcasa/]<br />
<br />
--[[User:Gbc921|Gabriel B. Casella]] ([[User talk:Gbc921|talk]]) 21:37, 13 December 2013 (UTC)<br />
<br />
:Sure, considering that MEGA is listed in [[Backup_Programs#Cloud_backups]], these three would fit there much better ;) But please keep the structure the same as for other software. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:01, 13 December 2013 (UTC)<br />
<br />
=== Wuala is shutting down ===<br />
<br />
Wuala is shutting down, see notice[https://support.wuala.com/2015/08/wuala-shutdown-notice/]. Can I remove it? Also it's recommended alternative Tresorit[https://tresorit.com] is not exaclty the same, it's more of an encrypted Dropbox.<br />
<br />
-- [[User:Folti|Folti]] ([[User talk:Folti|talk]]) 14:08, 29 September 2015 (UTC)<br />
<br />
:Yes, please remove Wuala. I don't know Tresorit, you may add it if you want, or leave it to somebody else. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:38, 30 September 2015 (UTC)<br />
<br />
== Should a link to a performance comparison between Rsync, Rdiff-backup, Duplicity, Areca and Link-Backup be included? ==<br />
<br />
I am one of the authors of [http://www.si-journal.org/index.php/JSI/article/view/205 this paper] were we compare the performance and system resources usage of five backup tools. Should it be included in this wiki?<br />
<br />
Thanks {{Unsigned|Oct 2014|Aurhe}}<br />
<br />
:Yes, you can use the See also section at the bottom. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:35, 8 October 2014 (UTC)<br />
<br />
== The Console / Graphical categorization doesn't really make sense any more ==<br />
<br />
I just added '''Bacula''', which appears to be the most downloaded open source backup solution. Bacula can be used in console and graphical mode, and included a web interface as well. For the time being I just created a new category: Console & Graphical. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 13:23, 20 December 2014 (UTC)<br />
<br />
:Hi, I don't get it, are you just reporting the fact that you've added Bacula, or are you proposing something about the Console/Graphical categorization? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:22, 21 December 2014 (UTC)<br />
<br />
::Bacula is the example of why the categorization scheme doesn't make sense. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:41, 22 December 2014 (UTC)<br />
<br />
:::I'm not a big fan of that distinction either for the same reason, but it's derived from [[List of applications]], and I feel many users would object to its removal. Let's leave this open and see if there are more comments. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:25, 23 December 2014 (UTC)<br />
<br />
== Radical reorganization ==<br />
<br />
I'm working on a possible restructuring of the page, especially using a table to compare the numerous incremental backup applications, see the draft at [[User:Kynikos/Backup programs]]. Here I wanted to see if there's somebody who doesn't like the idea in general, possibly bringing reasoned objections, so that I avoid wasting time on a project that eventually wouldn't be merged.<br />
<br />
Positive feedback, ideas and direct contributions to the draft are also welcome, of course.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:03, 28 January 2016 (UTC)<br />
<br />
: Great idea! --[[User:Edh|Edh]] ([[User talk:Edh|talk]]) 17:08, 29 January 2016 (UTC)<br />
<br />
::Thanks, I will merge soon if there are no objections, because I can't fill the table by myself :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:31, 31 January 2016 (UTC)<br />
<br />
::Merged, hopefully it will improve over time. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:20, 31 January 2016 (UTC)<br />
<br />
:::I will see what I can contribute as soon as my semester is over. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:14, 31 January 2016 (UTC)<br />
<br />
=== Distributed file systems ===<br />
<br />
[[Samba]] and [[NFS]] are not distributed in the sense as the other entries. They may be seen as "distributed" from the client's point of view, but the storage is (usually) not distributed as is the case of e.g. GlusterFS. Samba and NFS can be used to export the final mount of a distributed file system over the network to the clients, but they are not responsible for the "distribution".<br />
<br />
Even Wikipedia is very confused about this, e.g. [[w:File_system#Network_file_systems]] shows NFS and Samba as examples and links to [[w:Distributed_file_system]] as the main article, which is also very clumsy with explaining all the differences.<br />
<br />
[[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:39, 31 January 2016 (UTC)<br />
<br />
:Right, thanks for clarifying. A secondary reason why I added NFS and Samba to the list is that the only "overview" article that links to them is [[General recommendations]]: for the moment I've moved them in the Related box of [[File systems]], but if we move the whole "Distributed file systems" section there from here, maybe also those two links can get their own section? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 1 February 2016 (UTC)<br />
<br />
::They could be added to [[List of applications#File sharing]], next to FTP. This page already links there. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 1 February 2016 (UTC)<br />
<br />
:::Agreed, done. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:08, 21 February 2016 (UTC)<br />
<br />
Anyway, are Archers supposed to run their own clusters for personal backups? :P<br />
<br />
[[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:39, 31 January 2016 (UTC)<br />
<br />
:Eheh initially the article was only mentioning Tahoe-LAFS among the Cloud storage applications. That's what encouraged me to add [[Ceph]], for which I remembered we have an article, and then I decided to mention also GlusterFS and Sheepdog, eventually splitting them in the current list. Although the article doesn't explicitly set its scope to personal backups, I agree that those projects may not fit well here, and that's why I proposed to move them to [[File systems]], instead of just deleting the section, so we don't reorphan [[Ceph]], what do you think? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 1 February 2016 (UTC)<br />
<br />
::There could be an introduction to "network targets" somewhere, listing all the common options: SSH/SFTP, rsync, FTP, NFS, Samba, 3rd party cloud services and then the distributed file systems. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 1 February 2016 (UTC)<br />
<br />
:::Update: [[File systems#Clustered file systems]] has been expanded. I'm in favor of merging [[List of applications/Internet#Distributed file systems]] there. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:46, 27 February 2017 (UTC)<br />
<br />
=== Adding new information and reorganising the table of chunk-based increments archive/backup tools ===<br />
<br />
Here's what I propose for this table:<br />
<br />
*Added: Column "Increment Basis" to differentiate between full+incremental design and tools that base new increments off all prior data<br />
*Added: Column "Historical archives can be removed" to differentiate between tools that are designed so prior archives can be removed easily or not<br />
*Also moved GUI frontends of CLI tools to the "other interfaces" column<br />
<br />
Here's the modified table: [[User:Level323]]<br />
<br />
[[User:Level323|Level323]] ([[User talk:Level323|talk]]) 22:20, 8 August 2016 (UTC)<br />
<br />
:* About "Increment Basis", doesn't that simply distinguish between applications that allow creating subsequent full backups and those that create only one at the beginning? I think it's misleading to color the "Prior full backup" case in red, because an additional full backup is done intentionally, and it's obvious that the subsequent increments are then based on it. If really one type should be considered "better" than the other (green vs red), then the ability to create subsequent full backups would be an additional feature, therefore that should be colored in green. If adding a column like this, however, I wouldn't color it at all.<br />
:* About "Historical archives can be removed" I agree it can be useful; perhaps the heading can be simplified with "Old archives removable".<br />
:* About merging GUI frontends into Other interfaces, I tend to disagree because a frontend may add or hide features when compared to the backend application. Also, at least kup has ambiguous documentation about the backend, search "Needed backup programs" in https://www.linux-apps.com/p/1127689/<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:50, 10 August 2016 (UTC)<br />
<br />
::* Re your comments about "increment basis": I think my perhaps poor choice of column title led you down the wrong track. The feature I intended to distinguish was the deduplication abilities of the tool. The "traditional" approach of full backups followed by incrementals (typically) only avoids duplication of entire files that have not changed since the last full backup. This means that the destination "archive" will still retain considerable duplication (the unchanged parts of larger files as well as files in the next full backup that have not changed since the last full backup). In contrast, tools like borg/attic/obnam/bup commit all backup data to a single monolithic store and employ a rolling hash. This eliminates the concept of full+incremental backups (and avoids the associated duplication) and it also avoids the duplication of parts of larger files that have not changed. So I've changed the column title to "deduplication method". I've also removed the colouring of that column, but would note that most common use cases (personal and SME backup roles) would see the old full+incremental paradigm as inferior to the monolithic store + rolling-hash method. About the only beneficial use case I can think of for the full+incremental approach is when the archive is being written to write-once media. <br />
::* Re column "Historical archives can be removed" I agree the name is clunky. Have changed it to your suggestion.<br />
::* Re merging GUI frontends: I don't mind either way. <br />
::[[User:Level323|Level323]] ([[User talk:Level323|talk]]) 01:09, 19 August 2016 (UTC)<br />
<br />
:::* Please pardon my stubbornness, but the meaning of the deduplication column isn't very clear yet to me :) Are we talking about the difference between [[w:Differential backup]] and [[w:Incremental backup]] (well explained in [[w:Differential backup#Illustration]])? Then I'd call the column "Diff basis" or similar, and I would directly and simply use "differential" or "incremental" in the cells, leaving the explanation to a "Specific legend" under [[Synchronization and backup programs#Chunk-based increments]], as it's already done for [[Synchronization and backup programs#File-based increments]], with links to the Wikipedia articles. Also, I'd move the column between "Implementation" and "Compressed storage", and I'd indeed leave it uncolored.<br />
:::* Green light for the "Old archives removable" column then.<br />
:::* About merging the GUI frontends, let's leave them separate until somebody else shares their opinion here.<br />
:::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:55, 19 August 2016 (UTC)<br />
<br />
== Backup by exporting list of programs ==<br />
<br />
This page seems to omit documentation on backing up the installed state of the operating system (as explained for other distros [http://www.cyberciti.biz/tips/linux-get-list-installed-software-reinstallation-restore.html here]). I guess maybe that's out of scope, bu pointing towards it might be helpful. [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 04:50, 24 October 2016 (UTC)<br />
<br />
== 2017-10-09 changes ==<br />
<br />
=== Bypassing articles with links to packages ===<br />
<br />
[https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492793] replaced, only in the "Data synchronization" section, some direct links to official websites with direct links to packages for applications with an ArchWiki article.<br />
<br />
This is a problem that I've also always seen in the App template, anyway I see it at least as redundant to link to ''both'' the package(s) and the main application article, which in turn surely links to the packages itself, 1) because the user may be tempted to install the packages directly, skipping any particular instructions that may be present in the article (which exists for a purpose), and 2) because we create duplication of content, i.e. if a package is split, renamed, alternatives are added etc., we have to keep both locations in sync. For this reason I propose to revert the edit.<br />
<br />
If I'm the only one thinking this way, however, the same change should be applied to the other tables for consistency.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:20, 10 October 2017 (UTC)<br />
<br />
:I don't regard it as a problem. By providing a link to the article and a link to the package readers can choose whether they want to directly install a package or follow the article's installation section. I don't think that the ArchWiki should be idiot-proof. Overviews always result in duplication. –[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:22, 11 October 2017 (UTC)<br />
<br />
::Let's leave this open for a third opinion then, the article can stay in the current state meanwhile, this isn't a big issue after all. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 12 October 2017 (UTC)<br />
<br />
:::[[Special:Diff/541102|I also updated the rest of the tables]] to be consistent with other comparison tables. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:21, 14 September 2018 (UTC)<br />
<br />
=== Partial legends ===<br />
<br />
[https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492808] [https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492809] [https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492814] removed a few legend entries because the meaning of the respective fields is, I agree, kind of obvious, however the legend still has entries for almost all fields, and only arbitrarily excluding a few ("obviousness" is subjective after all) gives me a sense of incompleteness, so I propose to restore the entries.<br />
<br />
Again, as an alternative the change should be applied to the rest of the article consistently.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:20, 10 October 2017 (UTC)<br />
<br />
:Thanks Larivact for restoring the legend entries. "Maintenance" is the only one left out, what if we reinstate it with the advice to add a "last-checked" date? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:26, 12 October 2017 (UTC)<br />
<br />
== taskd removal proposal ==<br />
taskd is specific to taskwarrior, it can't be used for generic file sync or backup. Should it be removed from this page ?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:45, 10 April 2021 (UTC)<br />
<br />
== Add luckybackup to the list ==<br />
<br />
[https://sourceforge.net/projects/luckybackup/ Luckybackup] is a simple GUI tool for backup & sync. Although, it is not actively being maintained, the author is active on their [https://sourceforge.net/p/luckybackup/discussion/ discussion] page. It is also available in the AUR [https://aur.archlinux.org/packages/luckybackup/ luckybackup]<sup>[AUR]</sup> --[[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 13:23, 20 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Synchronization_and_backup_programs&diff=706769Talk:Synchronization and backup programs2021-12-20T12:55:58Z<p>RaZorr: /* Add luckybackup to the list */ new section</p>
<hr />
<div>== should we mention par2cmdline? ==<br />
<br />
I had used parchive before and was looking for its packagename for it here. Maybe it should be mentioned. Feels backup-related enough to me.<br />
<br />
Thanks<br />
--[[User:Kristianlm|Kristianlm]] ([[User talk:Kristianlm|talk]]) 13:01, 15 October 2012 (UTC)<br />
<br />
== Guidelines for adding programs? ==<br />
Should a particular program (assuming it is open source) already have a package created for ArchLinux before adding it to this list? Also, what if it is relatively new, and doesn't have a lot of users yet, should it go through a minimum amount of other user testing before adding it? In the interest of full disclosure, I have recently contributed a backup system as open source (currently hosted on github), that I've personally used for a while -- it is similar in concept to the rsync-based backups, but it includes full file level deduplication (even across multiple clients), an SQLite-based catalog, and the client side uses standard GNU tar, find, and a wrapper shell script (no binaries to install on the client side). So you end up with the simplicity of rsync, with some of the features of the heavy-weight backup programs.<br />
<br />
Thought I would ask here first before posting a writeup on the main wiki page -- don't want to appear like I'm spamming links or anything. [[User:Derekp7|Derekp7]] ([[User talk:Derekp7|talk]]) 01:48, 17 February 2013 (UTC)<br />
: You are free to add your tool. But since this is an Arch Wiki, the tool should be easily accessed by Arch user. I think at least a [[AUR]] package is needed. Create a [[AUR]] package is very easy. See the [[AUR]] and [[PKGBUILD]] for how to. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:42, 17 February 2013 (UTC)<br />
<br />
== Cloud backups ==<br />
<br />
Can I add these tree other options or they are not suitable by any reason?<br />
<br />
- Drive[https://tools.google.com/dlpage/drive] - AUR[https://aur.archlinux.org/packages/grive/]<br />
- Copy[https://www1.copy.com/home/] - AUR[https://aur.archlinux.org/packages/copy/]<br />
- Bitcasa[http://www.bitcasa.com/] - AUR[https://aur.archlinux.org/packages/bitcasa/]<br />
<br />
--[[User:Gbc921|Gabriel B. Casella]] ([[User talk:Gbc921|talk]]) 21:37, 13 December 2013 (UTC)<br />
<br />
:Sure, considering that MEGA is listed in [[Backup_Programs#Cloud_backups]], these three would fit there much better ;) But please keep the structure the same as for other software. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:01, 13 December 2013 (UTC)<br />
<br />
=== Wuala is shutting down ===<br />
<br />
Wuala is shutting down, see notice[https://support.wuala.com/2015/08/wuala-shutdown-notice/]. Can I remove it? Also it's recommended alternative Tresorit[https://tresorit.com] is not exaclty the same, it's more of an encrypted Dropbox.<br />
<br />
-- [[User:Folti|Folti]] ([[User talk:Folti|talk]]) 14:08, 29 September 2015 (UTC)<br />
<br />
:Yes, please remove Wuala. I don't know Tresorit, you may add it if you want, or leave it to somebody else. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:38, 30 September 2015 (UTC)<br />
<br />
== Should a link to a performance comparison between Rsync, Rdiff-backup, Duplicity, Areca and Link-Backup be included? ==<br />
<br />
I am one of the authors of [http://www.si-journal.org/index.php/JSI/article/view/205 this paper] were we compare the performance and system resources usage of five backup tools. Should it be included in this wiki?<br />
<br />
Thanks {{Unsigned|Oct 2014|Aurhe}}<br />
<br />
:Yes, you can use the See also section at the bottom. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:35, 8 October 2014 (UTC)<br />
<br />
== The Console / Graphical categorization doesn't really make sense any more ==<br />
<br />
I just added '''Bacula''', which appears to be the most downloaded open source backup solution. Bacula can be used in console and graphical mode, and included a web interface as well. For the time being I just created a new category: Console & Graphical. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 13:23, 20 December 2014 (UTC)<br />
<br />
:Hi, I don't get it, are you just reporting the fact that you've added Bacula, or are you proposing something about the Console/Graphical categorization? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:22, 21 December 2014 (UTC)<br />
<br />
::Bacula is the example of why the categorization scheme doesn't make sense. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:41, 22 December 2014 (UTC)<br />
<br />
:::I'm not a big fan of that distinction either for the same reason, but it's derived from [[List of applications]], and I feel many users would object to its removal. Let's leave this open and see if there are more comments. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:25, 23 December 2014 (UTC)<br />
<br />
== Radical reorganization ==<br />
<br />
I'm working on a possible restructuring of the page, especially using a table to compare the numerous incremental backup applications, see the draft at [[User:Kynikos/Backup programs]]. Here I wanted to see if there's somebody who doesn't like the idea in general, possibly bringing reasoned objections, so that I avoid wasting time on a project that eventually wouldn't be merged.<br />
<br />
Positive feedback, ideas and direct contributions to the draft are also welcome, of course.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:03, 28 January 2016 (UTC)<br />
<br />
: Great idea! --[[User:Edh|Edh]] ([[User talk:Edh|talk]]) 17:08, 29 January 2016 (UTC)<br />
<br />
::Thanks, I will merge soon if there are no objections, because I can't fill the table by myself :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:31, 31 January 2016 (UTC)<br />
<br />
::Merged, hopefully it will improve over time. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:20, 31 January 2016 (UTC)<br />
<br />
:::I will see what I can contribute as soon as my semester is over. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 18:14, 31 January 2016 (UTC)<br />
<br />
=== Distributed file systems ===<br />
<br />
[[Samba]] and [[NFS]] are not distributed in the sense as the other entries. They may be seen as "distributed" from the client's point of view, but the storage is (usually) not distributed as is the case of e.g. GlusterFS. Samba and NFS can be used to export the final mount of a distributed file system over the network to the clients, but they are not responsible for the "distribution".<br />
<br />
Even Wikipedia is very confused about this, e.g. [[w:File_system#Network_file_systems]] shows NFS and Samba as examples and links to [[w:Distributed_file_system]] as the main article, which is also very clumsy with explaining all the differences.<br />
<br />
[[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:39, 31 January 2016 (UTC)<br />
<br />
:Right, thanks for clarifying. A secondary reason why I added NFS and Samba to the list is that the only "overview" article that links to them is [[General recommendations]]: for the moment I've moved them in the Related box of [[File systems]], but if we move the whole "Distributed file systems" section there from here, maybe also those two links can get their own section? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 1 February 2016 (UTC)<br />
<br />
::They could be added to [[List of applications#File sharing]], next to FTP. This page already links there. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 1 February 2016 (UTC)<br />
<br />
:::Agreed, done. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:08, 21 February 2016 (UTC)<br />
<br />
Anyway, are Archers supposed to run their own clusters for personal backups? :P<br />
<br />
[[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:39, 31 January 2016 (UTC)<br />
<br />
:Eheh initially the article was only mentioning Tahoe-LAFS among the Cloud storage applications. That's what encouraged me to add [[Ceph]], for which I remembered we have an article, and then I decided to mention also GlusterFS and Sheepdog, eventually splitting them in the current list. Although the article doesn't explicitly set its scope to personal backups, I agree that those projects may not fit well here, and that's why I proposed to move them to [[File systems]], instead of just deleting the section, so we don't reorphan [[Ceph]], what do you think? — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 1 February 2016 (UTC)<br />
<br />
::There could be an introduction to "network targets" somewhere, listing all the common options: SSH/SFTP, rsync, FTP, NFS, Samba, 3rd party cloud services and then the distributed file systems. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 1 February 2016 (UTC)<br />
<br />
:::Update: [[File systems#Clustered file systems]] has been expanded. I'm in favor of merging [[List of applications/Internet#Distributed file systems]] there. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:46, 27 February 2017 (UTC)<br />
<br />
=== Adding new information and reorganising the table of chunk-based increments archive/backup tools ===<br />
<br />
Here's what I propose for this table:<br />
<br />
*Added: Column "Increment Basis" to differentiate between full+incremental design and tools that base new increments off all prior data<br />
*Added: Column "Historical archives can be removed" to differentiate between tools that are designed so prior archives can be removed easily or not<br />
*Also moved GUI frontends of CLI tools to the "other interfaces" column<br />
<br />
Here's the modified table: [[User:Level323]]<br />
<br />
[[User:Level323|Level323]] ([[User talk:Level323|talk]]) 22:20, 8 August 2016 (UTC)<br />
<br />
:* About "Increment Basis", doesn't that simply distinguish between applications that allow creating subsequent full backups and those that create only one at the beginning? I think it's misleading to color the "Prior full backup" case in red, because an additional full backup is done intentionally, and it's obvious that the subsequent increments are then based on it. If really one type should be considered "better" than the other (green vs red), then the ability to create subsequent full backups would be an additional feature, therefore that should be colored in green. If adding a column like this, however, I wouldn't color it at all.<br />
:* About "Historical archives can be removed" I agree it can be useful; perhaps the heading can be simplified with "Old archives removable".<br />
:* About merging GUI frontends into Other interfaces, I tend to disagree because a frontend may add or hide features when compared to the backend application. Also, at least kup has ambiguous documentation about the backend, search "Needed backup programs" in https://www.linux-apps.com/p/1127689/<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:50, 10 August 2016 (UTC)<br />
<br />
::* Re your comments about "increment basis": I think my perhaps poor choice of column title led you down the wrong track. The feature I intended to distinguish was the deduplication abilities of the tool. The "traditional" approach of full backups followed by incrementals (typically) only avoids duplication of entire files that have not changed since the last full backup. This means that the destination "archive" will still retain considerable duplication (the unchanged parts of larger files as well as files in the next full backup that have not changed since the last full backup). In contrast, tools like borg/attic/obnam/bup commit all backup data to a single monolithic store and employ a rolling hash. This eliminates the concept of full+incremental backups (and avoids the associated duplication) and it also avoids the duplication of parts of larger files that have not changed. So I've changed the column title to "deduplication method". I've also removed the colouring of that column, but would note that most common use cases (personal and SME backup roles) would see the old full+incremental paradigm as inferior to the monolithic store + rolling-hash method. About the only beneficial use case I can think of for the full+incremental approach is when the archive is being written to write-once media. <br />
::* Re column "Historical archives can be removed" I agree the name is clunky. Have changed it to your suggestion.<br />
::* Re merging GUI frontends: I don't mind either way. <br />
::[[User:Level323|Level323]] ([[User talk:Level323|talk]]) 01:09, 19 August 2016 (UTC)<br />
<br />
:::* Please pardon my stubbornness, but the meaning of the deduplication column isn't very clear yet to me :) Are we talking about the difference between [[w:Differential backup]] and [[w:Incremental backup]] (well explained in [[w:Differential backup#Illustration]])? Then I'd call the column "Diff basis" or similar, and I would directly and simply use "differential" or "incremental" in the cells, leaving the explanation to a "Specific legend" under [[Synchronization and backup programs#Chunk-based increments]], as it's already done for [[Synchronization and backup programs#File-based increments]], with links to the Wikipedia articles. Also, I'd move the column between "Implementation" and "Compressed storage", and I'd indeed leave it uncolored.<br />
:::* Green light for the "Old archives removable" column then.<br />
:::* About merging the GUI frontends, let's leave them separate until somebody else shares their opinion here.<br />
:::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:55, 19 August 2016 (UTC)<br />
<br />
== Backup by exporting list of programs ==<br />
<br />
This page seems to omit documentation on backing up the installed state of the operating system (as explained for other distros [http://www.cyberciti.biz/tips/linux-get-list-installed-software-reinstallation-restore.html here]). I guess maybe that's out of scope, bu pointing towards it might be helpful. [[User:Ben Creasy|Ben Creasy]] ([[User talk:Ben Creasy|talk]]) 04:50, 24 October 2016 (UTC)<br />
<br />
== 2017-10-09 changes ==<br />
<br />
=== Bypassing articles with links to packages ===<br />
<br />
[https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492793] replaced, only in the "Data synchronization" section, some direct links to official websites with direct links to packages for applications with an ArchWiki article.<br />
<br />
This is a problem that I've also always seen in the App template, anyway I see it at least as redundant to link to ''both'' the package(s) and the main application article, which in turn surely links to the packages itself, 1) because the user may be tempted to install the packages directly, skipping any particular instructions that may be present in the article (which exists for a purpose), and 2) because we create duplication of content, i.e. if a package is split, renamed, alternatives are added etc., we have to keep both locations in sync. For this reason I propose to revert the edit.<br />
<br />
If I'm the only one thinking this way, however, the same change should be applied to the other tables for consistency.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:20, 10 October 2017 (UTC)<br />
<br />
:I don't regard it as a problem. By providing a link to the article and a link to the package readers can choose whether they want to directly install a package or follow the article's installation section. I don't think that the ArchWiki should be idiot-proof. Overviews always result in duplication. –[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 15:22, 11 October 2017 (UTC)<br />
<br />
::Let's leave this open for a third opinion then, the article can stay in the current state meanwhile, this isn't a big issue after all. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 12 October 2017 (UTC)<br />
<br />
:::[[Special:Diff/541102|I also updated the rest of the tables]] to be consistent with other comparison tables. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:21, 14 September 2018 (UTC)<br />
<br />
=== Partial legends ===<br />
<br />
[https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492808] [https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492809] [https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&diff=next&oldid=492814] removed a few legend entries because the meaning of the respective fields is, I agree, kind of obvious, however the legend still has entries for almost all fields, and only arbitrarily excluding a few ("obviousness" is subjective after all) gives me a sense of incompleteness, so I propose to restore the entries.<br />
<br />
Again, as an alternative the change should be applied to the rest of the article consistently.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:20, 10 October 2017 (UTC)<br />
<br />
:Thanks Larivact for restoring the legend entries. "Maintenance" is the only one left out, what if we reinstate it with the advice to add a "last-checked" date? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:26, 12 October 2017 (UTC)<br />
<br />
== taskd removal proposal ==<br />
taskd is specific to taskwarrior, it can't be used for generic file sync or backup. Should it be removed from this page ?<br />
<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 13:45, 10 April 2021 (UTC)<br />
<br />
== Add luckybackup to the list ==<br />
<br />
[https://sourceforge.net/projects/luckybackup/ Luckybackup] is a simple GUI tool for backup & sync. Although, it is not actively being maintained, the author is active on their [https://sourceforge.net/p/luckybackup/discussion/ discussion] page. It is also available in the AUR [https://aur.archlinux.org/packages/luckybackup/ luckybackup]<sup>[AUR]</sup> --12:55, 20 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Autostarting&diff=706764Talk:Autostarting2021-12-20T11:33:56Z<p>RaZorr: /* Event change utility */ new section</p>
<hr />
<div>== Example ==<br />
<br />
On bootup/shutdown the text only links to systemd wiki page, and there isn't any example of how to do autostarting at bootup. In forum, there's is an example at [https://bbs.archlinux.org/viewtopic.php?pid=1701642#p1701642]. It would be useful if this example is in the wiki. --[[User:Juanmah|Juanmah]] ([[User talk:Juanmah|talk]]) 19:30, 12 September 2018 (UTC)<br />
<br />
== XDG Autostart ==<br />
<br />
Of the 4 WM listed, only one (Openbox) has an article where xdg-autostart is supported natively. It could be interesting to add a comment for the ones supporting it natively (same for DE).<br />
I also think it should be mentionned that xdg-autostart behavior can be implemented indirectly in this article.<br />
[[User:Apollo22|Apollo22]] ([[User talk:Apollo22|talk]]) 21:42, 28 May 2019 (UTC)<br />
<br />
== Event change utility ==<br />
<br />
Maybe add [https://github.com/eradman/entr Entr] to the section [[Autostarting#On_filesystem_events|filesystem_events]] - [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 11:33, 20 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Xorg&diff=706068Talk:Xorg2021-12-16T13:07:55Z<p>RaZorr: Adding signature</p>
<hr />
<div>== Setting DPI manually ==<br />
<br />
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.<br />
<br />
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.<br />
<br />
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 05:25, 10 December 2013 (UTC)<br />
<br />
:As you probably noticed, [[Xorg#Display_size_and_DPI]] is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that {{Pkg|xorg-server}} uses several patches (see [https://github.com/archlinux/svntogit-packages/blob/packages/xorg-server/trunk]). I don't know which patches other distros use, but this option is not likely to depend on the patches.<br />
:Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:34, 10 December 2013 (UTC)<br />
<br />
::As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to [https://bugs.kde.org/show_bug.cgi?id=317929#c13 Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems]. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.<br />
<br />
::"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]])<br />
<br />
:::I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is ''not'' automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. {{unsigned|20:17, 5 June 2015|Silverhammermba}}<br />
<br />
::::Having fought this problem with a gen4 Intel laptop---1280x800@14.1in LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. [[User:Vorbote|Vorbote]] ([[User talk:Vorbote|talk]]) 14:17, 7 October 2015 (UTC)<br />
<br />
:::::I did some experiments in my Radeon HD6310 and discover somethings... lets start:<br />
:::::* efectively, set the dpi in the xorg file is meaningless, as is ignored<br />
:::::* set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.<br />
:::::My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/ <br />
:::::{{unsigned|05:40, 19 April 2016 (UTC)|Jristz}}<br />
<br />
::::::'''If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings.''' In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX ''after'' xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. [[User:Dc46and2|Dc46and2]] ([[User talk:Dc46and2|talk]]) 02:34, 9 June 2016 (UTC)<br />
<br />
:::::::In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system"] on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 06:45, 1 February 2017 (UTC)<br />
<br />
:::::: Regarding the Xorg xft.dpi issue, the ticket is now moved to Gitlab: [https://gitlab.freedesktop.org/xorg/xserver/issues/509 See Xserver issue 509].<br />
:::::: [[User:Danger89|Danger89]] ([[User talk:Danger89|talk]]) 15:04, 15 March 2019 (UTC)<br />
<br />
== Add xhost si:localuser:$USER ? ==<br />
<br />
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see [https://bbs.archlinux.org/viewtopic.php?id=202704 BBS#202704], [[Connman#Avoid_changing_the_hostname]]), things stop working. The user name is (or should be) less prone to change, so you could use {{Pkg|xorg-xhost}} for access:<br />
<br />
$ xhost si:localuser:$USER<br />
<br />
man Xsecurity says on this:<br />
<br />
localuser & localgroup<br />
On systems which can determine in a secure fashion the credentials of a client process,<br />
the "localuser" and "localgroup" authentication methods provide access based on those<br />
credentials. The format of the values provided is platform specific. For POSIX & UNIX<br />
platforms, if the value starts with the character '#', the rest of the string is treated<br />
as a decimal uid or gid, otherwise the string is defined as a user name or group name.<br />
<br />
If your system supports this method and you use it, be warned that some programs that<br />
proxy connections and are setuid or setgid may get authenticated as the uid or gid of<br />
the proxy process. For instance, some versions of ssh will be authenticated as the user<br />
root, no matter what user is running the ssh client, so on systems with such software,<br />
adding access for localuser:root may allow wider access than intended to the X display.<br />
<br />
However, X apps failing is the symptom; the cause lies in [[Network configuration]], or an issue with the (static) [[hostname]] not being respected. So I'm not sure where to mention this, if at all. One way would be to expand [[Xhost]] and add a link there under [[Xorg#Troubleshooting]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:51, 21 September 2015 (UTC)<br />
<br />
: For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.<br />
<br />
: As for where this should go? I have no idea. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 23:54, 13 March 2016 (UTC)<br />
<br />
== Location of Xorg.0.log ==<br />
<br />
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:<br />
<br />
/var/log/Xorg.0.log<br />
<br />
and <br />
~/.local/share/xorg/Xorg.0.log<br />
<br />
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by [[User:Slacka]], 20170112<br />
<br />
seconded <br />
/var/log/Xorg.0.log<br />
needs to be specified, im running i3wm<br />
--[[User:Yair|Yair]] ([[User talk:Yair|talk]]) 17:21, 20 April 2018 (UTC)<br />
<br />
== Rootless Xorg ==<br />
<br />
Reverted edit by Alad: "useless without reference, i.e. a bug report "<br />
And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design?<br />
[[User:Aufkrawall|Aufkrawall]] ([[User talk:Aufkrawall|talk]]) 16:14, 6 November 2017 (UTC)<br />
<br />
:That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 6 November 2017 (UTC)<br />
<br />
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use {{ic|startx}} instead of {{ic|exec startx}}, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested [https://bbs.archlinux.org/viewtopic.php?pid=1973717#p1973717/ here] that this section should be edited/moved. [[User:Garfa|Garfa]] ([[User talk:Garfa|talk]]) 17:01, 22 May 2021 (UTC)<br />
<br />
== Remove/replace/update the xorg.conf config section? ==<br />
<br />
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section.<br />
In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility.<br />
It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.<br />
<br />
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly.<br />
Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)<br />
<br />
{{unsigned|07:30, 2 April 2018|Seth}}<br />
<br />
== Best place for eGPU configs ==<br />
<br />
Greetings,<br />
I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.<br />
<br />
To get eGPU working with external monitor and internal one disabled:<br />
* Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)<br />
* Use something like the following for the Xorg config:<br />
Section "Module"<br />
Load "modesetting"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia"<br />
Driver "nvidia"<br />
BusID "PCI:6:0:0"<br />
Option "AllowEmptyInitialConfiguration"<br />
Option "AllowExternalGpus"<br />
EndSection<br />
<br />
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io.<br />
First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests. <br />
<br />
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.<br />
<br />
Whats the best place to add this information? <br />
I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"<br />
<br />
[[User:Snugghash|Snugghash]] ([[User talk:Snugghash|talk]]) 22:59, 10 August 2018 (UTC)<br />
<br />
:Since it is specific to the NVIDIA driver, add it to [[NVIDIA/Tips_and_tricks]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:41, 11 August 2018 (UTC)<br />
<br />
== systemctl --user in rootless Xorg ==<br />
<br />
To get {{ic|systemctl --user}} to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit {{ic|/etc/pam.d/system-login}} so that {{ic|pam_systemd.so}} is required (that is remove the {{ic|-}} in front of {{ic|session}} and change {{ic|optional}} to {{ic|required}}). I am not sure why this isn't the default somehow. -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 19:28, 6 November 2018 (UTC)<br />
<br />
:''to get'' {{ic|systemctl --user}} ''to work''<br />
:not sure what you mean by that but i use ''--user'' for cron like jobs without changing {{ic|/etc/pam.d/system-login}} --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:07, 7 November 2018 (UTC)<br />
<br />
::I just meant any command using {{ic|systemctl --user}}.<br />
::My comment was specific to rootless Xorg, but was edited out of its context, are you using rootless Xorg? -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 17:48, 10 November 2018 (UTC)<br />
<br />
:::yes ---[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 11 November 2018 (UTC)<br />
<br />
== XWayland ==<br />
<br />
As discussed in [[Talk:Wayland#XWayland]], I would like to add a small section for XWayland.<br />
<br />
Technically it is a part of the XServer, so where would you like it better, here or at [[Wayland]]?<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:45, 17 October 2020 (UTC) G3ro<br />
<br />
== <s>Information about xf86-video-intel</s> ==<br />
<br />
Maybe mention [https://wiki.archlinux.org/title/Intel_graphics#Installation Intel graphics installation] '''note''' near '''xf86-video-intel''' in [https://wiki.archlinux.org/title/Xorg#Driver_installation Xorg#driver_installation] section. From [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] {{Unsigned|07:33, 8 December 2021 (UTC)|RaZorr}}<br />
<br />
:There is already a link to [[Intel graphics#Installation]] in the note below the table. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:34, 8 December 2021 (UTC)<br />
<br />
::But I think it can be made more obvious. As of now, user may not find any reason to visit the [[Intel graphics#Installation]] documentation. Also, could you look at [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] ? [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 11:47, 16 December 2021 (UTC)<br />
<br />
:::People might miss it no matter where you put it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:38, 16 December 2021 (UTC)<br />
<br />
::::Alright. Could you look at [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] ? This is regarding [[AMDGPU_PRO]], [[AMDGPU]] and [[Intel_graphics]] [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 13:07, 16 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Xorg&diff=706067Talk:Xorg2021-12-16T13:07:07Z<p>RaZorr: regarding graphics command in various sections</p>
<hr />
<div>== Setting DPI manually ==<br />
<br />
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.<br />
<br />
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.<br />
<br />
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 05:25, 10 December 2013 (UTC)<br />
<br />
:As you probably noticed, [[Xorg#Display_size_and_DPI]] is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that {{Pkg|xorg-server}} uses several patches (see [https://github.com/archlinux/svntogit-packages/blob/packages/xorg-server/trunk]). I don't know which patches other distros use, but this option is not likely to depend on the patches.<br />
:Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:34, 10 December 2013 (UTC)<br />
<br />
::As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to [https://bugs.kde.org/show_bug.cgi?id=317929#c13 Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems]. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.<br />
<br />
::"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]])<br />
<br />
:::I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is ''not'' automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. {{unsigned|20:17, 5 June 2015|Silverhammermba}}<br />
<br />
::::Having fought this problem with a gen4 Intel laptop---1280x800@14.1in LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. [[User:Vorbote|Vorbote]] ([[User talk:Vorbote|talk]]) 14:17, 7 October 2015 (UTC)<br />
<br />
:::::I did some experiments in my Radeon HD6310 and discover somethings... lets start:<br />
:::::* efectively, set the dpi in the xorg file is meaningless, as is ignored<br />
:::::* set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.<br />
:::::My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/ <br />
:::::{{unsigned|05:40, 19 April 2016 (UTC)|Jristz}}<br />
<br />
::::::'''If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings.''' In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX ''after'' xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. [[User:Dc46and2|Dc46and2]] ([[User talk:Dc46and2|talk]]) 02:34, 9 June 2016 (UTC)<br />
<br />
:::::::In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system"] on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 06:45, 1 February 2017 (UTC)<br />
<br />
:::::: Regarding the Xorg xft.dpi issue, the ticket is now moved to Gitlab: [https://gitlab.freedesktop.org/xorg/xserver/issues/509 See Xserver issue 509].<br />
:::::: [[User:Danger89|Danger89]] ([[User talk:Danger89|talk]]) 15:04, 15 March 2019 (UTC)<br />
<br />
== Add xhost si:localuser:$USER ? ==<br />
<br />
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see [https://bbs.archlinux.org/viewtopic.php?id=202704 BBS#202704], [[Connman#Avoid_changing_the_hostname]]), things stop working. The user name is (or should be) less prone to change, so you could use {{Pkg|xorg-xhost}} for access:<br />
<br />
$ xhost si:localuser:$USER<br />
<br />
man Xsecurity says on this:<br />
<br />
localuser & localgroup<br />
On systems which can determine in a secure fashion the credentials of a client process,<br />
the "localuser" and "localgroup" authentication methods provide access based on those<br />
credentials. The format of the values provided is platform specific. For POSIX & UNIX<br />
platforms, if the value starts with the character '#', the rest of the string is treated<br />
as a decimal uid or gid, otherwise the string is defined as a user name or group name.<br />
<br />
If your system supports this method and you use it, be warned that some programs that<br />
proxy connections and are setuid or setgid may get authenticated as the uid or gid of<br />
the proxy process. For instance, some versions of ssh will be authenticated as the user<br />
root, no matter what user is running the ssh client, so on systems with such software,<br />
adding access for localuser:root may allow wider access than intended to the X display.<br />
<br />
However, X apps failing is the symptom; the cause lies in [[Network configuration]], or an issue with the (static) [[hostname]] not being respected. So I'm not sure where to mention this, if at all. One way would be to expand [[Xhost]] and add a link there under [[Xorg#Troubleshooting]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:51, 21 September 2015 (UTC)<br />
<br />
: For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.<br />
<br />
: As for where this should go? I have no idea. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 23:54, 13 March 2016 (UTC)<br />
<br />
== Location of Xorg.0.log ==<br />
<br />
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:<br />
<br />
/var/log/Xorg.0.log<br />
<br />
and <br />
~/.local/share/xorg/Xorg.0.log<br />
<br />
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by [[User:Slacka]], 20170112<br />
<br />
seconded <br />
/var/log/Xorg.0.log<br />
needs to be specified, im running i3wm<br />
--[[User:Yair|Yair]] ([[User talk:Yair|talk]]) 17:21, 20 April 2018 (UTC)<br />
<br />
== Rootless Xorg ==<br />
<br />
Reverted edit by Alad: "useless without reference, i.e. a bug report "<br />
And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design?<br />
[[User:Aufkrawall|Aufkrawall]] ([[User talk:Aufkrawall|talk]]) 16:14, 6 November 2017 (UTC)<br />
<br />
:That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 6 November 2017 (UTC)<br />
<br />
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use {{ic|startx}} instead of {{ic|exec startx}}, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested [https://bbs.archlinux.org/viewtopic.php?pid=1973717#p1973717/ here] that this section should be edited/moved. [[User:Garfa|Garfa]] ([[User talk:Garfa|talk]]) 17:01, 22 May 2021 (UTC)<br />
<br />
== Remove/replace/update the xorg.conf config section? ==<br />
<br />
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section.<br />
In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility.<br />
It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.<br />
<br />
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly.<br />
Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)<br />
<br />
{{unsigned|07:30, 2 April 2018|Seth}}<br />
<br />
== Best place for eGPU configs ==<br />
<br />
Greetings,<br />
I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.<br />
<br />
To get eGPU working with external monitor and internal one disabled:<br />
* Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)<br />
* Use something like the following for the Xorg config:<br />
Section "Module"<br />
Load "modesetting"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia"<br />
Driver "nvidia"<br />
BusID "PCI:6:0:0"<br />
Option "AllowEmptyInitialConfiguration"<br />
Option "AllowExternalGpus"<br />
EndSection<br />
<br />
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io.<br />
First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests. <br />
<br />
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.<br />
<br />
Whats the best place to add this information? <br />
I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"<br />
<br />
[[User:Snugghash|Snugghash]] ([[User talk:Snugghash|talk]]) 22:59, 10 August 2018 (UTC)<br />
<br />
:Since it is specific to the NVIDIA driver, add it to [[NVIDIA/Tips_and_tricks]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:41, 11 August 2018 (UTC)<br />
<br />
== systemctl --user in rootless Xorg ==<br />
<br />
To get {{ic|systemctl --user}} to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit {{ic|/etc/pam.d/system-login}} so that {{ic|pam_systemd.so}} is required (that is remove the {{ic|-}} in front of {{ic|session}} and change {{ic|optional}} to {{ic|required}}). I am not sure why this isn't the default somehow. -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 19:28, 6 November 2018 (UTC)<br />
<br />
:''to get'' {{ic|systemctl --user}} ''to work''<br />
:not sure what you mean by that but i use ''--user'' for cron like jobs without changing {{ic|/etc/pam.d/system-login}} --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:07, 7 November 2018 (UTC)<br />
<br />
::I just meant any command using {{ic|systemctl --user}}.<br />
::My comment was specific to rootless Xorg, but was edited out of its context, are you using rootless Xorg? -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 17:48, 10 November 2018 (UTC)<br />
<br />
:::yes ---[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 11 November 2018 (UTC)<br />
<br />
== XWayland ==<br />
<br />
As discussed in [[Talk:Wayland#XWayland]], I would like to add a small section for XWayland.<br />
<br />
Technically it is a part of the XServer, so where would you like it better, here or at [[Wayland]]?<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:45, 17 October 2020 (UTC) G3ro<br />
<br />
== <s>Information about xf86-video-intel</s> ==<br />
<br />
Maybe mention [https://wiki.archlinux.org/title/Intel_graphics#Installation Intel graphics installation] '''note''' near '''xf86-video-intel''' in [https://wiki.archlinux.org/title/Xorg#Driver_installation Xorg#driver_installation] section. From [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] {{Unsigned|07:33, 8 December 2021 (UTC)|RaZorr}}<br />
<br />
:There is already a link to [[Intel graphics#Installation]] in the note below the table. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:34, 8 December 2021 (UTC)<br />
<br />
::But I think it can be made more obvious. As of now, user may not find any reason to visit the [[Intel graphics#Installation]] documentation. Also, could you look at [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] ? [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 11:47, 16 December 2021 (UTC)<br />
<br />
:::People might miss it no matter where you put it. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:38, 16 December 2021 (UTC)<br />
<br />
:::: Alright. Could you look at [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] ? This is regarding [[AMDGPU_PRO]], [[AMDGPU]] and [[Intel_graphics]] sections 13:07, 16 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Power_management&diff=706064Talk:Power management2021-12-16T13:01:54Z<p>RaZorr: Add signature</p>
<hr />
<div>== Suspend/resume service files ==<br />
<br />
I have the slight suspicion that the service files posted in the section [[Power Management#Suspend/resume service files]] might not work. Has anybody tried them or is actually using them? <br><br />
-- [[User:Jakobh|jakobh]] [[User talk:Jakobh|✉]] 03:12, 10 May 2013 (UTC)<br />
<br />
: (Mod: the section was moved from [[systemd]] into [[Power Management]], so I moved this post too, fixed link along the way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 21 August 2013 (UTC))<br />
<br />
== Sleep hooks ==<br />
<br />
Where is the exact difference between '''Suspend/resume service files''' approach and '''Hooks in /usr/lib/systemd/system-sleep'''?<br />
<br />
Is the latter obsolete?<br />
<br />
-- [[User:Orschiro|Orschiro]] 07:33, 17 January 2014<br />
<br />
:From {{ic|systemd-sleep(8)}}:<br />
::"Note that scripts or binaries dropped in {{ic|/usr/lib/systemd/system-sleep/}} are intended for local use only and should be considered hacks."<br />
:It's always preferred to use service files, they are much more flexible in handling the dependencies etc.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 23:52, 31 January 2014 (UTC)<br />
<br />
== Delayed hibernation service ==<br />
<br />
I have found that the service file given in this section does not work. My laptop hibernates immediately after resuming from suspend. I have also found that the older version of this service found in the forum post does indeed work perfectly. Does anyone know why this is?<br />
[[User:Aouellette|Aouellette]] ([[User talk:Aouellette|talk]]) 16:16, 30 May 2015 (UTC)<br />
<br />
== Resume file does not work after resuming from hibernation ==<br />
<br />
The systemd unit {{ic|User resume actions}} presented on this page only worked for me after resuming from sleep, not from hibernate. <br />
After adding {{ic|hibernate.target}} to the {{ic|After}} and {{ic|WantedBy}} lines it works both ways.<br />
However this is the first time I've done anything with such service files so I ain't sure if this is the optimal way.<br />
Can anyone confirm?<br />
<br />
{{unsigned|18:30, 12 October 2015|PhilippD}}<br />
<br />
:Actually, the {{ic|suspend@.service}} in [[Power_management#Suspend.2Fresume_service_files]] binds to {{ic|sleep.target}}, but {{ic|resume@.service}} binds to {{ic|suspend.target}}. They are not synonyms, systemd triggers {{ic|suspend.target}} and {{ic|sleep.target}} when the system is suspended to RAM, and {{ic|hibernate.target}} and {{ic|sleep.target}} when it is suspended to disk. This way you can bind your service to either one or both suspend methods using just a single target. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:17, 12 October 2015 (UTC)<br />
<br />
== Bluetooth rfkill ==<br />
<br />
Systemd now provides {{ic|systemd-rfkill.service}}. If you use {{ic|rfkill block}} to disable bluetooth, {{ic|systemd-rfkill.service}} will remember this and restore this state on next boot -- [[User:robtaylor|robtaylor]] ([[User talk:robtaylor|talk]]) Wed 18 May 16:10:05 BST 2016<br />
<br />
== A "sensible value" for the laptop mode ==<br />
<br />
The vast amount of specific information carried in this part, I find it a bit surprising. It seems "A sensible value for the laptop mode 'knob' is 5 seconds." could be heard in the mouth of a politician kicking the ball into touch.<br />
<br />
From Documentation/laptops/laptop-mode.txt:<br />
<br />
> The value of the laptop_mode knob determines the time between the occurrence of disk I/O <br />
and when the flush is triggered. A sensible value for the knob is 5 seconds. Setting the knob<br />
to 0 disables laptop mode.<br />
<br />
So "5 (seconds)" is related to the virtual memory subsystem (in direct relation to ''vm.dirty_writeback_centisecs''). Then "0" turns laptop mode off, aha. It'd be cool to know *what* is laptop_mode is in the first place: Is it the whole vm configuration settings that are described in the docs? I believe not, as e.g. the conf files are not to be seen in present Arch (nor in other distros I know of).<br />
<br />
A few things changed a bit since the Documentation/laptops/laptop-mode.txt was last edited, in 2004. I've searched extensively which part of it might still be up to date, without success so far. ''TLP'' has many if not most of the settings the doc explains. And so looks as an evolution of ''laptop_mode''. Would a guru or someone with knowledge about that be kind enough to specify the effect of ''vm.laptop_mode''? [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:33, 1 September 2016 (UTC)<br />
<br />
:The effect of the {{ic|vm.laptop_mode}} is described in the kernel docs in "The Details" section. The scripts that the docs talk about are probably [[Laptop Mode Tools]] nowadays. They are needed only to switch settings based on the current power source (and as a "bonus" they integrate most of the things in the [[Power_management#Power_saving]] section), but I bet the kernel settings are mostly the same as in 2004. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:41, 2 September 2016 (UTC)<br />
<br />
:: I now see that, thank you Lahwaacz. Now as we may increase flush time to disk (to, say, ten minutes) via {{ic|vm.dirty_writeback_centisecs}}, delaying the flush up to five seconds via the {{ic|vm.laptop_mode}} knob doesn't make much sense regarding the ''disk'' power-savings... But it may help the ''cpu'' staying idle longer. Hence, whether set via [[laptop-mode-tools]], [[tlp]] or proper self-made [[udev]] rules. I.e. {{ic|vm.laptop_mode}} and {{ic|vm.dirty_*}} together help delaying and grouping system's activity ''as a whole'', allowing for longer power-saving efficient idle times. Please correct me if I'm wrong. [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 19:37, 4 September 2016 (UTC)<br />
<br />
::: True, but the delay via {{ic|vm.laptop_mode}} makes sense also for other reasons. Let's say {{ic|vm.dirty_writeback_centisecs}} is set to something like 10 minutes and the disk is spun down due to inactivity and stays like that for e.g. 8 minutes, when it spins up due to user activity. Flushing all the cummulated dirty pages to the disk immediately might delay the request which caused the disk to spin up, so it's better to wait couple of seconds until there is chance that small high-priority requests have been serviced. Also, it might take couple of seconds to spin up the disk. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:14, 4 September 2016 (UTC)<br />
<br />
== suspend to hibernate require fix ==<br />
<br />
Rather than overriding the <code>suspend.target</code>, I think we should just add <code>RequiredBy=suspend.target</code> in the <code>[Install]</code> section of the service. It works for me, and I think this is cleaner. Can anyone else confirm that this works?<br />
--[[User:Svvac|Svvac]] ([[User talk:Svvac|talk]]) 14:16, 28 May 2017 (UTC)<br />
<br />
== network interfaces: udev rule does not work ==<br />
<br />
At least a few other wiki pages point to this rule for how an example of how to turn off power management, because power mananagement breaks some current cards using the iwlwifi driver. Unfortunately the given udev rule does not work due to persistent device names. There is a note here about persistent device names, but it is really confusing. It stresses the importance of the number in the file name, but then states that it actually wont work anyway and to use the persistent name instead of the wildcard?? However even that won't work because the udev rule above has ACTION="add". At least in my case, that ACTION clause causes the rule to only trigger for the original device name (wlan0), and not the persistent name (wlp5s0). So if I use wlan0 everywhere, it triggers but has no effect. If I use wlp5s0 everywhere it never triggers. One solution is to remove the ACTION="add" clause and use the persistent name everywhere. Another solution is to continue using a wildcard in KERNEL, such as KERNEL="wl*", and then use the persistent name instead of %k in the RUN command. I chose the second solution and my full udev rule was this:<br />
<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev wlp5s0 set power_save off"<br />
<br />
Note that I also tried using 99 instead of 70 for the filename with the original udev rule, but that did not work. [[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 23:10, 5 August 2017 (UTC)<br />
<br />
:What the note tries to say is that you can't "use wlan0" everywhere as you did. In any case, the command is run ''after'' the interface gets a persistent name, so you need to run {{ic|iw dev wlp5s0 set power_save off}} (or, as the note says, {{ic|iw dev $name set power_save off}} to make it generic). As for the matching, {{ic|KERNEL}} is the "old name" and {{ic|NAME}} is the "new name", which is assigned in {{ic|80-net-setup-link.rules}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:57, 6 August 2017 (UTC)<br />
<br />
::Ok. In a way it's nice to have so much detail about how udev manages the initial and persistent names. But the way this is currently written is still very confusing. Thanks to $name, it sounds like we could just change the given udev rule to:<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"<br />
::with a note about how some people will need to use "eth*" instead of "wl*", or off instead of on. Then the whole section about persistent names is unnecessary extra info, and could either be ommitted or clarified and kept as an informational side note.[[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 02:22, 7 August 2017 (UTC)<br />
<br />
:::Note that there are people who [[Network_configuration#Revert_to_traditional_device_names|don't use the persistent names]] at all. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 7 August 2017 (UTC)<br />
<br />
== RTC drift bug in suspend-to-hibernate script ==<br />
<br />
For some time now I have been trying to figure out an issue with my laptop that seems to happen when I use the suspend-to-hibernate script: the laptop would immediately wake up after hibernating.<br />
<br />
I took some more time to investigate today, and I think (unfortunately not confirmed 100% yet - the issue was fairly rare) that there is a race in the script that causes the RTC to immediately wake up the computer after it gets suspended. Specifically, the RTC is reset after the hibernate has started, so it is possible that the reset does not happen before the computer hibernates.<br />
<br />
Further, the source for the current time is the command {{ic|date}}, whereas the RTC's idea of time might be a little different. I confirmed this by outputting {{ic|/sys/class/rtc/rtc0/since_epoch}} at the same time as {{ic|date +%s}} and saw delays as large as 4 seconds, but I suppose it could also get larger.<br />
<br />
Combining the RTC drift and the fact that the RTC wakealarm reset happens after the hibernate has started, it is possible for the computer to immediately wake up from hibernation right after it hibernates if that happens quickly enough. This was especially noticeable in my case as it would then wait for me to enter my encryption password and drain my battery, overheating the CPU and the insides of my backpack.<br />
<br />
I have two proposed changes to the script to make it better, but I suppose either one would fix the issue:<br />
<br />
# Use {{ic|/sys/class/rtc/rtc0/since_epoch}} as a base for the wakeup time, rather than {{ic|date}};<br />
# Reset the RTC wakealarm before hibernating (right after reading it would be ideal).<br />
<br />
<br />
I will keep investigating to see if I don't get the issue anymore (as I said, it was fairly rare and thus hard to confirm that it has definitely stopped happening), but if I don't see it in the next week, I'll submit an edit to the wiki.<br />
<br />
--[[User:Cynary|Cynary]] ([[User talk:Cynary|talk]]) 09:16, 20 February 2018 (UTC)<br />
<br />
== Userspace tools ==<br />
<br />
[[Power management#Userspace tools]] now provides a list of graphical power managers and statistics tools as well as laptop power managers for the commandline. The recommendation to use only one of the listed tools because they conflict doesn't really fit anymore, how should that be changed? <br />
-- [[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 12:42, 20 June 2018 (UTC)<br />
<br />
:It could be changed to something like this: ''Be aware that using some of these tools in combination can result in unexpected behavior, such as double suspends. Please consult the documentation of the tool in question to see if there are any possible conflicts.''<br />
:-- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 16:12, 20 June 2018 (UTC)<br />
<br />
::That sounds good. I looked a bit closer and most (all?) of the GUI tools do not have anything to do with power saving, they only monitor and sometimes react to low battery charge states. Maybe it would be better to split the list between power saving and power monitoring instead of GUI/Console? acpid and powertop do both, though.<br />
::[[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 18:37, 22 June 2018 (UTC)<br />
<br />
:::Most GUI tools are not just monitors, e.g. MATE Power Manager can be used to turn off the screen and suspend the system after specified time, which definitely saves the power. On the other hand, most console tools are more advanced solutions, allowing more detailed power tweaks.<br />
:::--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 22:02, 22 June 2018 (UTC)<br />
<br />
::::Oh right, I somehow missed backlight and sleep management.<br />
::::[[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 08:43, 23 June 2018 (UTC)<br />
<br />
== <s>Mentioning power-profiles-daemon</s> ==<br />
<br />
''[Moved to [[Talk:CPU frequency scaling#Mentioning power-profiles-daemon]]. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 00:08, 30 November 2021 (UTC)]''<br />
<br />
== Add tool to userspace tools ==<br />
<br />
Add [https://github.com/AdnanHodzic/auto-cpufreq auto-cpufreq] to [[Power_management#Console]] [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 13:01, 16 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Power_management&diff=706063Talk:Power management2021-12-16T13:01:29Z<p>RaZorr: /* Add tool to userspace tools */ new section</p>
<hr />
<div>== Suspend/resume service files ==<br />
<br />
I have the slight suspicion that the service files posted in the section [[Power Management#Suspend/resume service files]] might not work. Has anybody tried them or is actually using them? <br><br />
-- [[User:Jakobh|jakobh]] [[User talk:Jakobh|✉]] 03:12, 10 May 2013 (UTC)<br />
<br />
: (Mod: the section was moved from [[systemd]] into [[Power Management]], so I moved this post too, fixed link along the way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:24, 21 August 2013 (UTC))<br />
<br />
== Sleep hooks ==<br />
<br />
Where is the exact difference between '''Suspend/resume service files''' approach and '''Hooks in /usr/lib/systemd/system-sleep'''?<br />
<br />
Is the latter obsolete?<br />
<br />
-- [[User:Orschiro|Orschiro]] 07:33, 17 January 2014<br />
<br />
:From {{ic|systemd-sleep(8)}}:<br />
::"Note that scripts or binaries dropped in {{ic|/usr/lib/systemd/system-sleep/}} are intended for local use only and should be considered hacks."<br />
:It's always preferred to use service files, they are much more flexible in handling the dependencies etc.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 23:52, 31 January 2014 (UTC)<br />
<br />
== Delayed hibernation service ==<br />
<br />
I have found that the service file given in this section does not work. My laptop hibernates immediately after resuming from suspend. I have also found that the older version of this service found in the forum post does indeed work perfectly. Does anyone know why this is?<br />
[[User:Aouellette|Aouellette]] ([[User talk:Aouellette|talk]]) 16:16, 30 May 2015 (UTC)<br />
<br />
== Resume file does not work after resuming from hibernation ==<br />
<br />
The systemd unit {{ic|User resume actions}} presented on this page only worked for me after resuming from sleep, not from hibernate. <br />
After adding {{ic|hibernate.target}} to the {{ic|After}} and {{ic|WantedBy}} lines it works both ways.<br />
However this is the first time I've done anything with such service files so I ain't sure if this is the optimal way.<br />
Can anyone confirm?<br />
<br />
{{unsigned|18:30, 12 October 2015|PhilippD}}<br />
<br />
:Actually, the {{ic|suspend@.service}} in [[Power_management#Suspend.2Fresume_service_files]] binds to {{ic|sleep.target}}, but {{ic|resume@.service}} binds to {{ic|suspend.target}}. They are not synonyms, systemd triggers {{ic|suspend.target}} and {{ic|sleep.target}} when the system is suspended to RAM, and {{ic|hibernate.target}} and {{ic|sleep.target}} when it is suspended to disk. This way you can bind your service to either one or both suspend methods using just a single target. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:17, 12 October 2015 (UTC)<br />
<br />
== Bluetooth rfkill ==<br />
<br />
Systemd now provides {{ic|systemd-rfkill.service}}. If you use {{ic|rfkill block}} to disable bluetooth, {{ic|systemd-rfkill.service}} will remember this and restore this state on next boot -- [[User:robtaylor|robtaylor]] ([[User talk:robtaylor|talk]]) Wed 18 May 16:10:05 BST 2016<br />
<br />
== A "sensible value" for the laptop mode ==<br />
<br />
The vast amount of specific information carried in this part, I find it a bit surprising. It seems "A sensible value for the laptop mode 'knob' is 5 seconds." could be heard in the mouth of a politician kicking the ball into touch.<br />
<br />
From Documentation/laptops/laptop-mode.txt:<br />
<br />
> The value of the laptop_mode knob determines the time between the occurrence of disk I/O <br />
and when the flush is triggered. A sensible value for the knob is 5 seconds. Setting the knob<br />
to 0 disables laptop mode.<br />
<br />
So "5 (seconds)" is related to the virtual memory subsystem (in direct relation to ''vm.dirty_writeback_centisecs''). Then "0" turns laptop mode off, aha. It'd be cool to know *what* is laptop_mode is in the first place: Is it the whole vm configuration settings that are described in the docs? I believe not, as e.g. the conf files are not to be seen in present Arch (nor in other distros I know of).<br />
<br />
A few things changed a bit since the Documentation/laptops/laptop-mode.txt was last edited, in 2004. I've searched extensively which part of it might still be up to date, without success so far. ''TLP'' has many if not most of the settings the doc explains. And so looks as an evolution of ''laptop_mode''. Would a guru or someone with knowledge about that be kind enough to specify the effect of ''vm.laptop_mode''? [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:33, 1 September 2016 (UTC)<br />
<br />
:The effect of the {{ic|vm.laptop_mode}} is described in the kernel docs in "The Details" section. The scripts that the docs talk about are probably [[Laptop Mode Tools]] nowadays. They are needed only to switch settings based on the current power source (and as a "bonus" they integrate most of the things in the [[Power_management#Power_saving]] section), but I bet the kernel settings are mostly the same as in 2004. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:41, 2 September 2016 (UTC)<br />
<br />
:: I now see that, thank you Lahwaacz. Now as we may increase flush time to disk (to, say, ten minutes) via {{ic|vm.dirty_writeback_centisecs}}, delaying the flush up to five seconds via the {{ic|vm.laptop_mode}} knob doesn't make much sense regarding the ''disk'' power-savings... But it may help the ''cpu'' staying idle longer. Hence, whether set via [[laptop-mode-tools]], [[tlp]] or proper self-made [[udev]] rules. I.e. {{ic|vm.laptop_mode}} and {{ic|vm.dirty_*}} together help delaying and grouping system's activity ''as a whole'', allowing for longer power-saving efficient idle times. Please correct me if I'm wrong. [[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 19:37, 4 September 2016 (UTC)<br />
<br />
::: True, but the delay via {{ic|vm.laptop_mode}} makes sense also for other reasons. Let's say {{ic|vm.dirty_writeback_centisecs}} is set to something like 10 minutes and the disk is spun down due to inactivity and stays like that for e.g. 8 minutes, when it spins up due to user activity. Flushing all the cummulated dirty pages to the disk immediately might delay the request which caused the disk to spin up, so it's better to wait couple of seconds until there is chance that small high-priority requests have been serviced. Also, it might take couple of seconds to spin up the disk. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:14, 4 September 2016 (UTC)<br />
<br />
== suspend to hibernate require fix ==<br />
<br />
Rather than overriding the <code>suspend.target</code>, I think we should just add <code>RequiredBy=suspend.target</code> in the <code>[Install]</code> section of the service. It works for me, and I think this is cleaner. Can anyone else confirm that this works?<br />
--[[User:Svvac|Svvac]] ([[User talk:Svvac|talk]]) 14:16, 28 May 2017 (UTC)<br />
<br />
== network interfaces: udev rule does not work ==<br />
<br />
At least a few other wiki pages point to this rule for how an example of how to turn off power management, because power mananagement breaks some current cards using the iwlwifi driver. Unfortunately the given udev rule does not work due to persistent device names. There is a note here about persistent device names, but it is really confusing. It stresses the importance of the number in the file name, but then states that it actually wont work anyway and to use the persistent name instead of the wildcard?? However even that won't work because the udev rule above has ACTION="add". At least in my case, that ACTION clause causes the rule to only trigger for the original device name (wlan0), and not the persistent name (wlp5s0). So if I use wlan0 everywhere, it triggers but has no effect. If I use wlp5s0 everywhere it never triggers. One solution is to remove the ACTION="add" clause and use the persistent name everywhere. Another solution is to continue using a wildcard in KERNEL, such as KERNEL="wl*", and then use the persistent name instead of %k in the RUN command. I chose the second solution and my full udev rule was this:<br />
<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev wlp5s0 set power_save off"<br />
<br />
Note that I also tried using 99 instead of 70 for the filename with the original udev rule, but that did not work. [[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 23:10, 5 August 2017 (UTC)<br />
<br />
:What the note tries to say is that you can't "use wlan0" everywhere as you did. In any case, the command is run ''after'' the interface gets a persistent name, so you need to run {{ic|iw dev wlp5s0 set power_save off}} (or, as the note says, {{ic|iw dev $name set power_save off}} to make it generic). As for the matching, {{ic|KERNEL}} is the "old name" and {{ic|NAME}} is the "new name", which is assigned in {{ic|80-net-setup-link.rules}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:57, 6 August 2017 (UTC)<br />
<br />
::Ok. In a way it's nice to have so much detail about how udev manages the initial and persistent names. But the way this is currently written is still very confusing. Thanks to $name, it sounds like we could just change the given udev rule to:<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"<br />
::with a note about how some people will need to use "eth*" instead of "wl*", or off instead of on. Then the whole section about persistent names is unnecessary extra info, and could either be ommitted or clarified and kept as an informational side note.[[User:Lllars|Lllars]] ([[User talk:Lllars|talk]]) 02:22, 7 August 2017 (UTC)<br />
<br />
:::Note that there are people who [[Network_configuration#Revert_to_traditional_device_names|don't use the persistent names]] at all. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:17, 7 August 2017 (UTC)<br />
<br />
== RTC drift bug in suspend-to-hibernate script ==<br />
<br />
For some time now I have been trying to figure out an issue with my laptop that seems to happen when I use the suspend-to-hibernate script: the laptop would immediately wake up after hibernating.<br />
<br />
I took some more time to investigate today, and I think (unfortunately not confirmed 100% yet - the issue was fairly rare) that there is a race in the script that causes the RTC to immediately wake up the computer after it gets suspended. Specifically, the RTC is reset after the hibernate has started, so it is possible that the reset does not happen before the computer hibernates.<br />
<br />
Further, the source for the current time is the command {{ic|date}}, whereas the RTC's idea of time might be a little different. I confirmed this by outputting {{ic|/sys/class/rtc/rtc0/since_epoch}} at the same time as {{ic|date +%s}} and saw delays as large as 4 seconds, but I suppose it could also get larger.<br />
<br />
Combining the RTC drift and the fact that the RTC wakealarm reset happens after the hibernate has started, it is possible for the computer to immediately wake up from hibernation right after it hibernates if that happens quickly enough. This was especially noticeable in my case as it would then wait for me to enter my encryption password and drain my battery, overheating the CPU and the insides of my backpack.<br />
<br />
I have two proposed changes to the script to make it better, but I suppose either one would fix the issue:<br />
<br />
# Use {{ic|/sys/class/rtc/rtc0/since_epoch}} as a base for the wakeup time, rather than {{ic|date}};<br />
# Reset the RTC wakealarm before hibernating (right after reading it would be ideal).<br />
<br />
<br />
I will keep investigating to see if I don't get the issue anymore (as I said, it was fairly rare and thus hard to confirm that it has definitely stopped happening), but if I don't see it in the next week, I'll submit an edit to the wiki.<br />
<br />
--[[User:Cynary|Cynary]] ([[User talk:Cynary|talk]]) 09:16, 20 February 2018 (UTC)<br />
<br />
== Userspace tools ==<br />
<br />
[[Power management#Userspace tools]] now provides a list of graphical power managers and statistics tools as well as laptop power managers for the commandline. The recommendation to use only one of the listed tools because they conflict doesn't really fit anymore, how should that be changed? <br />
-- [[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 12:42, 20 June 2018 (UTC)<br />
<br />
:It could be changed to something like this: ''Be aware that using some of these tools in combination can result in unexpected behavior, such as double suspends. Please consult the documentation of the tool in question to see if there are any possible conflicts.''<br />
:-- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 16:12, 20 June 2018 (UTC)<br />
<br />
::That sounds good. I looked a bit closer and most (all?) of the GUI tools do not have anything to do with power saving, they only monitor and sometimes react to low battery charge states. Maybe it would be better to split the list between power saving and power monitoring instead of GUI/Console? acpid and powertop do both, though.<br />
::[[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 18:37, 22 June 2018 (UTC)<br />
<br />
:::Most GUI tools are not just monitors, e.g. MATE Power Manager can be used to turn off the screen and suspend the system after specified time, which definitely saves the power. On the other hand, most console tools are more advanced solutions, allowing more detailed power tweaks.<br />
:::--[[User:City-busz|City-busz]] ([[User talk:City-busz|talk]]) 22:02, 22 June 2018 (UTC)<br />
<br />
::::Oh right, I somehow missed backlight and sleep management.<br />
::::[[User:Progandy|Progandy]] ([[User talk:Progandy|talk]]) 08:43, 23 June 2018 (UTC)<br />
<br />
== <s>Mentioning power-profiles-daemon</s> ==<br />
<br />
''[Moved to [[Talk:CPU frequency scaling#Mentioning power-profiles-daemon]]. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 00:08, 30 November 2021 (UTC)]''<br />
<br />
== Add tool to userspace tools ==<br />
<br />
Add [https://github.com/AdnanHodzic/auto-cpufreq auto-cpufreq] to [[Power_management#Console]]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Xorg&diff=706055Talk:Xorg2021-12-16T11:47:14Z<p>RaZorr: reply to Lahwaaz and forum topic</p>
<hr />
<div>== Setting DPI manually ==<br />
<br />
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.<br />
<br />
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.<br />
<br />
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 05:25, 10 December 2013 (UTC)<br />
<br />
:As you probably noticed, [[Xorg#Display_size_and_DPI]] is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that {{Pkg|xorg-server}} uses several patches (see [https://github.com/archlinux/svntogit-packages/blob/packages/xorg-server/trunk]). I don't know which patches other distros use, but this option is not likely to depend on the patches.<br />
:Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:34, 10 December 2013 (UTC)<br />
<br />
::As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to [https://bugs.kde.org/show_bug.cgi?id=317929#c13 Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems]. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.<br />
<br />
::"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]])<br />
<br />
:::I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is ''not'' automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. {{unsigned|20:17, 5 June 2015|Silverhammermba}}<br />
<br />
::::Having fought this problem with a gen4 Intel laptop---1280x800@14.1in LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. [[User:Vorbote|Vorbote]] ([[User talk:Vorbote|talk]]) 14:17, 7 October 2015 (UTC)<br />
<br />
:::::I did some experiments in my Radeon HD6310 and discover somethings... lets start:<br />
:::::* efectively, set the dpi in the xorg file is meaningless, as is ignored<br />
:::::* set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.<br />
:::::My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/ <br />
:::::{{unsigned|05:40, 19 April 2016 (UTC)|Jristz}}<br />
<br />
::::::'''If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings.''' In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX ''after'' xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. [[User:Dc46and2|Dc46and2]] ([[User talk:Dc46and2|talk]]) 02:34, 9 June 2016 (UTC)<br />
<br />
:::::::In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system"] on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 06:45, 1 February 2017 (UTC)<br />
<br />
:::::: Regarding the Xorg xft.dpi issue, the ticket is now moved to Gitlab: [https://gitlab.freedesktop.org/xorg/xserver/issues/509 See Xserver issue 509].<br />
:::::: [[User:Danger89|Danger89]] ([[User talk:Danger89|talk]]) 15:04, 15 March 2019 (UTC)<br />
<br />
== Add xhost si:localuser:$USER ? ==<br />
<br />
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see [https://bbs.archlinux.org/viewtopic.php?id=202704 BBS#202704], [[Connman#Avoid_changing_the_hostname]]), things stop working. The user name is (or should be) less prone to change, so you could use {{Pkg|xorg-xhost}} for access:<br />
<br />
$ xhost si:localuser:$USER<br />
<br />
man Xsecurity says on this:<br />
<br />
localuser & localgroup<br />
On systems which can determine in a secure fashion the credentials of a client process,<br />
the "localuser" and "localgroup" authentication methods provide access based on those<br />
credentials. The format of the values provided is platform specific. For POSIX & UNIX<br />
platforms, if the value starts with the character '#', the rest of the string is treated<br />
as a decimal uid or gid, otherwise the string is defined as a user name or group name.<br />
<br />
If your system supports this method and you use it, be warned that some programs that<br />
proxy connections and are setuid or setgid may get authenticated as the uid or gid of<br />
the proxy process. For instance, some versions of ssh will be authenticated as the user<br />
root, no matter what user is running the ssh client, so on systems with such software,<br />
adding access for localuser:root may allow wider access than intended to the X display.<br />
<br />
However, X apps failing is the symptom; the cause lies in [[Network configuration]], or an issue with the (static) [[hostname]] not being respected. So I'm not sure where to mention this, if at all. One way would be to expand [[Xhost]] and add a link there under [[Xorg#Troubleshooting]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:51, 21 September 2015 (UTC)<br />
<br />
: For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.<br />
<br />
: As for where this should go? I have no idea. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 23:54, 13 March 2016 (UTC)<br />
<br />
== Location of Xorg.0.log ==<br />
<br />
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:<br />
<br />
/var/log/Xorg.0.log<br />
<br />
and <br />
~/.local/share/xorg/Xorg.0.log<br />
<br />
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by [[User:Slacka]], 20170112<br />
<br />
seconded <br />
/var/log/Xorg.0.log<br />
needs to be specified, im running i3wm<br />
--[[User:Yair|Yair]] ([[User talk:Yair|talk]]) 17:21, 20 April 2018 (UTC)<br />
<br />
== Rootless Xorg ==<br />
<br />
Reverted edit by Alad: "useless without reference, i.e. a bug report "<br />
And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design?<br />
[[User:Aufkrawall|Aufkrawall]] ([[User talk:Aufkrawall|talk]]) 16:14, 6 November 2017 (UTC)<br />
<br />
:That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 6 November 2017 (UTC)<br />
<br />
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use {{ic|startx}} instead of {{ic|exec startx}}, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested [https://bbs.archlinux.org/viewtopic.php?pid=1973717#p1973717/ here] that this section should be edited/moved. [[User:Garfa|Garfa]] ([[User talk:Garfa|talk]]) 17:01, 22 May 2021 (UTC)<br />
<br />
== Remove/replace/update the xorg.conf config section? ==<br />
<br />
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section.<br />
In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility.<br />
It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.<br />
<br />
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly.<br />
Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)<br />
<br />
{{unsigned|07:30, 2 April 2018|Seth}}<br />
<br />
== Best place for eGPU configs ==<br />
<br />
Greetings,<br />
I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.<br />
<br />
To get eGPU working with external monitor and internal one disabled:<br />
* Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)<br />
* Use something like the following for the Xorg config:<br />
Section "Module"<br />
Load "modesetting"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia"<br />
Driver "nvidia"<br />
BusID "PCI:6:0:0"<br />
Option "AllowEmptyInitialConfiguration"<br />
Option "AllowExternalGpus"<br />
EndSection<br />
<br />
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io.<br />
First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests. <br />
<br />
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.<br />
<br />
Whats the best place to add this information? <br />
I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"<br />
<br />
[[User:Snugghash|Snugghash]] ([[User talk:Snugghash|talk]]) 22:59, 10 August 2018 (UTC)<br />
<br />
:Since it is specific to the NVIDIA driver, add it to [[NVIDIA/Tips_and_tricks]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:41, 11 August 2018 (UTC)<br />
<br />
== systemctl --user in rootless Xorg ==<br />
<br />
To get {{ic|systemctl --user}} to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit {{ic|/etc/pam.d/system-login}} so that {{ic|pam_systemd.so}} is required (that is remove the {{ic|-}} in front of {{ic|session}} and change {{ic|optional}} to {{ic|required}}). I am not sure why this isn't the default somehow. -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 19:28, 6 November 2018 (UTC)<br />
<br />
:''to get'' {{ic|systemctl --user}} ''to work''<br />
:not sure what you mean by that but i use ''--user'' for cron like jobs without changing {{ic|/etc/pam.d/system-login}} --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:07, 7 November 2018 (UTC)<br />
<br />
::I just meant any command using {{ic|systemctl --user}}.<br />
::My comment was specific to rootless Xorg, but was edited out of its context, are you using rootless Xorg? -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 17:48, 10 November 2018 (UTC)<br />
<br />
:::yes ---[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 11 November 2018 (UTC)<br />
<br />
== XWayland ==<br />
<br />
As discussed in [[Talk:Wayland#XWayland]], I would like to add a small section for XWayland.<br />
<br />
Technically it is a part of the XServer, so where would you like it better, here or at [[Wayland]]?<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:45, 17 October 2020 (UTC) G3ro<br />
<br />
== <s>Information about xf86-video-intel</s> ==<br />
<br />
Maybe mention [https://wiki.archlinux.org/title/Intel_graphics#Installation Intel graphics installation] '''note''' near '''xf86-video-intel''' in [https://wiki.archlinux.org/title/Xorg#Driver_installation Xorg#driver_installation] section. From [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] {{Unsigned|07:33, 8 December 2021 (UTC)|RaZorr}}<br />
<br />
:There is already a link to [[Intel graphics#Installation]] in the note below the table. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:34, 8 December 2021 (UTC)<br />
:But I think it can be made more obvious. As of now, user may not find any reason to visit the [[Intel graphics#Installation]] documentation. Also, could you look at [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic] ? [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 11:47, 16 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:PipeWire&diff=704810Talk:PipeWire2021-12-08T07:54:09Z<p>RaZorr: adding pipewire wiki info alongwith archwiki info</p>
<hr />
<div>== 0.3.16 pulse replacement ==<br />
<br />
For the pulse-dropin-replacement to work, you probably also need to clear your users config, {{ic|~/.config/pulse}} (like in delete/move the content) - That is created by pulseaudio for pulseaudio.<br />
Otherwise the server could be unable to start.<br />
<br />
[[User:Fabis.cafe|Fabis.cafe]] ([[User talk:Fabis.cafe|talk]]) 14:12, 23 November 2020 (UTC)<br />
<br />
----<br />
<br />
I just installed the pulse replacement and while everything seems to be working just fine, the only problem is gnome-shell doesn't seem to be able to see the pipewrire pulse server, thus the volume control in the top right system menu is absent and keyboard media keys for volume don't work either. I think this should be addressed in the troubleshooting section with a solution if there is one.<br />
<br />
Interestingly enough gnome-control-center is able to control the volume as well as other typical pulseaudio parameters.<br />
<br />
UPDATE: running {{ic|killall pipewire-pulse; killall pipewire}} restarts the pipewire pulse daemon and makes the volume control in gnome-shell work as expected. This of course is a workaround and not a proper solution.<br />
<br />
UPDATE 2: the above makes the volume control menu item and shortcuts appear, but adjusting the volume does nothing.<br />
<br />
[[User:GabMus|GabMus]] ([[User talk:GabMus|talk]]) 09:39, 3 December 2020 (UTC)<br />
<br />
:I don't see volume indicator in gnome-shell/wayland but I'm able to control volume with media keys. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 15:55, 3 December 2020 (UTC)<br />
<br />
:: Possibly related: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/426 [[User:Hexchain|Hexchain]] ([[User talk:Hexchain|talk]]) 18:05, 3 December 2020 (UTC)<br />
<br />
: Solved, refer to the latest change I made in the main page, found the solution thanks to Hexchain's link. -- [[User:GabMus|GabMus]] ([[User talk:GabMus|talk]]) 19:55, 4 December 2020 (UTC)<br />
<br />
== aptX support ==<br />
Does `pipewire` support low latency/high quality bluetooth codecs (aptX, LDAC, ...) ? <br />
along the lines of https://aur.archlinux.org/packages/pulseaudio-modules-bt-git/ <br />
If yes, how to configure it? <br />
along the lines of https://freedesktop.org/software/pulseaudio/pavucontrol/ <br />
[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 21:23, 3 December 2020 (UTC)<br />
<br />
: I switched to PipeWire and currently bluetooth sound poorly works: high latency and low quality.<br />
: Actually open bug/enhancement in pipewire bugtracker [https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/136].<br />
: [[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 10:20, 5 December 2020 (UTC)<br />
<br />
: It does now but currently there is no way to select a codec manually. It uses (the first supported?) codec in this order: LDAC, AptX HD, AptX, SBC. You can check for the current codec with {{ic|pactl list sinks}} IIRC.<br />
: [[User:Hexchain|Hexchain]] ([[User talk:Hexchain|talk]]) 00:41, 21 December 2020 (UTC)<br />
<br />
:: In the meantime, pipewire gets updated with support of the above mentioned feature; at the same time GNOME's sound setting allows to select (supported) codec<br />
:: [[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 06:31, 1 May 2021 (UTC)<br />
<br />
== Better introduction? ==<br />
<br />
Right now I think the description is missing some content to exactly explain what pipewire is and what it can be used for.<br />
The website names some important examples imho:<br />
<br />
* Capture and playback of audio and video with minimal latency.<br />
* Real-time Multimedia processing on audio and video.<br />
* Multiprocess architecture to let applications share multimedia content.<br />
* Seamless support for PulseAudio, JACK, ALSA and GStreamer applications.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:21, 28 February 2021 (UTC)<br />
<br />
: I fully agree! TBH I don't see an urgent need for a discussion on this topic. Feel free to amend the page with whatever you think is right. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 19:30, 3 March 2021 (UTC)<br />
<br />
:: Ok, I have added some parts. Someone with better knowledge on this topic might edit it further.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:26, 5 March 2021 (UTC)<br />
<br />
== Move section "webrtc screen sharing" below other sections in "Usage" ==<br />
<br />
I think that the "Audio" and "Video" sections are more important and more general, so they should be placed first.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:23, 28 February 2021 (UTC)<br />
<br />
: IMHO the ordering is just fine as of now. Pipewire is completely optional for handling audio and video. However, for screensharing under wayland you must use it. I strongly believe that this section is of most interest to the average user. Note, I am fine though with whatever reaches a consensus. I do not feel too strongly about the ordering of these sections. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 19:28, 3 March 2021 (UTC)<br />
<br />
:: For now I would be ok with the ordering, but afaik Pipewire is aimed to become some kind of "replacement" for pulseaudio etc., so the other parts will become more important in the future.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 5 March 2021 (UTC)<br />
<br />
== 0.3.23 no pcm devices found ==<br />
<br />
Thanks [[User:NTia89|nTia89]] for reverting my change. pipewire-alsa isn't needed, I checked contents of the package, it definitely can't help.<br />
<br />
Spent 5h on pipewire, it did not find any sound-card. The moment I installed pipewire-alsa it started working. I used <code>pw-cli ls | grep -i pcm</code> to find pcm devices. I didn't change any config the whole time, because the wiki-page says it should work out of the box. I rebooted a lot. I hoped I could help that other users don't have to spend 5h on this. pipewire seems very nice. So here is what I did in the end.<br />
<br />
* install <code>pipewire pipewire-media-session pipewire-alsa pipewire-jack pipewire-pulse pipewire-jack-dropin</code> (ignore jack if you don't have jack-applications)<br />
* remove <code>pulseaudio</code><br />
* <code>systemctl --user enable pipewire.socket pipewire-pulse.service pipewire-media-session.service</code><br />
* <code>systemctl --user restart pipewire.service pipewire-pulse.service pipewire-media-session.service</code><br />
<br />
I try to find out what exactly my mistake was.<br />
<br />
[[User:Streampunk|Streampunk]] ([[User talk:Streampunk|talk]]) 14:59, 22 March 2021 (UTC)<br />
<br />
== Native pulse clients can't connect ==<br />
<br />
{{ic|pipewire-pulse-dropin}} (AUR) has existed until Nov 2020. If still installed, it shadows and conflicts the socket {{ic|/run/user/*/pulse/native}} which is now already provided by {{ic|pipewire-pulse.service}}. Delete that orphaned package to solve this issue. [[User:Sausix|Sausix]] ([[User talk:Sausix|talk]]) 15:10, 30 March 2021 (UTC)<br />
<br />
== Configuration section ==<br />
<br />
I think we have to mention the official wiki page: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Configuration#set-global-sample-rate<br />
because it is a complete and always up-to-date resource.<br />
<br />
<br />
I think we should add a Configuration section; a sort of:<br />
<br />
`PipeWire is a powerful tool having a plethora of options. We recommend to read the official wiki page[1] in order to have a complete sight of all possibilities. Although most users are happy with default settings, particular configuration cases are reported in the Pipewire/Examples page. On the other hand, most common issues and their solutions are reported below in the Troubleshooting section.`<br />
<br />
What do you think?<br />
<br />
<br />
[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 10:16, 27 March 2021 (UTC)<br />
<br />
: I fully agree with you about mentioning the official wiki page. However, I think it is fine to recap some of the most important configuration options in the ArchWiki too! At least to me the current phrasing of the paragraph suggests that we solely refer to the official wiki page for that. -- [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 11:03, 27 March 2021 (UTC)<br />
<br />
: Maybe add info about [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home Pipewire wiki] in a new Configuration section and below that add " ''Configurations for some of the most common usecases are provided in the following [usage] sections.'' " [[User:RaZorr|RaZorr]] ([[User talk:RaZorr|talk]]) 07:54, 8 December 2021 (UTC) .<br />
<br />
== video production ready? ==<br />
<br />
The video section currently claims that:<br />
<br />
> Although the software [video in PipeWire] is '''not yet production-ready''', it is safe to play around with.<br />
<br />
(emphasis mine). What's the source for the claim? The [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet PipeWire (PW) FAQ] basically says "It [PW] is ready for broader use", so I wonder where that dissonance comes from. --[[User:Anarcat|Anarcat]] ([[User talk:Anarcat|talk]]) 18:45, 6 May 2021 (UTC)<br />
<br />
== Elaborate on the expectations/requirements of the jack/jack2 removal option ==<br />
<br />
The page currently suggests removing jack/jack2 from your system as an alternative to running through `pw-jack` or installing {{AUR|pipewire-jack-dropin}} to have the system use PipeWire for JACK but this is most likely blocked by a lot of software unless you've installed said software on your system without involving `pacman` and thus not having the transaction blocked, or you would need to force the removal (and IgnorePkg it to prevent it from returning) or maybe NoExtract jack's *.so files? <br />
The way it is suggested makes it sound like it should be a very easy `pacman -Rns jack/jack2` which it more than likely will not be. <br />
<br />
Examples of programs that would block a simple/normal removal as suggested are blender and ffmpeg looking for 'jack', or things like qemu and fluidsynth looking for 'libjack.so=0-64'. <br />
<br />
Maybe this section should have a note about that or maybe it's better to remove that whole suggestion as an option?<br />
<br />
{{unsigned|15:36, 10 June 2021|Omar007}}<br />
<br />
== Screensharing not functional with wireplumber? ==<br />
<br />
It looks to me that wireplumber, while mentioned as more powerful in the wiki page, does not allow screen sharing at least with sway. Replacing it with pipewire-media-session fixes the issue. xdg-desktop-portal[-wlr] and wireplumber bugtrackers and docs do not mention anything about it.<br />
<br />
Does anyone have a different experience or should we mention it in the wiki?<br />
<br />
EDIT: it looks like it's fixed as of xdg-desktop-portal-wlr v0.5.0<br />
<br />
--[[User:Njoyard|Njoyard]] ([[User talk:Njoyard|talk]]) 20:56, 26 October 2021 (UTC)<br />
<br />
== <s>Should it be mentioned that the Pipewire maintainers recommend wireplumber?</s> ==<br />
<br />
Copied from the readme on [https://gitlab.freedesktop.org/pipewire/media-session pipewire/media-session gitlab]:<br />
<br />
Note that we recommend the use of WirePlumber instead.<br />
<br />
{{Unsigned|03:25, 4 December 2021 (UTC)|Ben781}}<br />
<br />
:I don't see why not. Implemented with [[Special:Diff/704213|Diff/704213]]; closing. -- [[User:Flyingpig|Flyingpig]] ([[User talk:Flyingpig|talk]]) 04:39, 4 December 2021 (UTC)</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Xorg&diff=704807Talk:Xorg2021-12-08T07:33:58Z<p>RaZorr: added topic link from forums</p>
<hr />
<div>== Setting DPI manually ==<br />
<br />
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.<br />
<br />
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.<br />
<br />
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 05:25, 10 December 2013 (UTC)<br />
<br />
:As you probably noticed, [[Xorg#Display_size_and_DPI]] is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that {{Pkg|xorg-server}} uses several patches (see [https://github.com/archlinux/svntogit-packages/blob/packages/xorg-server/trunk]). I don't know which patches other distros use, but this option is not likely to depend on the patches.<br />
:Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:34, 10 December 2013 (UTC)<br />
<br />
::As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to [https://bugs.kde.org/show_bug.cgi?id=317929#c13 Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems]. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.<br />
<br />
::"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]])<br />
<br />
:::I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is ''not'' automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. {{unsigned|20:17, 5 June 2015|Silverhammermba}}<br />
<br />
::::Having fought this problem with a gen4 Intel laptop---1280x800@14.1in LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. [[User:Vorbote|Vorbote]] ([[User talk:Vorbote|talk]]) 14:17, 7 October 2015 (UTC)<br />
<br />
:::::I did some experiments in my Radeon HD6310 and discover somethings... lets start:<br />
:::::* efectively, set the dpi in the xorg file is meaningless, as is ignored<br />
:::::* set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.<br />
:::::My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/ <br />
:::::{{unsigned|05:40, 19 April 2016 (UTC)|Jristz}}<br />
<br />
::::::'''If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings.''' In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX ''after'' xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. [[User:Dc46and2|Dc46and2]] ([[User talk:Dc46and2|talk]]) 02:34, 9 June 2016 (UTC)<br />
<br />
:::::::In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system"] on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 06:45, 1 February 2017 (UTC)<br />
<br />
:::::: Regarding the Xorg xft.dpi issue, the ticket is now moved to Gitlab: [https://gitlab.freedesktop.org/xorg/xserver/issues/509 See Xserver issue 509].<br />
:::::: [[User:Danger89|Danger89]] ([[User talk:Danger89|talk]]) 15:04, 15 March 2019 (UTC)<br />
<br />
== Add xhost si:localuser:$USER ? ==<br />
<br />
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see [https://bbs.archlinux.org/viewtopic.php?id=202704 BBS#202704], [[Connman#Avoid_changing_the_hostname]]), things stop working. The user name is (or should be) less prone to change, so you could use {{Pkg|xorg-xhost}} for access:<br />
<br />
$ xhost si:localuser:$USER<br />
<br />
man Xsecurity says on this:<br />
<br />
localuser & localgroup<br />
On systems which can determine in a secure fashion the credentials of a client process,<br />
the "localuser" and "localgroup" authentication methods provide access based on those<br />
credentials. The format of the values provided is platform specific. For POSIX & UNIX<br />
platforms, if the value starts with the character '#', the rest of the string is treated<br />
as a decimal uid or gid, otherwise the string is defined as a user name or group name.<br />
<br />
If your system supports this method and you use it, be warned that some programs that<br />
proxy connections and are setuid or setgid may get authenticated as the uid or gid of<br />
the proxy process. For instance, some versions of ssh will be authenticated as the user<br />
root, no matter what user is running the ssh client, so on systems with such software,<br />
adding access for localuser:root may allow wider access than intended to the X display.<br />
<br />
However, X apps failing is the symptom; the cause lies in [[Network configuration]], or an issue with the (static) [[hostname]] not being respected. So I'm not sure where to mention this, if at all. One way would be to expand [[Xhost]] and add a link there under [[Xorg#Troubleshooting]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:51, 21 September 2015 (UTC)<br />
<br />
: For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.<br />
<br />
: As for where this should go? I have no idea. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 23:54, 13 March 2016 (UTC)<br />
<br />
== Location of Xorg.0.log ==<br />
<br />
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:<br />
<br />
/var/log/Xorg.0.log<br />
<br />
and <br />
~/.local/share/xorg/Xorg.0.log<br />
<br />
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by [[User:Slacka]], 20170112<br />
<br />
seconded <br />
/var/log/Xorg.0.log<br />
needs to be specified, im running i3wm<br />
--[[User:Yair|Yair]] ([[User talk:Yair|talk]]) 17:21, 20 April 2018 (UTC)<br />
<br />
== Rootless Xorg ==<br />
<br />
Reverted edit by Alad: "useless without reference, i.e. a bug report "<br />
And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design?<br />
[[User:Aufkrawall|Aufkrawall]] ([[User talk:Aufkrawall|talk]]) 16:14, 6 November 2017 (UTC)<br />
<br />
:That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 6 November 2017 (UTC)<br />
<br />
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use {{ic|startx}} instead of {{ic|exec startx}}, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested [https://bbs.archlinux.org/viewtopic.php?pid=1973717#p1973717/ here] that this section should be edited/moved. [[User:Garfa|Garfa]] ([[User talk:Garfa|talk]]) 17:01, 22 May 2021 (UTC)<br />
<br />
== Remove/replace/update the xorg.conf config section? ==<br />
<br />
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section.<br />
In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility.<br />
It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.<br />
<br />
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly.<br />
Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)<br />
<br />
{{unsigned|07:30, 2 April 2018|Seth}}<br />
<br />
== Best place for eGPU configs ==<br />
<br />
Greetings,<br />
I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.<br />
<br />
To get eGPU working with external monitor and internal one disabled:<br />
* Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)<br />
* Use something like the following for the Xorg config:<br />
Section "Module"<br />
Load "modesetting"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia"<br />
Driver "nvidia"<br />
BusID "PCI:6:0:0"<br />
Option "AllowEmptyInitialConfiguration"<br />
Option "AllowExternalGpus"<br />
EndSection<br />
<br />
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io.<br />
First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests. <br />
<br />
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.<br />
<br />
Whats the best place to add this information? <br />
I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"<br />
<br />
[[User:Snugghash|Snugghash]] ([[User talk:Snugghash|talk]]) 22:59, 10 August 2018 (UTC)<br />
<br />
:Since it is specific to the NVIDIA driver, add it to [[NVIDIA/Tips_and_tricks]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:41, 11 August 2018 (UTC)<br />
<br />
== systemctl --user in rootless Xorg ==<br />
<br />
To get {{ic|systemctl --user}} to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit {{ic|/etc/pam.d/system-login}} so that {{ic|pam_systemd.so}} is required (that is remove the {{ic|-}} in front of {{ic|session}} and change {{ic|optional}} to {{ic|required}}). I am not sure why this isn't the default somehow. -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 19:28, 6 November 2018 (UTC)<br />
<br />
:''to get'' {{ic|systemctl --user}} ''to work''<br />
:not sure what you mean by that but i use ''--user'' for cron like jobs without changing {{ic|/etc/pam.d/system-login}} --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:07, 7 November 2018 (UTC)<br />
<br />
::I just meant any command using {{ic|systemctl --user}}.<br />
::My comment was specific to rootless Xorg, but was edited out of its context, are you using rootless Xorg? -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 17:48, 10 November 2018 (UTC)<br />
<br />
:::yes ---[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 11 November 2018 (UTC)<br />
<br />
== XWayland ==<br />
<br />
As discussed in [[Talk:Wayland#XWayland]], I would like to add a small section for XWayland.<br />
<br />
Technically it is a part of the XServer, so where would you like it better, here or at [[Wayland]]?<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:45, 17 October 2020 (UTC) G3ro<br />
<br />
== Information about xf86-video-intel ==<br />
<br />
Maybe mention [https://wiki.archlinux.org/title/Intel_graphics#Installation Intel graphics installation] '''note''' near '''xf86-video-intel''' in [https://wiki.archlinux.org/title/Xorg#Driver_installation Xorg#driver_installation] section. From [https://bbs.archlinux.org/viewtopic.php?id=271883 forum topic]</div>RaZorrhttps://wiki.archlinux.org/index.php?title=Talk:Xorg&diff=704806Talk:Xorg2021-12-08T07:32:20Z<p>RaZorr: /* Information about xf86-video-intel */ new section</p>
<hr />
<div>== Setting DPI manually ==<br />
<br />
I'm not an Archlinux user, but Google sends me to this Wiki often. As a non-user, I cannot confirm this error on Archlinux unless I find time to learn how to install it. That's unlikely to happen in the foreseeable future.<br />
<br />
The example 'Option "DPI" "96 x 96"' is invalid, because 96 x 96 is forced by the Xorg Xserver to start with as default to match Mac and Windows.<br />
<br />
Unless the Archlinux X servers are different from other distros I've used, Option "DPI" "120 x 120" and others (144, 192, 108, etc) AFAICT only work for users of proprietary NVidia drivers, fail for certain on MGA (e.g. G400), Intel (e.g. 810, 845, 865, 915, 945, 3000, 4000), Radeon (e.g. rv200, rv250, rv380) & Nouveau (e.g. nv11, G84) on openSUSE 12.2, openSUSE 13.1, Fedora 20 and Mageia 4. I've been using Xorg for many many years and have never yet found any version in which this option is valid using any of the 4 FOSS drivers indicated. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 05:25, 10 December 2013 (UTC)<br />
<br />
:As you probably noticed, [[Xorg#Display_size_and_DPI]] is marked as inaccurate with links to several bug reports about Xorg forcing 96x96. Part of Arch's philosophy is to avoid patching of packages whenever possible, but I see that {{Pkg|xorg-server}} uses several patches (see [https://github.com/archlinux/svntogit-packages/blob/packages/xorg-server/trunk]). I don't know which patches other distros use, but this option is not likely to depend on the patches.<br />
:Anyway, if you know a functioning method of manually setting DPI, feel free to share it - even a link to external documentation might be better than the current inaccurate information.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:34, 10 December 2013 (UTC)<br />
<br />
::As help situations arise I point people to my http://fm.no-ip.com/Share/DisplaySize which is mostly a lookup table designed to avoid need to calculate values for DisplaySize that will produce a desired DPI. DisplaySize in 'Section "Monitor"' has been reliable long-term with non-broken drivers, but since KScreen was released last summer, a workaround is required to get xorg.conf* to be obeyed at all by KDE. According to [https://bugs.kde.org/show_bug.cgi?id=317929#c13 Alex Fiestas, KScreen 1.1 is proposed to allow xorg.conf* to be obeyed by default on single display systems]. The workaround is to put [Module-kscreen]\nautoload=false in kdmrc. Whether other DEs have similar obstacles I have no idea. It would really be nice for those only wishing to force the hardware native DPI instead of an arbitrary one (which is usually what 96 is) for https://bugs.freedesktop.org/show_bug.cgi?id=41115 to be fixed, which means letting the server automatically as it already knows how make logical and physical DPI match. http://www.gentoo-wiki.info/HOWTO_Set_DPI_Dots_Per_Inch is one place that shows how to perform the calculations.<br />
<br />
::"To reduce scaling artifacts to GUI that use bitmaps" is not the only reason to choose +25% steps (96, 120, 144, 168, 192...). Most scalable fonts are tuned to 96 DPI, and step from pixel size to pixel size best at specific steps, of which +25% are the best. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]])<br />
<br />
:::I question the validity of the claim that Xorg always sets the DPI to 96 mainly because of this issue: https://bbs.archlinux.org/viewtopic.php?id=197624. Quite a lot of people are having problems with the latest versions of Chromium because Xorg is ''not'' automatically setting the DPI to 96, and Chromium is now high-DPI-sensitive. The result is really bad font and bitmap scaling on most webpages. {{unsigned|20:17, 5 June 2015|Silverhammermba}}<br />
<br />
::::Having fought this problem with a gen4 Intel laptop---1280x800@14.1in LVDS---over the last two days, I reread the man page and found the newish option "ReprobeOutputs". After enabling, the driver correctly detects the panel geometry and size for slightly rectangular pixels and DPI higher than 96x96. This suggests that udev's hardware probing is failing to detect the real hardware configuration or Xorg server is failing to process the information correctly. Unfortunately neither the ati not nv drivers allow for direct reading of the EDID information and you are left to resort to the kind of monitor configuration hackery mentioned above. [[User:Vorbote|Vorbote]] ([[User talk:Vorbote|talk]]) 14:17, 7 October 2015 (UTC)<br />
<br />
:::::I did some experiments in my Radeon HD6310 and discover somethings... lets start:<br />
:::::* efectively, set the dpi in the xorg file is meaningless, as is ignored<br />
:::::* set the CORRECT size for you screen, the size taked manually with rule and seting the correct resolution (if not detected) WILL affect the Xorg dpi.<br />
:::::My monitor is 1366x768 with 309x174 millimeters, those were measured either with software and with my oun measuring rule here in RL, then I set them in Xorg and then the dpi change from 96x96 to 112x112. I use this page to help me: https://www.sven.de/dpi/ <br />
:::::{{unsigned|05:40, 19 April 2016 (UTC)|Jristz}}<br />
<br />
::::::'''If you are having problems with Xorg DPI, be sure to check if any programs are overriding your settings.''' In my case for example: I found that Xorg actually was respecting the DisplaySize entry in the config file, but xfsettingsd (a component of xfce) was setting this back to 96 DPI immediately after I started Xorg. See https://bugzilla.xfce.org/show_bug.cgi?id=10633 for some discussion of this behavior which is hardcoded into xfsettingsd. Apparently this is their solution for dealing with the possibility of a "Screen" spanning multiple monitors, each of which may have different sizes and/or resolutions (DPI). Running xrandr --dpi XXX ''after'' xfsettingsd is started is a workaround, but I think the long-term solution is to file bugs against applications, such as evince, which are incorrectly relying on the "Screen" DPI reported by Xorg. [[User:Dc46and2|Dc46and2]] ([[User talk:Dc46and2|talk]]) 02:34, 9 June 2016 (UTC)<br />
<br />
:::::::In July 2015, a patch was submitted to GTK3 that forces Xft.dpi to 96 whenever 'xrdb -query | grep dpi' would return a null Xft.dpi value. https://bugzilla.gnome.org/show_bug.cgi?id=757142 was filed when the impact of the change became apparent. It was immediately wontfixed. Xft.dpi is not required for Xorg functionality, being an interloper created by the Gnome people(?) as a tool to force DPI, the Gnome device for scaling its UI. The impact of this patch started to become more widely apparent when GTK3 became the default Firefox release build toolkit in 2016, most commonly among users of physical display densities between 96 and 192. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=1269274 Mozilla bug 1269274 "GTK+ 3.18 - UI text sizes no longer inherited from Linux system"] on account of this. It too was promptly wontfixed. Users of both GTK libs >3.16 and DEs that don't depend on Xft.dpi but instead utilize whatever >96 DPI logical density to which Xorg is configured find UI fonts in Firefox 46+ smaller than non-GTK3 apps, appreciably so even with configured density as low as 108 DPI. Such users not used to having Xft.dpi set, e.g. KDE users, will need to set it to match their Xorg DPI if they want supported GTK3-built Firefox (or SeaMonkey and/or Thunderbird) releases to have UI text matching their other apps. In KDE it's not a hard thing to do, because Xft.dpi is the means through which forced DPI in its systemsettings is implemented, but it will require manual intervention to keep Xorg and Xft.dpi in sync when switching among displays of different densities. Alternatively, and with other non-Gnome users, Xresources can be utilized to manage Xft.dpi, as explained on the parent page. [[User:Mrmazda|Mrmazda]] ([[User talk:Mrmazda|talk]]) 06:45, 1 February 2017 (UTC)<br />
<br />
:::::: Regarding the Xorg xft.dpi issue, the ticket is now moved to Gitlab: [https://gitlab.freedesktop.org/xorg/xserver/issues/509 See Xserver issue 509].<br />
:::::: [[User:Danger89|Danger89]] ([[User talk:Danger89|talk]]) 15:04, 15 March 2019 (UTC)<br />
<br />
== Add xhost si:localuser:$USER ? ==<br />
<br />
Access to the X server is usually regulated via the hostname, so if it changes unexpectedly (e.g. see [https://bbs.archlinux.org/viewtopic.php?id=202704 BBS#202704], [[Connman#Avoid_changing_the_hostname]]), things stop working. The user name is (or should be) less prone to change, so you could use {{Pkg|xorg-xhost}} for access:<br />
<br />
$ xhost si:localuser:$USER<br />
<br />
man Xsecurity says on this:<br />
<br />
localuser & localgroup<br />
On systems which can determine in a secure fashion the credentials of a client process,<br />
the "localuser" and "localgroup" authentication methods provide access based on those<br />
credentials. The format of the values provided is platform specific. For POSIX & UNIX<br />
platforms, if the value starts with the character '#', the rest of the string is treated<br />
as a decimal uid or gid, otherwise the string is defined as a user name or group name.<br />
<br />
If your system supports this method and you use it, be warned that some programs that<br />
proxy connections and are setuid or setgid may get authenticated as the uid or gid of<br />
the proxy process. For instance, some versions of ssh will be authenticated as the user<br />
root, no matter what user is running the ssh client, so on systems with such software,<br />
adding access for localuser:root may allow wider access than intended to the X display.<br />
<br />
However, X apps failing is the symptom; the cause lies in [[Network configuration]], or an issue with the (static) [[hostname]] not being respected. So I'm not sure where to mention this, if at all. One way would be to expand [[Xhost]] and add a link there under [[Xorg#Troubleshooting]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:51, 21 September 2015 (UTC)<br />
<br />
: For what it's worth using xhost is probably prefered (for example GDM does this) as xauth was mostly used in an era when hostname changing was very rare. I'm now using xhost instead of maintaining xauth along with the accompanying xauthority file which reduces quite a few dependencies on my end.<br />
<br />
: As for where this should go? I have no idea. [[User:Earnest|Earnest]] ([[User talk:Earnest|talk]]) 23:54, 13 March 2016 (UTC)<br />
<br />
== Location of Xorg.0.log ==<br />
<br />
On my desktop with Gnome 3 and my laptop with KDE 5, my `Xorg.0.log` file is only located in `/var/log/Xorg.0.log`. In the article the location goes back and forth between:<br />
<br />
/var/log/Xorg.0.log<br />
<br />
and <br />
~/.local/share/xorg/Xorg.0.log<br />
<br />
There is a note at the end," `/var/log/` or, for the rootless X default since v1.16, in `~/.local/share/xorg/`". Shouldn't we pick one and put this note at the start? ---- unsigned, by [[User:Slacka]], 20170112<br />
<br />
seconded <br />
/var/log/Xorg.0.log<br />
needs to be specified, im running i3wm<br />
--[[User:Yair|Yair]] ([[User talk:Yair|talk]]) 17:21, 20 April 2018 (UTC)<br />
<br />
== Rootless Xorg ==<br />
<br />
Reverted edit by Alad: "useless without reference, i.e. a bug report "<br />
And why is it not enabled without KMS in the first place? Who says problems with forced rootless xorg are a bug, and not a technical limitation by design?<br />
[[User:Aufkrawall|Aufkrawall]] ([[User talk:Aufkrawall|talk]]) 16:14, 6 November 2017 (UTC)<br />
<br />
:That's all vague conjectures. There's no point to relate CPU usage and KMS without the homework to prove there's an actual relation. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:20, 6 November 2017 (UTC)<br />
<br />
The suggestion at https://wiki.archlinux.org/title/Xorg#Using_xinitrc does not explain why you should use {{ic|startx}} instead of {{ic|exec startx}}, which might lead to confusion among people who are new to configuring Xorg (like me). It's also suggested [https://bbs.archlinux.org/viewtopic.php?pid=1973717#p1973717/ here] that this section should be edited/moved. [[User:Garfa|Garfa]] ([[User talk:Garfa|talk]]) 17:01, 22 May 2021 (UTC)<br />
<br />
== Remove/replace/update the xorg.conf config section? ==<br />
<br />
"Xorg -configure" is broken since years and nvidia-xconfig creates a bunch of cruft around the Device section.<br />
In addition static configuration and the monolithic xorg.conf are, if not even deprecated, causing trouble for unexperienced users by their unflexibility.<br />
It is common on the bbs to ask for the log and tell forum users to remove that file to "fix" things.<br />
<br />
Good reasons (and how) to write a server config (yourself) are indicated in the multihead and optimus articles and I'd suggest to remove that section resp. replace it by an explicit warning to refrain from overriding the autoconfig unwittingly.<br />
Also it should be explained that "Xorg -configure" is known to be "broken" (I cannot prove it, but believe it to be "accidentally broken" as deprecated), the error is normal and you should not be using it anyway ;-)<br />
<br />
{{unsigned|07:30, 2 April 2018|Seth}}<br />
<br />
== Best place for eGPU configs ==<br />
<br />
Greetings,<br />
I'd like to add the following critical piece of information that's not easily available on the internet - I had to find it in the Xorg logs when run with a specific config.<br />
<br />
To get eGPU working with external monitor and internal one disabled:<br />
* Install the correct version and build of drivers (nvidia or nvidia-dkms or equivalent for other makes)<br />
* Use something like the following for the Xorg config:<br />
Section "Module"<br />
Load "modesetting"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidia"<br />
Driver "nvidia"<br />
BusID "PCI:6:0:0"<br />
Option "AllowEmptyInitialConfiguration"<br />
Option "AllowExternalGpus"<br />
EndSection<br />
<br />
The critical thing is the Option "AllowExternalGpus". The existence of this isn't documented on the threads on nvidia support, or on egpu.io.<br />
First section turns off the internal display. If that's missing the systemd output will stay on screen, frozen. Nothing else is necessary, no DM config files, or nvidia-xconfig, or adding drivers to KMS, or using secure TB3 like Da_blitz's guide suggests. <br />
<br />
This was particularly infuriating because the device is easy to work with, send CUDA processes to, and nvidia-xsettings --query-gpu-info recognizes the external monitor. Yet xrandr doesn't. And using most configs crashes Xorg with a multitude of errors, from "No screens found" to "no usable config", to "Failed to get display number from pipe". All were rabbit holes. This info needs to be out there somewhere.<br />
<br />
Whats the best place to add this information? <br />
I was thinking under either NVIDIA/Tips or config or Xorg/Tips or config or start a new page "External GPUs"<br />
<br />
[[User:Snugghash|Snugghash]] ([[User talk:Snugghash|talk]]) 22:59, 10 August 2018 (UTC)<br />
<br />
:Since it is specific to the NVIDIA driver, add it to [[NVIDIA/Tips_and_tricks]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:41, 11 August 2018 (UTC)<br />
<br />
== systemctl --user in rootless Xorg ==<br />
<br />
To get {{ic|systemctl --user}} to work (as well as a device management I guess) with the rootless Xorg setup, I had to edit {{ic|/etc/pam.d/system-login}} so that {{ic|pam_systemd.so}} is required (that is remove the {{ic|-}} in front of {{ic|session}} and change {{ic|optional}} to {{ic|required}}). I am not sure why this isn't the default somehow. -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 19:28, 6 November 2018 (UTC)<br />
<br />
:''to get'' {{ic|systemctl --user}} ''to work''<br />
:not sure what you mean by that but i use ''--user'' for cron like jobs without changing {{ic|/etc/pam.d/system-login}} --[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 09:07, 7 November 2018 (UTC)<br />
<br />
::I just meant any command using {{ic|systemctl --user}}.<br />
::My comment was specific to rootless Xorg, but was edited out of its context, are you using rootless Xorg? -- [[User:Kalessin|Kalessin]] ([[User talk:Kalessin|talk]]) 17:48, 10 November 2018 (UTC)<br />
<br />
:::yes ---[[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 11 November 2018 (UTC)<br />
<br />
== XWayland ==<br />
<br />
As discussed in [[Talk:Wayland#XWayland]], I would like to add a small section for XWayland.<br />
<br />
Technically it is a part of the XServer, so where would you like it better, here or at [[Wayland]]?<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 15:45, 17 October 2020 (UTC) G3ro<br />
<br />
== Information about xf86-video-intel ==<br />
<br />
Maybe mention [https://wiki.archlinux.org/title/Intel_graphics#Installation Intel graphics installation] '''note''' near '''xf86-video-intel''' in [https://wiki.archlinux.org/title/Xorg#Driver_installation Xorg#driver_installation] section.</div>RaZorr