https://wiki.archlinux.org/api.php?action=feedcontributions&user=Denoyse&feedformat=atomArchWiki - User contributions [en]2024-03-28T23:01:16ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Xorg/Keyboard_configuration&diff=377499Talk:Xorg/Keyboard configuration2015-06-05T12:44:41Z<p>Denoyse: </p>
<hr />
<div>== Making Shift+numkeys work like on Windows ==<br />
<br />
I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7'<br />
The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:<br />
<br />
'''setxkbmap -option "numpad:microsoft"'''<br />
<br />
[[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 19:14, 24 July 2014 (UTC)<br />
<br />
== xorg.conf.d fails ==<br />
<br />
Wanted to add the following under "Using X configuration files"<br />
<br />
{{Warning|If you use GDM, use localectl.}} Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.<br />
<br />
I tried using xorg.conf.d files for keyboard and it did not work. I found the linked solution / bug description. I wanted to share that with the community by adding a warning. Not it was removed. Why?<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 11:30, 29 May 2015 (UTC)<br />
<br />
:1. It would be better to link to an upstream report 2. localectl creates those same *.conf files in {{ic|xorg.conf.d}} (besides {{ic|/etc/vconsole.conf}} for TTY use), so the cause it not clear from the warning alone. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:26, 29 May 2015 (UTC)<br />
<br />
:2. I don't have an explanation either. But the bug is also described [http://archlinux.2023198.n4.nabble.com/GDM-td4702089.html here] for Arch. --[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 12:44, 5 June 2015 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:Xorg/Keyboard_configuration&diff=375802Talk:Xorg/Keyboard configuration2015-05-29T12:10:58Z<p>Denoyse: </p>
<hr />
<div>== Making Shift+numkeys work like on Windows ==<br />
<br />
I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7'<br />
The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:<br />
<br />
'''setxkbmap -option "numpad:microsoft"'''<br />
<br />
[[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 19:14, 24 July 2014 (UTC)<br />
<br />
== xorg.conf.d fails ==<br />
<br />
Wanted to add the following under "Using X configuration files"<br />
<br />
{{Warning|If you use GDM, use localectl.}} Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.<br />
<br />
I tried using xorg.conf.d files for keyboard and it did not work. I found the linked solution / bug description. I wanted to share that with the community by adding a warning. Not it was removed. Why?<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 11:30, 29 May 2015 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:Xorg/Keyboard_configuration&diff=375781Talk:Xorg/Keyboard configuration2015-05-29T11:30:29Z<p>Denoyse: </p>
<hr />
<div>== Making Shift+numkeys work like on Windows ==<br />
<br />
I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7'<br />
The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:<br />
<br />
'''setxkbmap -option "numpad:microsoft"'''<br />
<br />
[[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 19:14, 24 July 2014 (UTC)<br />
<br />
== xorg.conf.d fails ==<br />
<br />
Wanted to add the following:<br />
<br />
{{Warning|If you use GDM, use localectl.}} Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.<br />
<br />
Was removed. Why?<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 11:30, 29 May 2015 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:Xorg/Keyboard_configuration&diff=375776Talk:Xorg/Keyboard configuration2015-05-29T11:11:19Z<p>Denoyse: </p>
<hr />
<div>== Making Shift+numkeys work like on Windows ==<br />
<br />
I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7'<br />
The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:<br />
<br />
'''setxkbmap -option "numpad:microsoft"'''<br />
<br />
[[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 19:14, 24 July 2014 (UTC)<br />
<br />
== xorg.conf.d fails ==<br />
<br />
Wanted to add the following:<br />
<br />
{{Warning|If you use GDM, use localectl.}} Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.<br />
<br />
Was removed. Why?</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:Xorg/Keyboard_configuration&diff=375775Talk:Xorg/Keyboard configuration2015-05-29T11:10:52Z<p>Denoyse: </p>
<hr />
<div>== Making Shift+numkeys work like on Windows ==<br />
<br />
I needed Shift+NumHome (numkey 7) to work like Shift+Home and select the text... but with NumLock off it would just type out '7'<br />
The solution was either turn on numlock temporarily then Shift+Num7 or make it work like in Windows where Shift key doesn't act like a temporary numlock toggler:<br />
<br />
'''setxkbmap -option "numpad:microsoft"'''<br />
<br />
[[User:EmanueLczirai|EmanueLczirai]] ([[User talk:EmanueLczirai|talk]]) 19:14, 24 July 2014 (UTC)<br />
<br />
== xorg.conf.d fails ==<br />
<br />
Wanted to add the following:<br />
<br />
{{Warning|'''If you use GDM, use localectl.''' Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.}}<br />
<br />
Was removed. Why?</div>Denoysehttps://wiki.archlinux.org/index.php?title=Xorg/Keyboard_configuration&diff=375732Xorg/Keyboard configuration2015-05-29T06:21:20Z<p>Denoyse: </p>
<hr />
<div>[[Category:Keyboards]]<br />
[[Category:X Server]]<br />
[[es:Keyboard Configuration in Xorg]]<br />
[[ja:Xorg でのキーボード設定]]<br />
{{Related articles start}}<br />
{{Related|Keyboard configuration in console}}<br />
{{Related|Extra keyboard keys}}<br />
{{Related|Xorg}}<br />
{{Related|X KeyBoard extension}}<br />
{{Related articles end}}<br />
<br />
This article's purpose is to detail basic Xorg server keyboard configuration. For advanced topics such as keyboard layout modification or additional key mappings, see [[Extra keyboard keys]].<br />
<br />
== Overview ==<br />
<br />
The Xorg server uses the [[X KeyBoard extension]] (XKB) to define keyboard layouts. Optionally, [[xmodmap]] can be used to access the internal keymap table directly, although this is not recommended for complex tasks. Also [[systemd]]'s ''localectl'' can be used to define the keyboard layout for both the Xorg server and the virtual console.<br />
<br />
{{Note|XKB options can be overridden by the tools provided by some desktop environments such as [[GNOME#XkbOptions_keyboard_options|GNOME (XkbOptions)]] and [[KDE#Set keyboard|KDE (set keyboard)]].}}<br />
<br />
== Viewing keyboard settings ==<br />
<br />
You can use the following command to see the actual XKB settings:<br />
<br />
{{hc|$ setxkbmap -print -verbose 10|<nowiki><br />
Setting verbose level to 10<br />
locale is C<br />
Applied rules from evdev:<br />
model: evdev<br />
layout: us<br />
options: terminate:ctrl_alt_bksp<br />
Trying to build keymap using the following components:<br />
keycodes: evdev+aliases(qwerty)<br />
types: complete<br />
compat: complete<br />
symbols: pc+us+inet(evdev)+terminate(ctrl_alt_bksp)<br />
geometry: pc(pc104)<br />
xkb_keymap {<br />
xkb_keycodes { include "evdev+aliases(qwerty)" };<br />
xkb_types { include "complete" };<br />
xkb_compat { include "complete" };<br />
xkb_symbols { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)" };<br />
xkb_geometry { include "pc(pc104)" };<br />
};<br />
</nowiki>}}<br />
<br />
=== Third party utilities ===<br />
<br />
There are some "unofficial" utilities which allow to print specific information about the currently used keyboard layout.<br />
<br />
* {{AUR|xkb-switch-git}}:<br />
<br />
{{hc|$ xkb-switch|us}}<br />
<br />
* {{AUR|xkblayout-state}}:<br />
<br />
{{hc|$ xkblayout-state print "%s"|de}}<br />
<br />
== Setting keyboard layout ==<br />
<br />
{{Expansion|Udev also comes into play (for example when plugging in a keyboard), undoing changes by ''setxkbmap''}}<br />
<br />
Keyboard layout in Xorg can be set in multiple ways. Here is an explanation of used options:<br />
<br />
* {{ic|XkbModel}} selects the keyboard model. This has an influence only for some extra keys your keyboard might have. The safe fallback are {{ic|pc104}} or {{ic|pc105}}. But for instance laptops usually have some extra keys, and sometimes you can make them work by simply setting a proper model.<br />
* {{ic|XkbLayout}} selects the keyboard layout. Multiple layouts may be specified in a comma-separated list, e.g. if you want to quickly switch between layouts.<br />
* {{ic|XkbVariant}} selects a specific layout variant. For instance, the default {{ic|sk}} variant is {{ic|qwertz}}, but you can manually specify {{ic|qwerty}}, etc.<br />
* {{ic|XkbOptions}} contains some extra options. Used for specifying layout switching, notification LED, compose mode etc.<br />
<br />
{{Note|You must specify as many variants as the number of specified layouts. If you want the default variant, specify an empty string as the variant (the comma must stay). For example, to have the default {{ic|us}} layout as primary and the {{ic|dvorak}} variant of {{ic|us}} layout as secondary, specify {{ic|us,us}} as {{ic|XkbLayout}} and {{ic|,dvorak}} as {{ic|XkbVariant}}.}}<br />
<br />
The layout name is usually a [[Wikipedia:ISO_3166-1_alpha-2#Officially_assigned_code_elements|2-letter country code]]. To see a full list of keyboard models, layouts, variants and options, along with a short description, open {{ic|/usr/share/X11/xkb/rules/base.lst}}. Alternatively, you may use one of the following commands to see a list without a description:<br />
<br />
* {{ic|localectl list-x11-keymap-models}}<br />
* {{ic|localectl list-x11-keymap-layouts}}<br />
* {{ic|localectl list-x11-keymap-variants [''layout'']}}<br />
* {{ic|localectl list-x11-keymap-options}}<br />
<br />
Examples in the following subsections will have the same effect, they will set {{ic|pc104}} model, {{ic|cz}} as primary layout, {{ic|us}} as secondary layout, {{ic|dvorak}} variant for {{ic|us}} layout and the {{ic|Alt+Shift}} combination for switching between layouts.<br />
<br />
=== Using setxkbmap ===<br />
<br />
''setxkbmap'' sets the keyboard layout for the current X session only, but can be made persistent in [[xinitrc|~/.xinitrc]]. This overrides system-wide configuration specified by [[#Using X configuration files|X configuration files]].<br />
<br />
The usage is as follows (see {{ic|man 1 setxkbmap}}):<br />
<br />
$ setxkbmap [-model ''xkb_model''] [-layout ''xkb_layout''] [-variant ''xkb_variant''] [-option ''xkb_options'']<br />
<br />
To change just the layout ({{ic|-layout}} is the default flag):<br />
<br />
$ setxkbmap ''xkb_layout''<br />
<br />
For multiple customizations:<br />
<br />
$ setxkbmap -model pc104 -layout cz,us -variant ,dvorak -option grp:alt_shift_toggle<br />
<br />
=== Using X configuration files ===<br />
<br />
{{Note|{{ic|xorg.conf}} is parsed by the X server at start-up. To apply changes, restart X. [http://fedoraproject.org/wiki/Input_device_configuration#xorg.conf.d].}}<br />
<br />
{{Warning|If you use GDM, use localectl.}} Due to a bug of gdm 3.14+ on systemd systems [https://bugs.mageia.org/show_bug.cgi?id=14476 described here], gdm does not read the 10-keyboard.conf before it starts up.}}<br />
<br />
The syntax of X configuration files is explained in [[Xorg#Configuration]]. This method creates system-wide configuration which is persistent across reboots.<br />
<br />
Here is an example:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-keyboard.conf|<br />
Section "InputClass"<br />
Identifier "system-keyboard"<br />
MatchIsKeyboard "on"<br />
Option "XkbLayout" "cz,us"<br />
Option "XkbModel" "pc104"<br />
Option "XkbVariant" ",dvorak"<br />
Option "XkbOptions" "grp:alt_shift_toggle"<br />
EndSection<br />
}}<br />
<br />
==== Using localectl ====<br />
<br />
For convenience, the tool ''localectl'' may be used instead of manually editing X configuration files. It will save the configuration in {{ic|/etc/X11/xorg.conf.d/00-keyboard.conf}}, this file should not be manually edited, because ''localectl'' will overwrite the changes on next start.<br />
<br />
The usage is as follows:<br />
<br />
$ localectl [--no-convert] set-x11-keymap ''layout'' [''model'' [''variant'' [''options'']]]<br />
<br />
To set a ''model'', ''variant'' or ''options'', all preceding fields need to be specified. Unless the {{ic|--no-convert}} option is passed, the specified keymap is also converted to the closest matching console keymap and applied to the [[Keyboard configuration in console|console configuration]] in {{ic|vconsole.conf}}. See {{ic|man localectl}} for more information.<br />
<br />
To create a {{ic|/etc/X11/xorg.conf.d/00-keyboard.conf}} like the above:<br />
<br />
$ localectl --no-convert set-x11-keymap cz,us pc104 ,dvorak grp:alt_shift_toggle<br />
<br />
== Frequently used XKB options ==<br />
<br />
=== Switching between keyboard layouts ===<br />
<br />
To be able to easily switch keyboard layouts, first specify multiple layouts between which you want to switch (the first one is the default). Then specify a key (or key combination), which will be used for switching. For example, to switch between a US and a Swedish layout using the {{ic|CapsLock}} key, use {{ic|us,se}} as an argument of {{ic|XkbLayout}} and {{ic|grp:caps_toggle}} as an argument of {{ic|XkbOptions}}.<br />
<br />
You can use other key combinations than {{ic|CapsLock}}, they are listed in {{ic|/usr/share/X11/xkb/rules/base.lst}}, start with {{ic|grp:}} and end with {{ic|toggle}}. To get the full list of available options, run the following command:<br />
<br />
$ grep "grp:.*toggle" /usr/share/X11/xkb/rules/base.lst<br />
<br />
=== Terminating Xorg with Ctrl+Alt+Backspace ===<br />
<br />
By default, the key combination {{ic|Ctrl+Alt+Backspace}} is disabled. You can enable it by passing {{ic|terminate:ctrl_alt_bksp}} to {{ic|XkbOptions}}.<br />
<br />
=== Swapping Caps Lock with Left Control ===<br />
<br />
To swap Caps Lock with Left Control key, add {{ic|ctrl:swapcaps}} to {{ic|XkbOptions}}. Run the following command to see similar options along with their descriptions:<br />
<br />
$ grep -E "(ctrl|caps):" /usr/share/X11/xkb/rules/base.lst<br />
<br />
=== Enabling mouse keys ===<br />
<br />
[[Wikipedia:Mouse keys|Mouse keys]] is now disabled by default and has to be manually enabled by passing {{ic|keypad:pointerkeys}} to {{ic|XkbOptions}}. This will make the {{ic|Shift+NumLock}} shortcut toggle mouse keys.<br />
<br />
=== Configuring compose key ===<br />
<br />
Though typically not on traditional keyboards, a [[Wikipedia:Compose key|Compose key]] can be configured to an existent key.<br />
<br />
The {{ic|Compose}} key begins a keypress sequence that involves (usually two) additional keypresses. Usage is typically either for entering characters in a language that the keyboard was not designed for, or for other less-used characters that are not covered with the {{ic|AltGr}} modifier. For example, pressing {{ic|Compose}} {{ic|'}} {{ic|e}} produces {{ic|é}}, or {{ic|Compose}} {{ic|-}} {{ic|-}} will produce an "em dash": {{ic|—}}.<br />
<br />
Though a few more eccentric keyboards feature a {{ic|Compose}} key, its availability is usually through substituting an already existing key to it. For example, to make the {{ic|Menu}} key a {{ic|Compose}} key use the [[Desktop environment]] configuration, or pass {{ic|compose:menu}} to {{ic|XkbOptions}} (or [[#Using setxbkmap|setxkbmap]]: {{ic|setxkbmap -option compose:menu}}). Allowed key substitutions are defined in {{ic|/usr/share/X11/xkb/rules/base.lst}}:<br />
<br />
$ grep "compose:" /usr/share/X11/xkb/rules/base.lst<br />
<br />
==== Key combinations ====<br />
<br />
The default combinations for the compose keys depend on the [[locale]] configured for the session and are stored in {{ic|/usr/share/X11/locale/''used_locale''/Compose}}, where {{ic|''used_locale''}} is for example {{ic|en_US.UTF-8}}.<br />
<br />
You can define your own compose key combinations by copying the default file to {{ic|~/.XCompose}} and editing it. The compose key works with any of the thousands of valid Unicode characters, including those outside the Basic Multilingual Plane.<br />
<br />
However, GTK does not use [[Wikipedia:X Input Method|XIM]] by default and therefore does not follow {{ic|~/.XCompose}} keys. This can be fixed by forcing GTK to use XIM by adding {{ic|1=export GTK_IM_MODULE=xim}} and/or {{ic|1=export XMODIFIERS="@im=none"}} to {{ic|~/.xprofile}}.<br />
<br />
{{Tip|XIM is very old, you might have better luck with other input methods: [[Wikipedia:Smart Common Input Method|SCIM]], [[Wikipedia:Uim|uim]], [[Wikipedia:Intelligent Input Bus|IBus]] etc. See [[Internationalization#Input methods in Xorg]] for details.}}<br />
<br />
=== Currency sign on other key ===<br />
<br />
Most European keyboards have a Euro sign (€) printed on on the {{ic|5}} key. For example, to access it with {{ic|Alt+5}}, use the {{ic|lv3:lalt_switch}} and {{ic|eurosign:5}} options.<br />
<br />
The Rupee sign (₹) can be used the same way with {{ic|rupeesign:4}}.<br />
<br />
=== Switching state immediately when Caps Lock is pressed ===<br />
<br />
Those who prefer typing capital letters with the Caps Lock key may experience a short delay when Caps Lock state is switched, resulting in two or more capital letters (e.g. ''THe'', ''ARch LInux''). This behaviour [[Wikipedia:Caps_lock#History|stems from typewriters]].<br />
<br />
Some more popular operating systems have removed this behaviour, either voluntarily (as it can be confusing to some) or by mistake, however this is a question of preference. Bug reports have been filed on the Xserver bug tracker, as there is currently no easy way to switch to the behaviour reflected by those other operating systems. For anyone who would like to follow up the issue, bug reports and latest working progress can be found at [https://bugs.freedesktop.org/show_bug.cgi?id=27903] and [https://bugs.freedesktop.org/show_bug.cgi?id=56491].<br />
<br />
==== Workaround ====<br />
<br />
First, export your keyboard configurations to a file:<br />
<br />
$ xkbcomp -xkb $DISPLAY xkbmap<br />
<br />
In the file ''xkbmap'', locate the Caps Lock section which begins with ''key <CAPS>'':<br />
<br />
key <CAPS> { [ Caps_Lock ] };<br />
<br />
and replace whole section with the following code:<br />
<br />
key <CAPS> {<br />
repeat=no,<br />
type[group1]="ALPHABETIC",<br />
symbols[group1]=[ Caps_Lock, Caps_Lock],<br />
actions[group1]=[ LockMods(modifiers=Lock), Private(type=3,data[0]=1,data[1]=3,data[2]=3)]<br />
};<br />
<br />
Save and reload keyboard configurations:<br />
<br />
$ xkbcomp -w 0 xkbmap $DISPLAY<br />
<br />
Consider making it a service launching after X starts, since reloaded configurations do not survive a system reboot.<br />
<br />
== Other settings ==<br />
<br />
=== Adjusting typematic delay and rate ===<br />
<br />
The ''typematic delay'' indicates the amount of time (typically in miliseconds) a key needs to be pressed in order for the repeating process to begin. After the repeating process has been triggered, the character will be repeated with a certain frequency (usually given in Hz) specified by the ''typematic rate''. The typematic delay in the [[Keyboard_configuration_in_console#Adjusting_typematic_delay_and_rate|virtual console]] is not affected by these settings.<br />
<br />
==== Using xset ====<br />
<br />
The tool ''xset'' can be used to set the typematic delay and rate for an active X server, certain actions during runtime tho may cause the XServer to reset these changes and revert instead to its ''seat defaults''.<br />
<br />
Usage:<br />
<br />
$ xset r rate ''delay'' [''rate'']<br />
<br />
For example to set a typematic delay to 200ms and a typematic rate to 30Hz, use the following command (use [[xinitrc]] to make it permanent):<br />
<br />
$ xset r rate 200 30<br />
<br />
Issuing the command without specifying the delay and rate will reset the typematic values to their respective defaults; a delay of 660ms and a rate of 25Hz:<br />
<br />
$ xset r rate<br />
<br />
==== Using XServer startup options ====<br />
<br />
A more resistant way to set the typematic delay and rate is to make them the ''seat defaults'' by passing the desired settings to the X server on its startup using the following options:<br />
<br />
* {{ic|-ardelay ''miliseconds''}} - sets the autorepeat delay (length of time in milliseconds that a key must be depressed before autorepeat starts).<br />
* {{ic|-arinterval ''miliseconds''}} - sets the autorepeat interval (length of time in milliseconds that should elapse between autorepeat-generated keystrokes).<br />
<br />
See {{ic|man xserver}} for a full list of X server options and refer to your [[display manager]] for information about how to pass these options.<br />
<br />
==== Using XServer options ====<br />
<br />
Add this line to {{ic|/etc/X11/xorg.conf.d/00-keyboard.conf}}:<br />
<br />
Option "AutoRepeat" "''delay'' ''rate''"</div>Denoysehttps://wiki.archlinux.org/index.php?title=Kerbal_Space_Program&diff=283441Kerbal Space Program2013-11-17T18:24:33Z<p>Denoyse: /* Game never progresses past initial loading */</p>
<hr />
<div>[[category:gaming]]<br />
Since version 0.19, Kerbal Space Program includes a native Linux version. However, only Ubuntu 12.04 is officialy supported, so it may not work on Arch Linux out of the box.<br />
<br />
== Known issues ==<br />
=== Game never progresses past initial loading ===<br />
To fix this, set:<br />
LC_ALL=C<br />
<br />
This is also relevant if you rocket's parts do not connect.<br />
<br />
=== No text display ===<br />
The game requires Arial and Arial Black fonts, provided in the {{AUR|ttf-ms-fonts}} [[AUR]] package.<br />
<br />
=== Graphics flickering when using primusrun ===<br />
Run with PRIMUS_SYNC=2 (but you will get reduced frame rate this way)<br />
<br />
=== Game crashes when accessing settings or saves on 64 bit systems on Steam ===<br />
In the properties for Kerbal Space program, set a launch option of:<br />
LC_ALL=C %command%_64<br />
<br />
=== Game has garbled graphics when running on x86_64 with all lib32 drivers installed ===<br />
Steam launches the KSP.x86 executable vs the KSP.x86_64 executable. <br />
Navigate to <br />
/home/$USER/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program/ <br />
Launch with <br />
./KSP.x86_64<br />
More elegant solution to follow.<br />
<br />
=== Game crashes when starting a game or opening the settings dialog ===<br />
<br />
There's a bug with current Mesa ( as of 57668 ), but luckily a patch exists.<br />
<br />
Get the latest patch from here:<br />
https://bugs.freedesktop.org/show_bug.cgi?id=64913<br />
And recompile mesa with it.<br />
<br />
This should only be considered a temporary solution<br />
<br />
=== No audio on 64-bit systems ===<br />
<br />
Run the 64-bit Executable.<br />
<br />
Steam launches the KSP.x86 executable vs the KSP.x86_64 executable. <br />
Navigate to <br />
/home/$USER/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program/ <br />
Launch with <br />
./KSP.x86_64<br />
More elegant solution to follow.<br />
<br />
==See also==<br />
* http://forum.kerbalspaceprogram.com/showthread.php/24529-The-Linux-compatibility-thread!</div>Denoysehttps://wiki.archlinux.org/index.php?title=Kerbal_Space_Program&diff=283440Kerbal Space Program2013-11-17T18:04:44Z<p>Denoyse: </p>
<hr />
<div>[[category:gaming]]<br />
Since version 0.19, Kerbal Space Program includes a native Linux version. However, only Ubuntu 12.04 is officialy supported, so it may not work on Arch Linux out of the box.<br />
<br />
== Known issues ==<br />
=== Game never progresses past initial loading ===<br />
To fix this, set:<br />
LC_ALL=C<br />
<br />
=== No text display ===<br />
The game requires Arial and Arial Black fonts, provided in the {{AUR|ttf-ms-fonts}} [[AUR]] package.<br />
<br />
=== Graphics flickering when using primusrun ===<br />
Run with PRIMUS_SYNC=2 (but you will get reduced frame rate this way)<br />
<br />
=== Game crashes when accessing settings or saves on 64 bit systems on Steam ===<br />
In the properties for Kerbal Space program, set a launch option of:<br />
LC_ALL=C %command%_64<br />
<br />
=== Game has garbled graphics when running on x86_64 with all lib32 drivers installed ===<br />
Steam launches the KSP.x86 executable vs the KSP.x86_64 executable. <br />
Navigate to <br />
/home/$USER/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program/ <br />
Launch with <br />
./KSP.x86_64<br />
More elegant solution to follow.<br />
<br />
=== Game crashes when starting a game or opening the settings dialog ===<br />
<br />
There's a bug with current Mesa ( as of 57668 ), but luckily a patch exists.<br />
<br />
Get the latest patch from here:<br />
https://bugs.freedesktop.org/show_bug.cgi?id=64913<br />
And recompile mesa with it.<br />
<br />
This should only be considered a temporary solution<br />
<br />
=== No audio on 64-bit systems ===<br />
<br />
Run the 64-bit Executable.<br />
<br />
Steam launches the KSP.x86 executable vs the KSP.x86_64 executable. <br />
Navigate to <br />
/home/$USER/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program/ <br />
Launch with <br />
./KSP.x86_64<br />
More elegant solution to follow.<br />
<br />
==See also==<br />
* http://forum.kerbalspaceprogram.com/showthread.php/24529-The-Linux-compatibility-thread!</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:UEFI_Bootloaders&diff=247431Talk:UEFI Bootloaders2013-02-15T16:37:51Z<p>Denoyse: /* MKinitcpio update hook misses fallback image */</p>
<hr />
<div>== Incorrect instructions ==<br />
<br />
Hi,<br />
<br />
I have already posted some information on the Forums, but since this is the way to go, I'm posting my thoughts here.<br />
<br />
The Wiki's says the following about rEFInd:<br />
''"Note: As of refind-efi 0.6.5, refind now automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind."''<br />
<br />
But how it is possible for rEFInd to scan the /boot directory? When booting rEFInd, only the dirs inside \EFI are readable for rEFInd. I have tested this and I confirm that rEFInd can't scan /boot until it is mounted by fstab. (the actual booting process). The sync scripts seems to be needed, to successfully boot Arch.<br />
<br />
<br />
As for '''Systemd Automation''' script, I find the following line a little bit weird:<br />
''cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs''<br />
<br />
Should it not be: cp -r {/usr/share/refind/*,/lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs ?<br />
Only the file refind_x*ARCH*, is needed for the /lib directory.<br />
<br />
<br />
Also I would like to see instructions how to add a custom boot entry (if needed/other location). They are documented inside rEFInd, but not on the Wiki.<br />
menuentry "Arch Linux" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=graphical.target"<br />
}<br />
<br />
menuentry "Arch Linux Fallback" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch-fallback.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=multi-user.target"<br />
}<br />
<br />
<br />
Thanks<br />
<br />
[[User:Beta990|Beta990]] ([[User talk:Beta990|talk]]) 11:11, 28 January 2013 (UTC)<br />
<br />
<br />
== Issue with the Systemd Automation script ==<br />
<br />
Beta990 has some reason questioning the '''Systemd Automation''' script's line:<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
As it is on the wiki, it just prints this when launched:<br />
/usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable<br />
[in English: unvalid identifier].<br />
Unfortunately editing that single line as follow changes nothing:<br />
cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs<br />
<br />
Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):<br />
Tip: Enable the systemd path unit by running :<br />
# systemctl enable refind_update.path;<br />
[[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:31, 3 February 2013 (UTC)<br />
<br />
<br />
== MKinitcpio update hook not working ==<br />
<br />
The mkinitcpio auto-update hook does not work. I get the following output: "Synced to /boot/efi/EFI/arch", along with some cp errors. Obviously, the parameters are not passed.<br />
<br />
If i replace the script with the static cp commands from incron, i get the following output, indicating that the image is copied BEFORE the new one is written:<br />
<br />
-> Running build hook: [efistub-update]<br />
Synced new kernel and initrd to EFIStub.<br />
==> Generating module dependencies<br />
==> Creating gzip initcpio image: /boot/initramfs-linux.img<br />
==> Image generation successful<br />
<br />
As a result, my scripts now look as follows:<br />
<br />
/usr/lib/initcpio/install/efistub-update <br />
----<br />
#!/bin/sh<br />
<br />
build() {<br />
/usr/local/sbin/efistub-update &<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook simply waits for mkinitcpio to finish and copies the finished ramdisk and kernel to UEFI<br />
HELPEOF<br />
}<br />
<br />
and<br />
<br />
/usr/local/sbin/efistub-update<br />
----<br />
#!/bin/sh<br />
<br />
while [ [ -d "/proc/$PPID" ]]; do<br />
sleep 1<br />
done<br />
<br />
/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/EFIStub/vmlinuz-arch.efi<br />
/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/EFIStub/initramfs-arch.img<br />
/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/EFIStub/initramfs-arch-fallback.img<br />
<br />
echo "Synced new kernel and initrd to EFIStub."<br />
<br />
<br />
<br />
Also, the watch.sh does not get chmod +x'ed in the existing example.<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 16:08, 15 February 2013 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:UEFI_Bootloaders&diff=247430Talk:UEFI Bootloaders2013-02-15T16:29:45Z<p>Denoyse: /* MKinitcpio update hook misses fallback image */</p>
<hr />
<div>== Incorrect instructions ==<br />
<br />
Hi,<br />
<br />
I have already posted some information on the Forums, but since this is the way to go, I'm posting my thoughts here.<br />
<br />
The Wiki's says the following about rEFInd:<br />
''"Note: As of refind-efi 0.6.5, refind now automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind."''<br />
<br />
But how it is possible for rEFInd to scan the /boot directory? When booting rEFInd, only the dirs inside \EFI are readable for rEFInd. I have tested this and I confirm that rEFInd can't scan /boot until it is mounted by fstab. (the actual booting process). The sync scripts seems to be needed, to successfully boot Arch.<br />
<br />
<br />
As for '''Systemd Automation''' script, I find the following line a little bit weird:<br />
''cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs''<br />
<br />
Should it not be: cp -r {/usr/share/refind/*,/lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs ?<br />
Only the file refind_x*ARCH*, is needed for the /lib directory.<br />
<br />
<br />
Also I would like to see instructions how to add a custom boot entry (if needed/other location). They are documented inside rEFInd, but not on the Wiki.<br />
menuentry "Arch Linux" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=graphical.target"<br />
}<br />
<br />
menuentry "Arch Linux Fallback" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch-fallback.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=multi-user.target"<br />
}<br />
<br />
<br />
Thanks<br />
<br />
[[User:Beta990|Beta990]] ([[User talk:Beta990|talk]]) 11:11, 28 January 2013 (UTC)<br />
<br />
<br />
== Issue with the Systemd Automation script ==<br />
<br />
Beta990 has some reason questioning the '''Systemd Automation''' script's line:<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
As it is on the wiki, it just prints this when launched:<br />
/usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable<br />
[in English: unvalid identifier].<br />
Unfortunately editing that single line as follow changes nothing:<br />
cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs<br />
<br />
Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):<br />
Tip: Enable the systemd path unit by running :<br />
# systemctl enable refind_update.path;<br />
[[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:31, 3 February 2013 (UTC)<br />
<br />
<br />
== MKinitcpio update hook misses fallback image ==<br />
<br />
The mkinitcpio auto-update hook does not work. I get the following output: "Synced to /boot/efi/EFI/arch", according with some cp errors. Obviously, the parameters are not passed.<br />
<br />
If i replace the script with the static cp commands from incron, i get the following output, indicating that the image is copied BEFORE the new one is written:<br />
<br />
-> Running build hook: [efistub-update]<br />
Synced new kernel and initrd to EFIStub.<br />
==> Generating module dependencies<br />
==> Creating gzip initcpio image: /boot/initramfs-linux.img<br />
==> Image generation successful<br />
<br />
Also, the watch.sh does not get chmod +x'ed<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 16:08, 15 February 2013 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:UEFI_Bootloaders&diff=247429Talk:UEFI Bootloaders2013-02-15T16:22:32Z<p>Denoyse: /* MKinitcpio update hook misses fallback image */</p>
<hr />
<div>== Incorrect instructions ==<br />
<br />
Hi,<br />
<br />
I have already posted some information on the Forums, but since this is the way to go, I'm posting my thoughts here.<br />
<br />
The Wiki's says the following about rEFInd:<br />
''"Note: As of refind-efi 0.6.5, refind now automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind."''<br />
<br />
But how it is possible for rEFInd to scan the /boot directory? When booting rEFInd, only the dirs inside \EFI are readable for rEFInd. I have tested this and I confirm that rEFInd can't scan /boot until it is mounted by fstab. (the actual booting process). The sync scripts seems to be needed, to successfully boot Arch.<br />
<br />
<br />
As for '''Systemd Automation''' script, I find the following line a little bit weird:<br />
''cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs''<br />
<br />
Should it not be: cp -r {/usr/share/refind/*,/lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs ?<br />
Only the file refind_x*ARCH*, is needed for the /lib directory.<br />
<br />
<br />
Also I would like to see instructions how to add a custom boot entry (if needed/other location). They are documented inside rEFInd, but not on the Wiki.<br />
menuentry "Arch Linux" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=graphical.target"<br />
}<br />
<br />
menuentry "Arch Linux Fallback" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch-fallback.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=multi-user.target"<br />
}<br />
<br />
<br />
Thanks<br />
<br />
[[User:Beta990|Beta990]] ([[User talk:Beta990|talk]]) 11:11, 28 January 2013 (UTC)<br />
<br />
<br />
== Issue with the Systemd Automation script ==<br />
<br />
Beta990 has some reason questioning the '''Systemd Automation''' script's line:<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
As it is on the wiki, it just prints this when launched:<br />
/usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable<br />
[in English: unvalid identifier].<br />
Unfortunately editing that single line as follow changes nothing:<br />
cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs<br />
<br />
Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):<br />
Tip: Enable the systemd path unit by running :<br />
# systemctl enable refind_update.path;<br />
[[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:31, 3 February 2013 (UTC)<br />
<br />
<br />
== MKinitcpio update hook misses fallback image ==<br />
<br />
The mkinitcpio auto-update hook does not work. I get the following output: "Synced to /boot/efi/EFI/arch", according with some cp errors. Obviously, the parameters are not passed.<br />
<br />
Also, the watch.sh does not get chmod +x'ed<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 16:08, 15 February 2013 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:UEFI_Bootloaders&diff=247424Talk:UEFI Bootloaders2013-02-15T16:10:11Z<p>Denoyse: </p>
<hr />
<div>== Incorrect instructions ==<br />
<br />
Hi,<br />
<br />
I have already posted some information on the Forums, but since this is the way to go, I'm posting my thoughts here.<br />
<br />
The Wiki's says the following about rEFInd:<br />
''"Note: As of refind-efi 0.6.5, refind now automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind."''<br />
<br />
But how it is possible for rEFInd to scan the /boot directory? When booting rEFInd, only the dirs inside \EFI are readable for rEFInd. I have tested this and I confirm that rEFInd can't scan /boot until it is mounted by fstab. (the actual booting process). The sync scripts seems to be needed, to successfully boot Arch.<br />
<br />
<br />
As for '''Systemd Automation''' script, I find the following line a little bit weird:<br />
''cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs''<br />
<br />
Should it not be: cp -r {/usr/share/refind/*,/lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs ?<br />
Only the file refind_x*ARCH*, is needed for the /lib directory.<br />
<br />
<br />
Also I would like to see instructions how to add a custom boot entry (if needed/other location). They are documented inside rEFInd, but not on the Wiki.<br />
menuentry "Arch Linux" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=graphical.target"<br />
}<br />
<br />
menuentry "Arch Linux Fallback" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch-fallback.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=multi-user.target"<br />
}<br />
<br />
<br />
Thanks<br />
<br />
[[User:Beta990|Beta990]] ([[User talk:Beta990|talk]]) 11:11, 28 January 2013 (UTC)<br />
<br />
<br />
== Issue with the Systemd Automation script ==<br />
<br />
Beta990 has some reason questioning the '''Systemd Automation''' script's line:<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
As it is on the wiki, it just prints this when launched:<br />
/usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable<br />
[in English: unvalid identifier].<br />
Unfortunately editing that single line as follow changes nothing:<br />
cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs<br />
<br />
Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):<br />
Tip: Enable the systemd path unit by running :<br />
# systemctl enable refind_update.path;<br />
[[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:31, 3 February 2013 (UTC)<br />
<br />
<br />
== MKinitcpio update hook misses fallback image ==<br />
<br />
The mkinitcpio auto-update part only updates kernel and initrd. However, the given script does not copy the fallback image.<br />
<br />
Also, the watch.sh does not get chmod +x'ed<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 16:08, 15 February 2013 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:UEFI_Bootloaders&diff=247423Talk:UEFI Bootloaders2013-02-15T16:08:01Z<p>Denoyse: </p>
<hr />
<div>== Incorrect instructions ==<br />
<br />
Hi,<br />
<br />
I have already posted some information on the Forums, but since this is the way to go, I'm posting my thoughts here.<br />
<br />
The Wiki's says the following about rEFInd:<br />
''"Note: As of refind-efi 0.6.5, refind now automatically detects kernels in /boot. They do not have to be renamed to have a .efi extension either. Hence, the following sync scripts aren't needed if using refind."''<br />
<br />
But how it is possible for rEFInd to scan the /boot directory? When booting rEFInd, only the dirs inside \EFI are readable for rEFInd. I have tested this and I confirm that rEFInd can't scan /boot until it is mounted by fstab. (the actual booting process). The sync scripts seems to be needed, to successfully boot Arch.<br />
<br />
<br />
As for '''Systemd Automation''' script, I find the following line a little bit weird:<br />
''cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs''<br />
<br />
Should it not be: cp -r {/usr/share/refind/*,/lib/refind/refind_x*$arch*.efi} $refind_dir/ && ## update bin and dirs ?<br />
Only the file refind_x*ARCH*, is needed for the /lib directory.<br />
<br />
<br />
Also I would like to see instructions how to add a custom boot entry (if needed/other location). They are documented inside rEFInd, but not on the Wiki.<br />
menuentry "Arch Linux" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=graphical.target"<br />
}<br />
<br />
menuentry "Arch Linux Fallback" {<br />
icon /EFI/refind/icons/os_arch.icns<br />
loader /EFI/arch/vmlinuz-arch.efi<br />
initrd /EFI/arch/initramfs-arch-fallback.img<br />
options "root=PARTUUID=xx rootfstype=ext4 ro add_efi_memmap systemd.unit=multi-user.target"<br />
}<br />
<br />
<br />
Thanks<br />
<br />
[[User:Beta990|Beta990]] ([[User talk:Beta990|talk]]) 11:11, 28 January 2013 (UTC)<br />
<br />
<br />
== Issue with the Systemd Automation script ==<br />
<br />
Beta990 has some reason questioning the '''Systemd Automation''' script's line:<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
As it is on the wiki, it just prints this when launched:<br />
/usr/lib/systemd/scripts/refind_name_patchv2: ligne31: « update-efi-dir » : identifiant non valable<br />
[in English: unvalid identifier].<br />
Unfortunately editing that single line as follow changes nothing:<br />
cp -r /usr/{share/refind/*,lib/refind/refind_*$arch*.efi} $refind_dir/ && ## update bin and dirs<br />
<br />
Next in the wiki, there might be a typo at the end of the systemctl command (see the « ; »):<br />
Tip: Enable the systemd path unit by running :<br />
# systemctl enable refind_update.path;<br />
[[User:Kozaki|kozaki]] ([[User talk:Kozaki|talk]]) 23:31, 3 February 2013 (UTC)<br />
<br />
<br />
== MKinitcpio update hook misses fallback image ==<br />
<br />
The mkinitcpio auto-update part only updates kernel and initrd. However, the given script does not copy the fallback image.<br />
<br />
--[[User:Denoyse|Denoyse]] ([[User talk:Denoyse|talk]]) 16:08, 15 February 2013 (UTC)</div>Denoysehttps://wiki.archlinux.org/index.php?title=UEFI_Bootloaders&diff=247422UEFI Bootloaders2013-02-15T16:05:34Z<p>Denoyse: /* Setting up EFISTUB */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[zh-CN:UEFI Bootloaders]]<br />
This page contains info about various [[UEFI]] Bootloaders capable of booting Linux kernel. It is recommended to read the [[UEFI]] and [[GPT]] pages before reading this page. The following [[Boot Loader|bootloaders]] (listed in decreasing order of stability) are explained here:<br />
<br />
== Linux Kernel EFISTUB ==<br />
<br />
Linux (Kernel >= 3.3) supports {{ic|EFISTUB (EFI BOOT STUB)}} booting. It is enabled by by default on Arch Linux kernels or can be activated by setting {{ic|CONFIG_EFI_STUB&#61;y}} in the Kernel configuration (see [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD The EFI Boot Stub] for more information).<br />
<br />
A single EFISTUB kernel is not capable of launching other kernels, hence each EFISTUB Kernel + Initramfs pair requires a separate boot menu entry. It is recommended to use a UEFI Boot Manager to manage multiple kernels.<br />
<br />
=== Setting up EFISTUB ===<br />
<br />
#[https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_an_UEFI_System_Partition_in_Linux Create a FAT32 UEFI System Partition]<br />
# Mount the UEFI System Partition at {{ic|/boot/efi}} with {{ic|# mount <UEFI Partition /boot/efi}}<br />
# Create {{ic|/boot/efi/EFI/arch/}} directory with {{ic|# mkdir /boot/efi/EFI/arch/}}<br />
# Copy the following files from source to destination<br />
{| border="1"<br />
!Boot File Source!!UEFI Destination<br />
|-<br />
| /boot/vmlinuz-linux || /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
|-<br />
| /boot/initramfs-linux.img || /boot/efi/EFI/arch/initramfs-arch.img<br />
|-<br />
| /boot/initramfs-linux-fallback.img || /boot/efi/EFI/arch/initramfs-arch-fallback.img<br />
|}<br />
<br />
=== Sync EFISTUB Kernel ===<br />
{{Warning|The EFISTUB Kernel must be updated each time the kernel is updated (follow step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]. Failure to do so will result in failure to boot. Alternatively one can automatically update the EFISTUB kernel using one of the following methods:}}<br />
<br />
{{Note| As of [https://www.archlinux.org/packages/extra/any/refind-efi/ refind-efi 0.6.5], refind now automatically detects kernels in {{ic|/boot}}. They do not have to be renamed to have a {{ic|.efi}} extension either. Hence, the following sync scripts aren't needed if using [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd refind].}}<br />
<br />
==== Systemd ====<br />
[[Systemd]] features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in {{ic|boot}}.<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.path}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Copy EFISTUB Kernel to UEFISYS Partition<br />
<br />
[Path]<br />
PathChanged=/boot/vmlinuz-linux<br />
PathChanged=/boot/initramfs-linux.img<br />
PathChanged=/boot/initramfs-linux-fallback.img<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.service}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Copy EFISTUB Kernel to UEFISYS Partition<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
ExecStart=/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img<br />
ExecStart=/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img<br />
</nowiki>}}<br />
<br />
{{Tip|Enable these services with<br />
{{bc|<nowiki><br />
# systemctl enable efistub-update.path<br />
</nowiki>}}}}<br />
<br />
==== Incron ====<br />
{{Pkg|incron}} can run a script to sync the EFISTUB Kernel after updates<br />
<br />
{{Tip|Save the following script as {{ic|/usr/local/bin/efistub-update.sh}}}}<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img<br />
/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/etc/incron.d/efistub-update.conf}}}}<br />
{{Note|The first parameter {{ic|/boot/initramfs-linux-fallback.img}} is the file to watch. The second parameter {{ic|IN_CLOSE_WRITE}} is the action to watch for. The third parameter {{ic|/usr/local/bin/efistub-update.sh}} is the script to execute.}}<br />
{{bc|<nowiki><br />
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update.sh<br />
</nowiki>}}<br />
<br />
{{Tip|In order to use this method, incron must be activated, if it is not run<br />
{{bc|<nowiki><br />
# systemctl enable incrond.service<br />
</nowiki>}}}}<br />
<br />
==== Mkinitcpio hook ====<br />
Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of {{ic|vm-linuz}}, {{ic|initramfs-linux.img}}, and {{ic|initramfs-linux-fallback.img}}; then follows step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/initcpio/install/efistub-update}}}}<br />
{{bc|<nowiki><br />
#!/usr/bin/env bash<br />
<br />
build() {<br />
local kernel= image=<br />
while getopts ':c:S:' OPT; do<br />
case $OPT in<br />
'c') kernel=$OPTARG;;<br />
'S') image=$OPTARG;;<br />
esac<br />
done<br />
<br />
/root/watch.sh $image $kernel &<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook simply waits for mkinitcpio to finish and copies the finished ramdisk and kernel to UEFI<br />
HELPEOF<br />
}<br />
<br />
# vim: set ft=sh ts=4 sw=4 et:<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/root/watch.sh}}}}<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
EFI_DIR="/boot/efi/EFI/arch"<br />
<br />
INITRD=$1<br />
KERNEL=$2<br />
<br />
EFI_IMAGE="$EFI_DIR/${KERNEL##*/}.efi"<br />
EFI_INITRD="$EFI_DIR/${INITRD##*/}"<br />
<br />
while [[ -d "/proc/$PPID" ]]; do<br />
sleep 1<br />
done<br />
<br />
cp $INITRD $EFI_INITRD<br />
cp $KERNEL $EFI_IMAGE<br />
echo "Synced $INITRD to $EFI_DIR"<br />
</nowiki>}}<br />
<br />
{{Tip|Add {{ic|efistub-update}} to the list of hooks in {{ic|/etc/mkinitcpio.conf}}}}<br />
<br />
=== Booting EFISTUB ===<br />
<br />
{{Warning|Linux Kernel EFISTUB booting uses {{ic|\}} instead of {{ic|/}} and should be relative to the UEFI System Partition's root. For example, if the initramfs is located in {{ic|/boot/efi/EFI/arch/initramfs-linux.img}}, the corresponding UEFI formatted line would be {{ic|\EFI\arch\initramfs-linux.img}}. Failure to convert the options will lead to a system hang without any error message from the firmware or kernel.}}<br />
<br />
One can boot the EFISTUB kernel using one of the following ways :<br />
<br />
==== Using rEFInd ====<br />
<br />
rEFInd is a fork of rEFIt Boot Manager (used in Intel Macs) by Rod Smith (author of GPT-fdisk). rEFInd fixes many issues in rEFIt with respect to non-Mac UEFI booting and also has support for booting EFISTUB kernels and contains some features specific to them. More info about rEFInd support for EFISTUB is at [http://www.rodsbooks.com/refind/linux.html The rEFInd Boot Manager: Methods of Booting Linux].<br />
<br />
# Install {{Pkg|refind-efi}} package with {{ic|# pacman -S refind-efi}}<br />
# Copy the following files from their source directory to their destination<br />
{{Note|1=<arch> is the bit architecture of the system. Run {{ic|$ uname -m}} to get the architecture. Replace <arch> with "ia32" for 32 bit systems, and <arch> with "x64" for 64 bit systems.}}<br />
{| border="1"<br />
!rEFInd File Source!!UEFI Destination<br />
|-<br />
| /usr/lib/refind/refind_<arch>.efi || /boot/efi/EFI/refind/refind_<arch>.efi<br />
|-<br />
| /usr/lib/refind/config/refind.conf || /boot/efi/EFI/refind/refind.conf<br />
|-<br />
| /usr/share/refind/icons || /boot/efi/EFI/refind/icons<br />
|}<br />
<br />
{{Tip|Refind's configuration file is located in {{ic|/boot/efi/EFI/refind/refind.conf}}. The file is well commented.}}<br />
<br />
{{Note|As of {{Pkg|refind-efi}} 0.6.5-1, refind can auto-detect kernels in {{ic|/boot}}, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. To enable rEFInd to detect and load the drivers and /boot kernels you must enable the appropriate options in {{ic|refind.conf}} (mainly mention the PATH for the drivers location in the ESP) and also copy your {{ic|refind_linux.conf}} to {{ic|/boot/refind_linux.conf}} .}}<br />
<br />
{{Tip|Pass kernel specific commands by copying {{ic|/usr/lib/refind/config/refind_linux.conf}} to {{ic|/boot/efi/EFI/arch/refind_linux.conf}}. This file should be located in the same directory as the EFISTUB kernel. Edit the configuration file to be similar to the template below. Replace the string after PARTUIID with your root's PARTUIID}}<br />
{{Note|Please notice the difference between the standard UUID and the PARTUUID shown by {{ic|$ ls -l /dev/disk/by-partuuid/}}}}<br />
{{hc|$esp/EFI/arch/refind_linux.conf|<nowiki><br />
"Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"<br />
"Boot to Terminal" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"</nowiki>}}<br />
<br />
{{Tip|Each line of {{ic|refind_linux.conf}} is displayed as a submenu by rEFInd. Access the submenu with "+" or "insert" keys.}}<br />
<br />
{{Tip|In non-Mac systems, create an entry for rEFInd using [[UEFI#efibootmgr|efibootmgr]] where sdX is the UEFI disk, and Y is the UEFI partition number. Run :<br />
{{bc|<nowiki><br />
# modprobe efivars<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "rEFInd" -l '\EFI\refind\refind_<arch>.efi'<br />
</nowiki>}}}}<br />
<br />
===== Systemd Automation =====<br />
{{Tip|To automate the process of copying refind files and updating the nvram (if needed) use the following script}}<br />
<br />
{{Note|Save this script as {{ic|/usr/lib/systemd/scripts/refind_name_patchv2}}}}<br />
{{Tip|If you want to change the directory that refind is installed in the UEFISYS partition, just change the value of $refind_dir in the script}}<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
## COPYRIGHT 2013 : MARK E. LEE (BLUERIDER) : mlee24@binghamton.edu; mark@markelee.com<br />
<br />
## LOG<br />
## 1/17/2013 : Version 2 of refind_name_patch is released<br />
## : Supports long subdirectory location for refind<br />
## : Updates nvram when needed<br />
## : 10% speed boost<br />
<br />
function main () { ## main insertion function<br />
declare -r refind_dir="/boot/efi/EFI/refind"; ## set the refind directory<br />
declare -r arch=$(uname -m | awk -F'_' '{if ($1 == "x86"){print $2}}') && ## get bit architecture<br />
update-efi-dir; ## updates or creates the refind directory<br />
update-efi-nvram; ## updates nvram if needed<br />
}<br />
<br />
function update-efi-dir () { ## setup the refind directory<br />
if [ ! -d $refind_dir ]; then ## check if refind directory exists<br />
echo "Couldn't find $refind_dir";<br />
mkdir $refind_dir && ## make the refind directory if needed<br />
echo "Made $refind_dir";<br />
fi;<br />
if [ "$arch" ]; then ## check if anything was stored in $arch<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
echo "Updated binaries and directory files for refind at $refind_dir";<br />
else<br />
echo "Failed to detect an x86 architecture";<br />
exit;<br />
fi;<br />
}<br />
<br />
function update-efi-nvram () { ## update the nvram with efibootmgr<br />
declare -r ref_bin=${refind_dir/\/boot\/efi}/$(ls /usr/lib | grep $arch*.efi); ## get path of refind binary (without /boot/efi)<br />
declare -r ref_bin_escape=${ref_bin//\//\\\\}; ## insert escape characters into $ref_bin<br />
modprobe efivars && ## grab the efi variables for efibootmgr<br />
efibootmgr -v | grep $ref_bin_escape && ( ## check if boot entry is in nvram<br />
echo "Found boot entry, no need to update nvram";<br />
) || ( ## if boot entry is not in nvram; add it<br />
declare -r esp=$(mount -l | awk '/ESP/ {print $1}') && ## get ESP partition<br />
efibootmgr -c -g -d ${esp:0:8} -p ${esp:8} -w -L "rEFInd" -l $ref_bin_escape && ## update nvram<br />
echo "<br />
Updated nvram with entry rEFInd to boot $ref_bin<br />
Did not copy configuration files, please move refind.conf to $refind_dir/";<br />
)<br />
}<br />
<br />
main; ## run the main insertion function<br />
</nowiki>}}<br />
<br />
{{Note|Save the following service file as {{ic|/usr/lib/systemd/system/refind_update.path}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Update rEFInd bootloader files<br />
<br />
[Path]<br />
PathChanged=/usr/lib/refind/refind_<arch>.efi<br />
Unit=refind_update.service<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Note|Save the following service file as {{ic|/usr/lib/systemd/system/refind_update.service}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Update rEFInd directories, binaries, and nvram<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/bash /usr/lib/systemd/scripts/refind_name_patchv2<br />
RemainAfterExit=no<br />
</nowiki>}}<br />
<br />
{{Tip|Enable the systemd path unit by running :<br />
{{bc|<nowiki><br />
# systemctl enable refind_update.path;<br />
</nowiki>}}}}<br />
<br />
===== Apple Macs =====<br />
<br />
In case of Apple Macs, try {{AUR|mactel-boot}} for an experimental "bless" utility for Linux. If that does not work, use "bless" form within OSX to set rEFInd as default bootloader. Assuming UEFISYS partition is mounted at {{ic|/mnt/efi}} within OSX, do<br />
<br />
$ sudo bless --setBoot --folder /mnt/efi/EFI/refind --file /mnt/efi/EFI/refind/refind_x64.efi<br />
<br />
===== VirtualBox =====<br />
<br />
In case of VirtualBox, see [[VirtualBox#Using_Arch_under_Virtualbox_EFI_mode]].<br />
<br />
==== Using gummiboot ====<br />
<br />
[[Gummiboot]] is a UEFI Boot Manager which provides a nice menu for EFISTUB Kernels. It is a new program and relatively untested compared to rEFInd . It is available in [extra] as {{Pkg|gummiboot-efi}}. See http://freedesktop.org/wiki/Software/gummiboot for more info.<br />
<br />
==== Using UEFI Shell ====<br />
<br />
It is possible to launch EFISTUB kernel form UEFI Shell as if it is a normal UEFI application. In this case the kernel parameters are passed as normal parameters to the launched EFISTUB kernel file.<br />
<br />
> fs0:<br />
> cd \EFI\arch<br />
> vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img<br />
<br />
You can also write a simple {{ic|archlinux.nsh}} file with your boot parameters and put it in your UEFI System Partition, then run it with:<br />
<br />
fs0:<br />
archlinux<br />
<br />
Example Script:<br />
<br />
echo -on<br />
\EFI\arch\vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img<br />
<br />
This way you can specify UUID's without needing to remember the name or type out 20-30 characters.<br />
<br />
==== Using efibootmgr entry ====<br />
<br />
{{Note|1=This menthod may not work due to [https://git.kernel.org/?p=linux/kernel/git/mfleming/efi.git;a=commitdiff;h=b003aaf799c991295b8b73e8f940d20bda2c1bbb;hp=ddffeb8c4d0331609ef2581d84de4d763607bd37 limitations in how the kernel handles uefi runtime variables]. For example in Lenovo Thinkpads the initrd path is truncated (verified using {{ic|efibootmgr -v}} command) and therefore the kernel fails to boot.}}<br />
<br />
{{Note|Some UEFI firmwares may not support embedding command line parameters to uefi applications in the boot entries.}}<br />
<br />
It is possible to directly embed the kernel parameters within the boot entry created by efibootmgr. This means that in your BIOS/UEFI you will be able to select Arch Linux directly in the default boot order, and on startup it will boot into Arch directly without any kind of boot selection GUI.<br />
<br />
Do (as root):<br />
<br />
Install efibootmgr if you haven't already.<br />
# pacman -S --needed efibootmgr<br />
<br />
Determine the UUID or PARTUUID of your boot device (ie. the partition for {{ic|/}}, not the EFI boot partition)<br />
# blkid<br />
<br />
Load the EFI module.<br />
# modprobe efivars<br />
<br />
Finally, add the efistub.<br />
WARNING: Make sure you replace the following before running this command:<br />
* ''3518bb68-d01e-45c9-b973-0b5d918aae96'' -- with the UUID of your {{ic|/}} partition. (This is not PARTUUID!)<br />
* ''ext4'' -- if you use a different file system.<br />
* ''/dev/sda'' -- the drive that contains the EFI boot partition.<br />
* ''-p 1'' -- the partition number of the EFI boot partition.<br />
# echo 'root=UUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img' | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -@ -<br />
<br />
or you can just run the following line (remember to replace /dev/sda1):<br />
<br />
# echo "root=UUID=$(blkid /dev/sda1 -o value -s UUID) ro rootfstype=ext4 add_efi_memmap initrd=\\EFI\\arch\\initramfs-arch.img" | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -@ -<br />
<br />
{{Note|The trailing hyphen after {{ic|--append-binary-args}} or {{ic|-@}} is required to instruct efibootmgr to read the parameters from STDIN (standard input). The code should be {{ic|--append-binary-args -}} or {{ic|-@ -}} .}}<br />
<br />
More info about efibootmgr at [[UEFI#efibootmgr]]. Forum post https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 .<br />
<br />
{{Note|Some firmwares may have trouble with the "initrd path" when piping in ucs-2 as shown above. In this case, one may put vmlinuz-linux.efi and the initramfs in the root of the ESP and adjust the efibootmgr entry accordingly.}}<br />
<br />
== GRUB 2.x ==<br />
<br />
GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from {{ic|/boot}} and does not require the kernel and initramfs files to be in the UEFISYS partition. Detailed information at [[GRUB#UEFI_systems_2]]. For bzr development version try AUR package - {{AUR|grub-efi-x86_64-bzr}}.<br />
<br />
== SYSLINUX ==<br />
<br />
{{Note|Syslinux UEFI support is currently part of version 6.00-preXX or in firmware branch of upstream git repo. It is considered alpha quality by upstream. The below information is provided mainly to enable bug-testing. Please report all issues upstream.}}<br />
<br />
{{Note|Syslinux UEFI can boot only those kernels that support '''EFI Handover Protocol'''. Thus LTS kernels are not supported.}}<br />
<br />
Install {{AUR|syslinux-efi-git}} AUR package and copy {{ic|/usr/lib/syslinux/efi64/*}} to {{ic|$esp/EFI/syslinux/}} ({{ic|$esp}} is the mountpoint of UEFISYS partition) ({{ic|efi64}} is for x86_64 UEFI firmwares, replace with {{ic|efi32}} for i386 UEFI firmwares), and then create a boot entry using efibootmgr in the firmware boot manager.<br />
<br />
== ELILO ==<br />
<br />
ELILO is the UEFI version of LILO Boot Loader. It was originally created for Intel Itanium systems which supported only EFI (precursor to UEFI). It is the oldest UEFI bootloader for Linux. It is still in development but happens at a very slow pace. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ . Elilo config file {{ic|elilo.conf}} is similar to [[LILO]]'s config file. AUR package - {{AUR|elilo-efi-x86_64}} (only for x86_64 UEFI).<br />
<br />
== EFILINUX ==<br />
<br />
EFILINUX is a reference implementation of a UEFI Linux bootloader and precursor to Kenrel EFISTUB support. It is considered to be a alpha quality software (as on 16-MAY-2012). Upstream sources are at https://github.com/mfleming/efilinux . and the usage instructions are at http://thread.gmane.org/gmane.linux.kernel/1172645 and http://article.gmane.org/gmane.linux.kernel/1175060 . AUR packages - {{Pkg|efilinux-efi}} and {{AUR|efilinux-efi-x86_64-git}} (only for x86_64 UEFI).<br />
<br />
== Package Naming Guidelines ==<br />
<br />
UEFI bootloader package(s) should be suffixed with {{ic|-efi-x86_64}} or {{ic|-efi-i386}} to denote package built for 64-bit and 32-bit UEFI respectively. If a single package contains both 64-bit and 32-bit UEFI applications, then {{ic|-efi}} suffix should be used in the '''pkgname'''.<br />
<br />
== See also ==<br />
<br />
* [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]<br />
* [http://www.rodsbooks.com/refind/ Rod Smith - rEFInd, a fork or rEFIt]<br />
* [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD Linux Kernel Documentation on EFISTUB]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=291f36325f9f252bd76ef5f603995f37e453fc60;hp=55839d515495e766605d7aaabd9c2758370a8d27 Linux Kernel EFISTUB Git Commit]<br />
* [http://www.rodsbooks.com/efi-bootloaders/efistub.html Rod Smith's page on EFISTUB]<br />
* [http://www.rodsbooks.com/refind/linux.html rEFInd Documentation for booting EFISTUB Kernels]</div>Denoysehttps://wiki.archlinux.org/index.php?title=UEFI_Bootloaders&diff=247421UEFI Bootloaders2013-02-15T16:03:55Z<p>Denoyse: </p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[zh-CN:UEFI Bootloaders]]<br />
This page contains info about various [[UEFI]] Bootloaders capable of booting Linux kernel. It is recommended to read the [[UEFI]] and [[GPT]] pages before reading this page. The following [[Boot Loader|bootloaders]] (listed in decreasing order of stability) are explained here:<br />
<br />
== Linux Kernel EFISTUB ==<br />
<br />
Linux (Kernel >= 3.3) supports {{ic|EFISTUB (EFI BOOT STUB)}} booting. It is enabled by by default on Arch Linux kernels or can be activated by setting {{ic|CONFIG_EFI_STUB&#61;y}} in the Kernel configuration (see [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD The EFI Boot Stub] for more information).<br />
<br />
A single EFISTUB kernel is not capable of launching other kernels, hence each EFISTUB Kernel + Initramfs pair requires a separate boot menu entry. It is recommended to use a UEFI Boot Manager to manage multiple kernels.<br />
<br />
=== Setting up EFISTUB ===<br />
<br />
#[https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Create_an_UEFI_System_Partition_in_Linux Create a FAT32 UEFI System Partition]<br />
# Mount the UEFI System Partition at {{ic|/boot/efi}} with {{ic|# mount <UEFI Partition /boot/efi}}<br />
# Create {{ic|/boot/efi/EFI/arch/}} directory with {{ic|# mkdir /boot/efi/EFI/arch/}}<br />
# Copy the following files from source to destination<br />
{| border="1"<br />
!Boot File Source!!UEFI Destination<br />
|-<br />
| /boot/vmlinuz-linux || /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
|-<br />
| /boot/initramfs-linux.img || /boot/efi/EFI/arch/initramfs-arch.img<br />
|-<br />
| /boot/initramfs-linux-fallback.img || /boot/efi/EFI/initramfs-arch-fallback.img<br />
|}<br />
<br />
=== Sync EFISTUB Kernel ===<br />
{{Warning|The EFISTUB Kernel must be updated each time the kernel is updated (follow step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]. Failure to do so will result in failure to boot. Alternatively one can automatically update the EFISTUB kernel using one of the following methods:}}<br />
<br />
{{Note| As of [https://www.archlinux.org/packages/extra/any/refind-efi/ refind-efi 0.6.5], refind now automatically detects kernels in {{ic|/boot}}. They do not have to be renamed to have a {{ic|.efi}} extension either. Hence, the following sync scripts aren't needed if using [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_rEFInd refind].}}<br />
<br />
==== Systemd ====<br />
[[Systemd]] features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in {{ic|boot}}.<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.path}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Copy EFISTUB Kernel to UEFISYS Partition<br />
<br />
[Path]<br />
PathChanged=/boot/vmlinuz-linux<br />
PathChanged=/boot/initramfs-linux.img<br />
PathChanged=/boot/initramfs-linux-fallback.img<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/systemd/system/efistub-update.service}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Copy EFISTUB Kernel to UEFISYS Partition<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
ExecStart=/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img<br />
ExecStart=/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img<br />
</nowiki>}}<br />
<br />
{{Tip|Enable these services with<br />
{{bc|<nowiki><br />
# systemctl enable efistub-update.path<br />
</nowiki>}}}}<br />
<br />
==== Incron ====<br />
{{Pkg|incron}} can run a script to sync the EFISTUB Kernel after updates<br />
<br />
{{Tip|Save the following script as {{ic|/usr/local/bin/efistub-update.sh}}}}<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
/bin/cp -f /boot/vmlinuz-linux /boot/efi/EFI/arch/vmlinuz-arch.efi<br />
/bin/cp -f /boot/initramfs-linux.img /boot/efi/EFI/arch/initramfs-arch.img<br />
/bin/cp -f /boot/initramfs-linux-fallback.img /boot/efi/EFI/arch/initramfs-arch-fallback.img<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/etc/incron.d/efistub-update.conf}}}}<br />
{{Note|The first parameter {{ic|/boot/initramfs-linux-fallback.img}} is the file to watch. The second parameter {{ic|IN_CLOSE_WRITE}} is the action to watch for. The third parameter {{ic|/usr/local/bin/efistub-update.sh}} is the script to execute.}}<br />
{{bc|<nowiki><br />
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update.sh<br />
</nowiki>}}<br />
<br />
{{Tip|In order to use this method, incron must be activated, if it is not run<br />
{{bc|<nowiki><br />
# systemctl enable incrond.service<br />
</nowiki>}}}}<br />
<br />
==== Mkinitcpio hook ====<br />
Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of {{ic|vm-linuz}}, {{ic|initramfs-linux.img}}, and {{ic|initramfs-linux-fallback.img}}; then follows step 4 in [https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Setting_up_EFISTUB Setting up EFISTUB]<br />
<br />
{{Tip|Save the following script as {{ic|/usr/lib/initcpio/install/efistub-update}}}}<br />
{{bc|<nowiki><br />
#!/usr/bin/env bash<br />
<br />
build() {<br />
local kernel= image=<br />
while getopts ':c:S:' OPT; do<br />
case $OPT in<br />
'c') kernel=$OPTARG;;<br />
'S') image=$OPTARG;;<br />
esac<br />
done<br />
<br />
/root/watch.sh $image $kernel &<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook simply waits for mkinitcpio to finish and copies the finished ramdisk and kernel to UEFI<br />
HELPEOF<br />
}<br />
<br />
# vim: set ft=sh ts=4 sw=4 et:<br />
</nowiki>}}<br />
<br />
{{Tip|Save the following script as {{ic|/root/watch.sh}}}}<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
EFI_DIR="/boot/efi/EFI/arch"<br />
<br />
INITRD=$1<br />
KERNEL=$2<br />
<br />
EFI_IMAGE="$EFI_DIR/${KERNEL##*/}.efi"<br />
EFI_INITRD="$EFI_DIR/${INITRD##*/}"<br />
<br />
while [[ -d "/proc/$PPID" ]]; do<br />
sleep 1<br />
done<br />
<br />
cp $INITRD $EFI_INITRD<br />
cp $KERNEL $EFI_IMAGE<br />
echo "Synced $INITRD to $EFI_DIR"<br />
</nowiki>}}<br />
<br />
{{Tip|Add {{ic|efistub-update}} to the list of hooks in {{ic|/etc/mkinitcpio.conf}}}}<br />
<br />
=== Booting EFISTUB ===<br />
<br />
{{Warning|Linux Kernel EFISTUB booting uses {{ic|\}} instead of {{ic|/}} and should be relative to the UEFI System Partition's root. For example, if the initramfs is located in {{ic|/boot/efi/EFI/arch/initramfs-linux.img}}, the corresponding UEFI formatted line would be {{ic|\EFI\arch\initramfs-linux.img}}. Failure to convert the options will lead to a system hang without any error message from the firmware or kernel.}}<br />
<br />
One can boot the EFISTUB kernel using one of the following ways :<br />
<br />
==== Using rEFInd ====<br />
<br />
rEFInd is a fork of rEFIt Boot Manager (used in Intel Macs) by Rod Smith (author of GPT-fdisk). rEFInd fixes many issues in rEFIt with respect to non-Mac UEFI booting and also has support for booting EFISTUB kernels and contains some features specific to them. More info about rEFInd support for EFISTUB is at [http://www.rodsbooks.com/refind/linux.html The rEFInd Boot Manager: Methods of Booting Linux].<br />
<br />
# Install {{Pkg|refind-efi}} package with {{ic|# pacman -S refind-efi}}<br />
# Copy the following files from their source directory to their destination<br />
{{Note|1=<arch> is the bit architecture of the system. Run {{ic|$ uname -m}} to get the architecture. Replace <arch> with "ia32" for 32 bit systems, and <arch> with "x64" for 64 bit systems.}}<br />
{| border="1"<br />
!rEFInd File Source!!UEFI Destination<br />
|-<br />
| /usr/lib/refind/refind_<arch>.efi || /boot/efi/EFI/refind/refind_<arch>.efi<br />
|-<br />
| /usr/lib/refind/config/refind.conf || /boot/efi/EFI/refind/refind.conf<br />
|-<br />
| /usr/share/refind/icons || /boot/efi/EFI/refind/icons<br />
|}<br />
<br />
{{Tip|Refind's configuration file is located in {{ic|/boot/efi/EFI/refind/refind.conf}}. The file is well commented.}}<br />
<br />
{{Note|As of {{Pkg|refind-efi}} 0.6.5-1, refind can auto-detect kernels in {{ic|/boot}}, if there are UEFI drivers for the filesystem used by /boot partition (or / partition if no separate /boot is used) in the ESP, and are loaded by rEFInd. To enable rEFInd to detect and load the drivers and /boot kernels you must enable the appropriate options in {{ic|refind.conf}} (mainly mention the PATH for the drivers location in the ESP) and also copy your {{ic|refind_linux.conf}} to {{ic|/boot/refind_linux.conf}} .}}<br />
<br />
{{Tip|Pass kernel specific commands by copying {{ic|/usr/lib/refind/config/refind_linux.conf}} to {{ic|/boot/efi/EFI/arch/refind_linux.conf}}. This file should be located in the same directory as the EFISTUB kernel. Edit the configuration file to be similar to the template below. Replace the string after PARTUIID with your root's PARTUIID}}<br />
{{Note|Please notice the difference between the standard UUID and the PARTUUID shown by {{ic|$ ls -l /dev/disk/by-partuuid/}}}}<br />
{{hc|$esp/EFI/arch/refind_linux.conf|<nowiki><br />
"Boot with defaults" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=graphical.target"<br />
"Boot to Terminal" "root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap systemd.unit=multi-user.target"</nowiki>}}<br />
<br />
{{Tip|Each line of {{ic|refind_linux.conf}} is displayed as a submenu by rEFInd. Access the submenu with "+" or "insert" keys.}}<br />
<br />
{{Tip|In non-Mac systems, create an entry for rEFInd using [[UEFI#efibootmgr|efibootmgr]] where sdX is the UEFI disk, and Y is the UEFI partition number. Run :<br />
{{bc|<nowiki><br />
# modprobe efivars<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "rEFInd" -l '\EFI\refind\refind_<arch>.efi'<br />
</nowiki>}}}}<br />
<br />
===== Systemd Automation =====<br />
{{Tip|To automate the process of copying refind files and updating the nvram (if needed) use the following script}}<br />
<br />
{{Note|Save this script as {{ic|/usr/lib/systemd/scripts/refind_name_patchv2}}}}<br />
{{Tip|If you want to change the directory that refind is installed in the UEFISYS partition, just change the value of $refind_dir in the script}}<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
## COPYRIGHT 2013 : MARK E. LEE (BLUERIDER) : mlee24@binghamton.edu; mark@markelee.com<br />
<br />
## LOG<br />
## 1/17/2013 : Version 2 of refind_name_patch is released<br />
## : Supports long subdirectory location for refind<br />
## : Updates nvram when needed<br />
## : 10% speed boost<br />
<br />
function main () { ## main insertion function<br />
declare -r refind_dir="/boot/efi/EFI/refind"; ## set the refind directory<br />
declare -r arch=$(uname -m | awk -F'_' '{if ($1 == "x86"){print $2}}') && ## get bit architecture<br />
update-efi-dir; ## updates or creates the refind directory<br />
update-efi-nvram; ## updates nvram if needed<br />
}<br />
<br />
function update-efi-dir () { ## setup the refind directory<br />
if [ ! -d $refind_dir ]; then ## check if refind directory exists<br />
echo "Couldn't find $refind_dir";<br />
mkdir $refind_dir && ## make the refind directory if needed<br />
echo "Made $refind_dir";<br />
fi;<br />
if [ "$arch" ]; then ## check if anything was stored in $arch<br />
cp -r /usr/{share/refind/*,lib/refind/*$arch*} $refind_dir/ && ## update bin and dirs<br />
echo "Updated binaries and directory files for refind at $refind_dir";<br />
else<br />
echo "Failed to detect an x86 architecture";<br />
exit;<br />
fi;<br />
}<br />
<br />
function update-efi-nvram () { ## update the nvram with efibootmgr<br />
declare -r ref_bin=${refind_dir/\/boot\/efi}/$(ls /usr/lib | grep $arch*.efi); ## get path of refind binary (without /boot/efi)<br />
declare -r ref_bin_escape=${ref_bin//\//\\\\}; ## insert escape characters into $ref_bin<br />
modprobe efivars && ## grab the efi variables for efibootmgr<br />
efibootmgr -v | grep $ref_bin_escape && ( ## check if boot entry is in nvram<br />
echo "Found boot entry, no need to update nvram";<br />
) || ( ## if boot entry is not in nvram; add it<br />
declare -r esp=$(mount -l | awk '/ESP/ {print $1}') && ## get ESP partition<br />
efibootmgr -c -g -d ${esp:0:8} -p ${esp:8} -w -L "rEFInd" -l $ref_bin_escape && ## update nvram<br />
echo "<br />
Updated nvram with entry rEFInd to boot $ref_bin<br />
Did not copy configuration files, please move refind.conf to $refind_dir/";<br />
)<br />
}<br />
<br />
main; ## run the main insertion function<br />
</nowiki>}}<br />
<br />
{{Note|Save the following service file as {{ic|/usr/lib/systemd/system/refind_update.path}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Update rEFInd bootloader files<br />
<br />
[Path]<br />
PathChanged=/usr/lib/refind/refind_<arch>.efi<br />
Unit=refind_update.service<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Note|Save the following service file as {{ic|/usr/lib/systemd/system/refind_update.service}}}}<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Update rEFInd directories, binaries, and nvram<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/bash /usr/lib/systemd/scripts/refind_name_patchv2<br />
RemainAfterExit=no<br />
</nowiki>}}<br />
<br />
{{Tip|Enable the systemd path unit by running :<br />
{{bc|<nowiki><br />
# systemctl enable refind_update.path;<br />
</nowiki>}}}}<br />
<br />
===== Apple Macs =====<br />
<br />
In case of Apple Macs, try {{AUR|mactel-boot}} for an experimental "bless" utility for Linux. If that does not work, use "bless" form within OSX to set rEFInd as default bootloader. Assuming UEFISYS partition is mounted at {{ic|/mnt/efi}} within OSX, do<br />
<br />
$ sudo bless --setBoot --folder /mnt/efi/EFI/refind --file /mnt/efi/EFI/refind/refind_x64.efi<br />
<br />
===== VirtualBox =====<br />
<br />
In case of VirtualBox, see [[VirtualBox#Using_Arch_under_Virtualbox_EFI_mode]].<br />
<br />
==== Using gummiboot ====<br />
<br />
[[Gummiboot]] is a UEFI Boot Manager which provides a nice menu for EFISTUB Kernels. It is a new program and relatively untested compared to rEFInd . It is available in [extra] as {{Pkg|gummiboot-efi}}. See http://freedesktop.org/wiki/Software/gummiboot for more info.<br />
<br />
==== Using UEFI Shell ====<br />
<br />
It is possible to launch EFISTUB kernel form UEFI Shell as if it is a normal UEFI application. In this case the kernel parameters are passed as normal parameters to the launched EFISTUB kernel file.<br />
<br />
> fs0:<br />
> cd \EFI\arch<br />
> vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img<br />
<br />
You can also write a simple {{ic|archlinux.nsh}} file with your boot parameters and put it in your UEFI System Partition, then run it with:<br />
<br />
fs0:<br />
archlinux<br />
<br />
Example Script:<br />
<br />
echo -on<br />
\EFI\arch\vmlinuz-arch.efi root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img<br />
<br />
This way you can specify UUID's without needing to remember the name or type out 20-30 characters.<br />
<br />
==== Using efibootmgr entry ====<br />
<br />
{{Note|1=This menthod may not work due to [https://git.kernel.org/?p=linux/kernel/git/mfleming/efi.git;a=commitdiff;h=b003aaf799c991295b8b73e8f940d20bda2c1bbb;hp=ddffeb8c4d0331609ef2581d84de4d763607bd37 limitations in how the kernel handles uefi runtime variables]. For example in Lenovo Thinkpads the initrd path is truncated (verified using {{ic|efibootmgr -v}} command) and therefore the kernel fails to boot.}}<br />
<br />
{{Note|Some UEFI firmwares may not support embedding command line parameters to uefi applications in the boot entries.}}<br />
<br />
It is possible to directly embed the kernel parameters within the boot entry created by efibootmgr. This means that in your BIOS/UEFI you will be able to select Arch Linux directly in the default boot order, and on startup it will boot into Arch directly without any kind of boot selection GUI.<br />
<br />
Do (as root):<br />
<br />
Install efibootmgr if you haven't already.<br />
# pacman -S --needed efibootmgr<br />
<br />
Determine the UUID or PARTUUID of your boot device (ie. the partition for {{ic|/}}, not the EFI boot partition)<br />
# blkid<br />
<br />
Load the EFI module.<br />
# modprobe efivars<br />
<br />
Finally, add the efistub.<br />
WARNING: Make sure you replace the following before running this command:<br />
* ''3518bb68-d01e-45c9-b973-0b5d918aae96'' -- with the UUID of your {{ic|/}} partition. (This is not PARTUUID!)<br />
* ''ext4'' -- if you use a different file system.<br />
* ''/dev/sda'' -- the drive that contains the EFI boot partition.<br />
* ''-p 1'' -- the partition number of the EFI boot partition.<br />
# echo 'root=UUID=3518bb68-d01e-45c9-b973-0b5d918aae96 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img' | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -@ -<br />
<br />
or you can just run the following line (remember to replace /dev/sda1):<br />
<br />
# echo "root=UUID=$(blkid /dev/sda1 -o value -s UUID) ro rootfstype=ext4 add_efi_memmap initrd=\\EFI\\arch\\initramfs-arch.img" | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -@ -<br />
<br />
{{Note|The trailing hyphen after {{ic|--append-binary-args}} or {{ic|-@}} is required to instruct efibootmgr to read the parameters from STDIN (standard input). The code should be {{ic|--append-binary-args -}} or {{ic|-@ -}} .}}<br />
<br />
More info about efibootmgr at [[UEFI#efibootmgr]]. Forum post https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 .<br />
<br />
{{Note|Some firmwares may have trouble with the "initrd path" when piping in ucs-2 as shown above. In this case, one may put vmlinuz-linux.efi and the initramfs in the root of the ESP and adjust the efibootmgr entry accordingly.}}<br />
<br />
== GRUB 2.x ==<br />
<br />
GRUB 2.x contains its own filesystem drivers and does not rely on the firmware to access the files. It can directly read files from {{ic|/boot}} and does not require the kernel and initramfs files to be in the UEFISYS partition. Detailed information at [[GRUB#UEFI_systems_2]]. For bzr development version try AUR package - {{AUR|grub-efi-x86_64-bzr}}.<br />
<br />
== SYSLINUX ==<br />
<br />
{{Note|Syslinux UEFI support is currently part of version 6.00-preXX or in firmware branch of upstream git repo. It is considered alpha quality by upstream. The below information is provided mainly to enable bug-testing. Please report all issues upstream.}}<br />
<br />
{{Note|Syslinux UEFI can boot only those kernels that support '''EFI Handover Protocol'''. Thus LTS kernels are not supported.}}<br />
<br />
Install {{AUR|syslinux-efi-git}} AUR package and copy {{ic|/usr/lib/syslinux/efi64/*}} to {{ic|$esp/EFI/syslinux/}} ({{ic|$esp}} is the mountpoint of UEFISYS partition) ({{ic|efi64}} is for x86_64 UEFI firmwares, replace with {{ic|efi32}} for i386 UEFI firmwares), and then create a boot entry using efibootmgr in the firmware boot manager.<br />
<br />
== ELILO ==<br />
<br />
ELILO is the UEFI version of LILO Boot Loader. It was originally created for Intel Itanium systems which supported only EFI (precursor to UEFI). It is the oldest UEFI bootloader for Linux. It is still in development but happens at a very slow pace. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ . Elilo config file {{ic|elilo.conf}} is similar to [[LILO]]'s config file. AUR package - {{AUR|elilo-efi-x86_64}} (only for x86_64 UEFI).<br />
<br />
== EFILINUX ==<br />
<br />
EFILINUX is a reference implementation of a UEFI Linux bootloader and precursor to Kenrel EFISTUB support. It is considered to be a alpha quality software (as on 16-MAY-2012). Upstream sources are at https://github.com/mfleming/efilinux . and the usage instructions are at http://thread.gmane.org/gmane.linux.kernel/1172645 and http://article.gmane.org/gmane.linux.kernel/1175060 . AUR packages - {{Pkg|efilinux-efi}} and {{AUR|efilinux-efi-x86_64-git}} (only for x86_64 UEFI).<br />
<br />
== Package Naming Guidelines ==<br />
<br />
UEFI bootloader package(s) should be suffixed with {{ic|-efi-x86_64}} or {{ic|-efi-i386}} to denote package built for 64-bit and 32-bit UEFI respectively. If a single package contains both 64-bit and 32-bit UEFI applications, then {{ic|-efi}} suffix should be used in the '''pkgname'''.<br />
<br />
== See also ==<br />
<br />
* [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]<br />
* [http://www.rodsbooks.com/refind/ Rod Smith - rEFInd, a fork or rEFIt]<br />
* [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD Linux Kernel Documentation on EFISTUB]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=291f36325f9f252bd76ef5f603995f37e453fc60;hp=55839d515495e766605d7aaabd9c2758370a8d27 Linux Kernel EFISTUB Git Commit]<br />
* [http://www.rodsbooks.com/efi-bootloaders/efistub.html Rod Smith's page on EFISTUB]<br />
* [http://www.rodsbooks.com/refind/linux.html rEFInd Documentation for booting EFISTUB Kernels]</div>Denoysehttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=229661Talk:Dm-crypt2012-10-19T15:02:50Z<p>Denoyse: </p>
<hr />
<div>== Cleanup and Clarification ==<br />
Hello. This wiki page while very exhaustive in content is tangenital with a fractured flow. It seems the prefered method for straight forward system encryption in single drive systems is to use a combination of Luks and LVM2 - this solution provides for an encrypted swap that does not have any issues with hibernation or suspend. I propose making this section the first part of the wiki page to follow the justification for using Luks with the rather large volume of detailed information to follow in other sections. If there are no objections I'll go ahead and structure this in the wiki page itself.<br />
[[User:Vinhsynd|Vinhsynd]] 9:55, 30 September 2010 (CDT)<br />
<br />
Hey all, I was trying to encrypt my hd using this page as a reference, but it was a bit difficult to read. As such, I'm going to try to clean things up a bit. It would be nice if there were a clean set of instructions with tips along the way for specialized setups.<br />
<br />
On a related note... would anyone mind if some of the posts on this page were erased? There are a number of posts from 2007, 2008...<br />
--[[User:Arcanazar|Arcanazar]] 13:22, 21 August 2010 (EDT)<br />
<br />
I'm considering to do some editing and rewriting of this page, mainly in part "4 The Steps". The content would mostly stay the same, safe for some changes introduced with the newer versions of arch, where less console switching and module loading is needed. On the same subject should we drop, or move to a subsection, the parts related to versions 0.72 of arch?<br />
<br />
Does anyone have objections to my plans, or should I just go ahead and we can revert back if it doesn't fit?<br />
[[User:WhiteMagic|WhiteMagic]] 12:56, 24 May 2007 (EDT)<br />
<br />
: Clean up is really needed. Please someone with enough knowledge start the job. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 02:55, 8 June 2012 (UTC)<br />
<br />
:: Someone review the made changes to clean up. Suggested next bits to clean-up should include removing legacy Grub section after making sure the relevant kernel parameters are adequately covered in the Grub2 paras. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:14, 26 September 2012 (UTC)<br />
<br />
== Discard/TRIM support for solid state disks (SSD) ==<br />
Does leaving half the drive unpartitioned (to manually resize partition-table, LUKS and filesystems when needed) ease problems?<br />
:That's an interesting question. Before the TRIM feature was added, this was the general advice to avoid degrading SSD performance over time due. I am not aware of a general answer to this, particularly since SSDs chipsets evolve considerably still. If someone has a link to up-to-date information (e.g. a comparison of pros/cons of discard and leaving empty space on a drive) that is very worthwile adding in my opinion. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:34, 30 September 2012 (UTC)<br />
Altough the security limitation topic is already explained within other sections above I think there should be a small but explicit WarningBox about Discard/TRIM as once there already was. --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 12:38, 28 September 2012 (UTC)<br />
:The first two paras of that SSD trim section '''only''' talk about the security impacts and why it is not default. In my opinion that is enough. Add a regular sentence ala "As explained above in section ...", if you really feel it necessary. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:06, 29 September 2012 (UTC) I have added another sentence & link regarding TRIM issues, have a look if its better now in your view also. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:01, 2 October 2012 (UTC)<br />
<br />
== Suspend to disk instructions are insecure ==<br />
They cause the swap encryption key to be picked up by mkinitcpio and stored on the unencrypted /boot partition, thus rendering the encryption useless. Better still, the suspend image contains the keys for any other encrypted partitions that were currently open too...<br />
<br />
Unless someone thinks otherwise, I'm going to remove the stuff about key files and replace it with a warning not to do that. I think the approach using a password should be secure, and it's somewhat workable (at least in my setup with uresume): we can place the 'openswap' and 'uresume' hooks ''before'' 'encrypt' and rely on the above-mentioned keys in the suspend image to magically have the root unlocked once the resume is complete. Downside is typing two passwords during a normal boot - it's a quick fix for the current instructions at any rate.<br />
<br />
There are a few other options, but probably the tidiest strategy would be to put root and swap (and anything else) on an encrypted LVM PV, then the 'encrypt' hook can unlock everything in one go. I guess that makes a mess if the VG contain other PVs which need decrypting too, but that's probably not an issue at least for laptop users. I've not tried this though.<br />
<br />
Of course, ideally there'd be support for multiple volumes (preferably with a single password prompt) in the 'encrypt' hook.<br />
<br />
--[[User:Jmawebb|Jmawebb]] 19:44, 27 February 2010 (EST)<br />
<br />
:Is there a fix for this yet? Maybe the luksSuspend function? --[[User:Revelation60|Revelation60]] 21:21, 20 December 2010 (GMT+1)<br />
<br />
== Luks and suspend2 ==<br />
Would it be worth adding a section on opening encrypted drives from the kernel command line, or more specifically on combining luks and suspend2? As far as I can tell opening a swap partition from crypttab doesn't make it available in time to resume from, but adding the following to a lilo append option does:<br />
resume2=swap:/dev/mapper/swap cryptdevice=/dev/sda2:swap<br />
I'm not sure if this is the correct/best way of doing this, though, and didn't see other documentation.<br />
<br />
== New cipher mode ==<br />
Kernel 2.6.24 supports "aes-xts-plain" (instead of "cbc" or "lrw"). Waiting for kernel 2.6.24 to reach [core] (and new CD version), stay tuned :-) [[User:Ekerazha|ekerazha]] 09:00, 6 February 2008 (EST)<br />
:Sounds cool.<br />
<br />
:If you can't wait you can get a livecd that has a 2.6.24 kernel (such as the [http://cdimage.ubuntu.com/daily-live/current/ daily builds of ubuntu]). It worked for me. --[[User:inthemedium|inthemedium]] 10:14, 6 February 2008 (EST)<br />
:'''Question:''' [http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/2585 xts-plain VS xts-benbi] --[[User:Ekerazha|ekerazha]] 09:13, 13 April 2008 (EDT)<br />
:: -plain is the good one (specs: [http://grouper.ieee.org/groups/1619/email/pdf00086.pdf aes-xts-plain_specs.pdf from grouper.ieee.org]) --[[User:Ekerazha|ekerazha]] 13:00, 16 April 2008 (EDT)<br />
<br />
:::Note that after [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&oldid=225227#Prepare_hard_drive_for_Arch_Install_Scripts 26.09.2012 (revision 225227)] the default luksFormat Instructions were [https://wiki.archlinux.org/index.php?title=Dm-crypt_with_LUKS&diff=225278&oldid=225227 changed] back to cryptsetup's compiled in vanilla defaults. (aes-cbc-essiv / sha1) This has advantages in compatibility with older cryptsetup versions.<br />
:::'''explanatory statement:'''"Change luksFormat to default compiled in cypher, less typing for everyone, less CPU overhead and default for a reason."<br />
<br />
:::I added a table comparing and explaining the default options for a LUKS container with one single passphrase keyslot against example options in the [[#Using_LUKS_to_Format_Partitions_with_a_Passphrase]]-section.<br />
<br />
:::Everyone is welcome to adopt it in the keyfile or other sections on corresponding options. The [[Wikipedia:Help:Table|format]] of the table is yust screwed together, improvements would be great!<br />
<br />
:::'''Question:''' I think the {{ic|-y}} switch is deprecated as it '''is''' the compiled-in default at least for cryptsetup >=1.5. --[[User:Nonix|Nonix]] ([[User talk:Nonix|talk]]) 03:03, 27 September 2012 (UTC)<br />
::::'''Comment:''' Yeah, I tried it also, it seems to default to "y". I also looked at the google code revision, but could not find adhoc a definite statement plus in the current manpage it is still advised to use "y" with luksFormat. That's why I think we better leave that in for now not to provoke easy user errors. Thanks for looking over it!! (I was actually writing it up a couple of weeks after doing it - do correct what you think has to change. Thanks) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:52, 27 September 2012 (UTC)<br />
<br />
== Proposed update of the section 'Storing the key between MBR and 1st partition' ==<br />
{| style="background-color: #f3f9ff; margin: 1em 2.5% 0 2.5%; padding: 3px 3px; border: 1px solid #aaa;"<br />
|-<br />
|'''Background'''<br />
<br />
I tried to setup automatic mount of my LUKS encrypted {{ic|/home}} using a keyfile stored between MBR and first partition header of my USB key following this wiki page and realized that it didn't work out because the howto is incomplete. I had to manually go through the encrypt hook to figure out what it does. To save other users this tiresome work that cost me hours until all finally worked out the way I wanted it I propose to update the mentioned section in the following way. Suggestions welcome. Maybe it should be noted in the parent section that {{ic|/etc/crypttab}} conflicts with using the howto presented here.<br />
|}<br />
<br />
Add the temporary keyfile we created before with cryptsetup:<br />
cryptsetup luksAddKey /dev/hda3 secretkey<br />
<br />
That should return you output like this:<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
Next you'll have to write the key directly between MBR and first partition.<br />
<br />
WARNING: you should only follow this step if you know what you are doing - '''it can cause data loss and damage your partitions or MBR on the stick!'''<br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. GRUB needs the first 16 sectors, you would have to replace seek=4 with seek=16; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
''Optional''<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey:<br />
shred --remove --zero secretkey<br />
You should not simply use rm as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} (GRUB), it should look something like this:<br />
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048 cryptdevice=/dev/hda4:home<br />
Format for the cryptkey option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
OFFSET and SIZE match in this example, but this is coincidence - they can differ (and often will). An other possible example could be (if you use skip=16 in the 'dd' command above to protect the bootloader)<br />
kernel /vmlinuz-linux root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048 cryptdevice=/dev/hda4:home<br />
Format for the cryptdevice option:<br />
cryptdevice=BLOCKDEVICE:MAPPING_TARGET<br />
The encrypted block device BLOCKDEVICE will then be mapped to {{ic|/dev/mapper/MAPPING_TARGET}}<br />
<br />
'''Note:''' You will _not_ need to have {{ic|/etc/crypttab}} setup for this device then (but maybe you want to use it for other encrypted devices where you want to enter the passphrase manually or e.g. use a keyfile stored on this afterwards decrypted partition)! But don't forget to activate the ''encrypt'' hook in {{ic|/etc/mkinitcpio.conf}} (_before_ the ''filesystems'' hook)<br />
<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup of volume header ==<br />
I think that its important to backup headers of your volumes. This should be mentioned in the wiki imo.<br />
<br />
== LVM2 and LUKS ==<br />
I'm quite sure this section is misleading. You have to setup up encryption ''before'' LVM2 partitions on the decrypted device.<br />
<br />
And you have to add the "encrypt" hook ''before'' the "lvm2" hook, because you need to make the decrypted device available before LVM2 imports volume groupe and makes logical volumes available.<br />
<br />
Yet this chapter tends to tell the other way round. Is my English so bad ?<br />
<br />
I agree.. I find this entire wiki article unnecessarily complicated .. this link for an LVM on top of an encrypted partition is MUCH!!! easier to follow, and for a laptop would be better. [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
- This section is misleading. What the author meant was if you encrypt the contents of LVM partitions, THEN you have to move the lvm2 hook before the encrypt hook. I made a few small changes, so other newbies (like me) don't end up with an unbootable system.<br />
<br />
-- I also agree that the section needs a further overhaul, assuming here everyone commenting means the "Encrypting and LVM Setup" (because "LVM2 and LUKS" is not in the TOC). Having encrypt over (i.e. before) LVM is def the typical and easiest setup (and this should be expanded on more clearly in the wiki like in the link above I agree). However, all methods have a usecase. It depends what the user wants to achieve. Time permitting, the differences should be worked out. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:53, 18 September 2012 (UTC)<br />
<br />
== Prepare hard drive ==<br />
The actual text is:<br />
<br />
Skip the Partitioning and Auto-Prepare business and go straight to "Set Filesystem Mountpoints". When asked for your {{ic|/}} (root) partition, do NOT select {{ic|/dev/sda3}} as you normally would. Select {{ic|/dev/mapper/root}} instead. Similarly, use {{ic|/dev/mapper/home}} instead of {{ic|/dev/sda4}} as the partition to be mounted as {{ic|/home}}. The same is valid for a swap partition which is set up like the home partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition or else the installer will not properly set up the bootloader. <br />
<br />
but the Arch Linux installer says:<br />
[code]<br />
/dev/sda1<br />
/dev/sda2<br />
/dev/mapper/root<br />
/dev/mapper/lvm-home<br />
/dev/mapper/lvm-root<br />
/dev/mapper/lvm-swap<br />
/dev/mapper/lvm-tmp<br />
[/code]<br />
When asked for {{ic|/}} (root) partition: is it {{ic|/dev/mapper/root}} or {{ic|/dev/mapper/lvm-root}}. I suppose it is the first one because the second one does not match.<br />
<br />
== Decryption of root during boot with the assistance of UDEV when key is stored on USB drive between MBR and 1st Partition ==<br />
The instructions in the wiki were very helpful but a bit confusing/lacking when it comes to getting Decryption via USB keyfile stored between MBR and 1st Partition.<br />
<br />
[[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] makes references to {{ic|/dev/usbkey}} but the previous instructions aren't entirely clear on how to ensure your usb drive can always be found at this location.<br />
<br />
When modifying your bootloader you will be unable to use ''/dev/disk/by-uuid'' because you are not referencing a filesystem. You wouldn't want to use ''/dev/sd[x]'' because this can and will change depending on what other drives and media you have connected during boot. The best bet is to create a udev rule that will exist in early userspace to alias your usb drive to an arbitrary name, in this case "usbkey". The rule must be added to the initial ramdisk so it can be read and processed to alias your drive at ''/dev/usbkey'' before root decryption is attempted via the key hidden on the drive.<br />
<br />
[[System_Encryption_with_LUKS#Using_udev]] runs you through the initial steps you need to create a basic rule based on the USB drive's serial number. That is the very same rule I used. I named the rules file "62-usbkey.rules" and placed it in {{ic|/etc/udev/rules.d/}}.<br />
<br />
Now modify {{ic|/etc/mkinitcpio.conf}}, look for the "FILES" section and add the udev rule that you created above:<br />
<br />
<pre><br />
# FILES<br />
# This setting is similar to BINARIES above, however, files are added<br />
# as-is and are not parsed in any way. This is useful for config files.<br />
# Some users may wish to include modprobe.conf for custom module options<br />
# like so:<br />
# FILES="/etc/modprobe.d/modprobe.conf"<br />
FILES="/etc/udev/rules.d/62-usbkey.rules"<br />
</pre><br />
<br />
Run ''mkinitcpio'' ala [[Mkinitcpio#Image_creation_and_activation]] and rebuild your ramdisk with the new udev rule you've included. You can now continue to follow the instructions in [[System_Encryption_with_LUKS#Storing_the_key_between_MBR_and_1st_partition]] to modify your bootloader and substitute references to "usbkey" to whatever you named your drive alias above.<br />
<br />
[[User:S0ma|S0ma]] 13:48, 16 December 2011 (EST)<br />
<br />
== Specifying skip and count in /etc/crypttab for /tmp ==<br />
In this wiki article, [[Dm-crypt_with_LUKS#.2Fetc.2Fcrypttab]], you're advised to put the following in your /etc/crypttab<br />
<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
But doing that will not work. More specifically in /etc/rc.d/functions:do_unlock() in switch case /dev/*. After debugging with some `set -x`:es I found that if you specify the dd count and skip parameters in crypttab it will work i.e., e.g.,<br />
<br />
tmp /dev/lvm/tmp /dev/urandom:0:2048 -c aes-xts-plain -s 512<br />
<br />
If this is how it should be done I propose a change in the wiki to consider this. If not, do_unlock() is strange.<br />
--[[User:Erikw|Erikw]] ([[User talk:Erikw|talk]]) 16:40, 17 July 2012 (UTC)<br />
<br />
:Please add [[Template:Accuracy]] if you're not sure of something and want some feedback. I'm sorry but I can't help you on this now :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:19, 18 July 2012 (UTC)<br />
<br />
::Oh I was not aware of this. It's added now. Thanks. --[[User:Erikw|Erikw]] ([[User talk:Erikw|talk]]) 18:54, 18 July 2012 (UTC)<br />
<br />
:After the latest update with systemd-cryptsetup this syntax is deprecated. Probably the whole wiki article should be reviewed and use the "new" syntax.--[[User:Erikw|Erikw]] ([[User talk:Erikw|talk]]) 23:53, 3 August 2012 (UTC)<br />
<br />
== GRUB-Legacy/GRUB2 changes regarding the Kernel Line ==<br />
Since GRUB-Legacy doesn't play that much of a role anymore it'd be advisable to exchange the explainations for adjusting the kernel line in the bootloader to the procedure used in GRUB2.<br />
<br />
For example @ the last step of #With_suspend-to-disk_support<br />
<br />
<br />
== systemd addidtions ==<br />
systemd requires lvm-on-cryptdevice.service active in order to open LVMs on cryptdevices that are not the root partition (which is handled by the initrd).</div>Denoyse