https://wiki.archlinux.org/api.php?action=feedcontributions&user=Michael+Arthur+Long&feedformat=atomArchWiki - User contributions [en]2024-03-28T10:30:23ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=EFISTUB&diff=769203EFISTUB2023-02-24T11:21:58Z<p>Michael Arthur Long: Use `touch` instead of `echo "" >`</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[de:EFISTUB]]<br />
[[es:EFISTUB]]<br />
[[fr:EFISTUB]]<br />
[[ja:EFISTUB]]<br />
[[pt:EFISTUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Unified kernel image}}<br />
{{Related articles end}}<br />
<br />
The Linux kernel supports EFISTUB booting which allows [[EFI]] firmware to load the kernel as an EFI executable. The option is enabled by default on Arch Linux kernels, or if compiling the kernel one can activate it by setting {{ic|1=CONFIG_EFI_STUB=y}} in the Kernel configuration. See [https://docs.kernel.org/admin-guide/efi-stub.html The EFI Boot Stub] for more information.<br />
<br />
With EFISTUB a kernel can be booted directly by a UEFI motherboard or indirectly using a [[boot loader]]. Using a boot loader is recommended if you have multiple kernel/initramfs pairs and your motherboard's UEFI boot menu is not easy to use.<br />
<br />
== Preparing for EFISTUB ==<br />
<br />
First, you must create an [[EFI system partition]] and choose how it is mounted. See [[EFI system partition#Mount the partition]] for all available ESP mounting options.<br />
<br />
{{Tip|<br />
* [[pacman]] will directly update the kernel that the EFI firmware will read if you mount the ESP to {{ic|/boot}}. <br />
* You can keep the kernel and initramfs off of the ESP if you use a boot manager which has a file system driver for the partition where they reside, e.g. [[rEFInd]].<br />
}}<br />
<br />
== Booting EFISTUB ==<br />
<br />
{{Tip| There are several UEFI boot managers which can provide additional options or simplify the process of UEFI booting - especially if you are experimenting with [[kernel parameters]] or if you have multiple kernels/operating systems. See [[Arch boot process#Boot loader]] for more information. }}<br />
<br />
{{Note|Linux Kernel EFISTUB initramfs path should be relative to the EFI System Partition's root and use backslashes (in accordance with EFI standards). For example, if the initramfs is located in {{ic|''esp''/EFI/arch/initramfs-linux.img}}, the corresponding UEFI formatted line should be {{ic|1=initrd=\EFI\arch\initramfs-linux.img}}. In the following examples we will assume that everything is under {{ic|''esp''/}}.}}<br />
<br />
=== Using UEFI directly ===<br />
<br />
UEFI is designed to remove the need for an intermediate bootloader such as [[GRUB]]. If your motherboard has a good UEFI implementation, it is possible to embed the kernel parameters within a UEFI boot entry and for the motherboard to boot Arch directly. You can use [[efibootmgr]] or UEFI Shell v2 to modify your motherboard's boot entries.<br />
<br />
{{Note|1=<nowiki/><br />
* Outdated UEFI implementations may have compatibility issues with the Linux kernel. If there is a newer version of your UEFI with bug fixes, consider flashing it with the manufacturer's recommended tool.<br />
* Some firmwares do not pass command line parameters from the boot entries in NVRAM to the EFI binaries.[https://bbs.archlinux.org/viewtopic.php?id=178154] In that case, the kernel and parameters can be combined into a [[unified kernel image]], then create a boot entry with the resulting ''.efi'' file.<br />
}}<br />
<br />
==== efibootmgr ====<br />
<br />
To create a boot entry with ''efibootmgr'' that will load the kernel:<br />
<br />
# efibootmgr --create --disk ''/dev/sdX'' --part ''Y'' --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=''block_device_identifier'' rw initrd=\initramfs-linux.img'<br />
<br />
or create a boot entry with ''efibootmgr'' and hibernation on swap partition:<br />
<br />
# efibootmgr --create --disk ''/dev/sdX'' --part ''Y'' --label "Arch Linux" --loader /vmlinuz-linux --unicode 'root=''block_device_identifier'' resume=''block_device_identifier'' rw initrd=\initramfs-linux.img'<br />
<br />
Where {{ic|''/dev/sdX''}} and {{ic|''Y''}} are the drive and partition number where the ESP is located. Change the {{ic|1=root=}} and {{ic|1=resume=}} parameters to reflect your Linux root and swap partitions. <br />
<br />
{{Note|See [[kernel parameters#Parameter list|kernel parameters]] for supported device name formats, and [[persistent block device naming]] for how to obtain the corresponding value.}}<br />
<br />
If omitted, then the first partition on {{ic|''/dev/sda''}} is used as the ESP.<br />
<br />
Note that the {{ic|-u}}/{{ic|--unicode}} argument in quotes is just the list of [[kernel parameters]], so you may need to add additional parameters (e.g. for [[Suspend and hibernate#Required kernel parameters|suspend to disk]] or [[microcode]]).<br />
<br />
After adding the boot entry, you can verify the entry was added properly with:<br />
<br />
# efibootmgr --unicode<br />
<br />
To set the boot order:<br />
<br />
# efibootmgr --bootorder ''XXXX'',''XXXX'' --unicode<br />
<br />
Where ''XXXX'' is the number that appears in the output of ''efibootmgr'' command against each entry.<br />
<br />
{{Tip|1=<nowiki/><br />
* https://github.com/de-arl/auto-UEFI-entry is a tool to create the commands<br />
* It is convenient to save the command to create the boot entry in a shell script, which makes it easier to modify, for example when changing kernel parameters. In doing so, consider automating the deletion of old boot entries, as ''efibootmgr'' currently [https://github.com/rhboot/efibootmgr/issues/49 does not support editing existing entries].<br />
* The forum post titled [https://bbs.archlinux.org/viewtopic.php?pid=1090040#p1090040 The linux kernel with build in bootloader?] might also be of interest.<br />
}}<br />
<br />
==== bcfg ====<br />
<br />
Some UEFI implementations make it difficult to modify the NVRAM successfully using ''efibootmgr''. If ''efibootmgr'' cannot successfully create an entry, you can use the [[UEFI#bcfg|bcfg]] command in UEFI Shell v2 (i.e., from the [https://archlinux.org/download/ Arch Linux live iso]).<br />
<br />
First, find out the device number where your [[ESP]] resides with:<br />
<br />
Shell> map<br />
<br />
In this example, {{ic|1}} is used as the device number. To list the contents of the [[ESP]]:<br />
<br />
Shell> ls FS1:<br />
<br />
To view the current boot entries:<br />
<br />
Shell> bcfg boot dump<br />
<br />
To add an entry for your kernel, use:<br />
<br />
Shell> bcfg boot add ''N'' FS1:\vmlinuz-linux "Arch Linux"<br />
<br />
Where {{ic|''N''}} is the location where the entry will be added in the boot menu. 0 is the first menu item. Menu items already existing will be shifted in the menu without being discarded.<br />
<br />
Add the necessary kernel options by creating a file on your ESP:<br />
<br />
Shell> edit FS1:\options.txt<br />
<br />
In the file, add the boot line. For example:<br />
<br />
root=/dev/sda2 ro initrd=\initramfs-linux.img<br />
<br />
{{Note|Add extra spaces in the beginning of the line in the file. There is a [[Wikipedia:Byte order mark|byte order mark]] at the beginning of the line that will squash any character next to it which will cause an error when booting.}}<br />
<br />
Press {{ic|F2}} to save and then {{ic|F3}} to exit.<br />
<br />
Add these options to your previous entry:<br />
<br />
Shell> bcfg boot -opt ''N'' FS1:\options.txt<br />
<br />
Repeat this process for any additional entries.<br />
<br />
To remove a previously added item do:<br />
<br />
Shell> bcfg boot rm ''N''<br />
<br />
==== kesboot ====<br />
<br />
You can also simplify and automate the work with EFISTUB using a script from the {{AUR|kesboot-git}} package. It also contains a [[pacman hook]] that can add and remove EFI variables during actions with packages.<br />
<br />
First, install the package, and then configure the {{ic|/etc/kesboot.conf}} file:<br />
<br />
{{hc|/etc/kesboot.conf|2=<br />
CMDLINES=('linux' 'acpi=on'<br />
'linux-zen' 'iommu=off')<br />
}}<br />
<br />
{{Note|If you use a hook (the variables {{ic|INSTALL_HOOK}} and {{ic|REMOVE_HOOK}}), then it will overwrite the {{ic|CMDLINES}} array every time it runs (preserving the contents of all records).}}<br />
<br />
Then, execute<br />
<br />
# kesboot -u<br />
<br />
The package also contains a program for the initial configuration of the EFI boot. After [[EFI system partition#Mount the partition|mounting the ESP]] directory, run<br />
<br />
# /usr/lib/setup-efi-boot<br />
<br />
=== Using UEFI Shell ===<br />
<br />
If you do not want to create a permanent boot entry it is possible to launch the kernel from UEFI Shell since it is a normal UEFI application:<br />
<br />
> FS0:<br />
> \vmlinuz-linux root=PARTUUID=3518bb68-d01e-45c9-b973-0b5d918aae96 rw initrd=\initramfs-linux.img<br />
<br />
In this case, the kernel parameters are passed as normal parameters to the launched EFISTUB kernel file.<br />
<br />
To avoid needing to remember all of your kernel parameters every time, you can save the executable command to a shell script such as {{ic|archlinux.nsh}} on your UEFI System Partition, then run it with:<br />
<br />
> FS0:<br />
> archlinux<br />
<br />
==== Using a startup.nsh script ====<br />
<br />
Some UEFI implementations do not retain EFI variables between cold boots (e.g. [[VirtualBox]] before version 6.1) and anything set through the UEFI firmware interface is lost on poweroff.<br />
<br />
The [https://www.uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf UEFI Shell Specification 2.0] establishes that a script called {{ic|startup.nsh}} at the root of the ESP partition will always be interpreted and can contain arbitrary instructions; among those you can set a bootloading line. Make sure you mount the ESP partition on {{ic|/boot}} and create a {{ic|startup.nsh}} script that contains a kernel bootloading line. For example:<br />
<br />
vmlinuz-linux rw root=/dev/sd''X'' [rootfs=''myfs''] [rootflags=''myrootflags''] \<br />
[kernel.flag=''foo''] [''mymodule''.flag=''bar''] \<br />
[initrd=\intel-ucode.img] initrd=\initramfs-linux.img<br />
<br />
This method will work with almost all UEFI firmware versions you may encounter in real hardware, you can use it as last resort. '''The script must be a single long line.''' Sections in brackets are optional and given only as a guide. Shell style linebreaks are for visual clarification only. FAT filesystems use the backslash as path separator and in this case, the backslash declares the initramfs is located in the root of the ESP partition. Only Intel microcode is loaded in the booting parameters line; AMD microcode is read from disk later during the boot process; this is done automatically by the kernel.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Boot entries are randomly removed ===<br />
<br />
{{Move|Unified Extensible Firmware Interface#Troubleshooting|This does not sound like a EFISTUB-specific issue.}}<br />
<br />
Some motherboards may remove boot entries due to lack of free space in the NVRAM instead of giving an error at creation. To prevent this from occurring, reduce the amount of boot entries being added by ''efibootmgr'' by minimizing your entry creation process, as well as reducing the amount of automatic drive boot entries by the [[Wikipedia:Unified Extensible Firmware Interface#CSM booting|Compatibility Support Module (CSM)]] by disabling it from your UEFI settings. See [https://bbs.archlinux.org/viewtopic.php?pid=1608838#p1608838].<br />
<br />
Another reason why boot entries might have been removed is the fact that UEFI specification allows OEMs to do "NVRAM maintenance" during boot process. Those manufacturers do it simply: they just look up for efi applications in predefined, hardcoded paths on the device. If they fail to find any, they just think that there is no OS on the device and wipe all boot entries from NVRAM associated with it, because they assume that NVRAM contains some corrupted or outdated data. If you do not plan to install Windows and still want to load linux kernel directly from the firmware, then one possible workaround here is to create empty file {{ic|esp/EFI/BOOT/BOOTX64.EFI}} (assuming here that esp mounted to {{ic|/boot}}): {{bc|# mkdir -p /boot/EFI/BOOT <br />
# touch /boot/EFI/BOOT/BOOTX64.EFI}}<br />
And restore the deleted boot entry by running ''efibootmgr'' again. Now after reboot the motherboard must see that "Fake OS" and probably will not wipe other boot entries from NVRAM. You can change the fake OS loader with an actual EFI application if you want, of course, as long as you keep the standard fallback name.<br />
<br />
=== EFISTUB does not work on some Dell systems ===<br />
<br />
Several generation Dell firmwares are wrongly passing the arguments to the bootloader, thus making EFISTUB parse a null command line which normally means unbootable system (see the complete [https://lore.kernel.org/linux-efi/20200907170021.GA2284449@rani.riverdale.lan/ linux-efi thread]).<br />
<br />
A workaround has been found since Linux 5.10 to correct this behavior (see this [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a568ce29d3f48df95919f82a80e4b9be7ea0dc1 commit ]). For Linux < 5.10, you can use an efi-packer like [https://github.com/RobertCsordas/arch-efiboot arch-efiboot], or a different bootloader.<br />
<br />
=== Changes to boot entries are not applied ===<br />
<br />
Some motherboards, such as Haswell-era Asus boards ([https://forums.archlinux.fr/viewtopic.php?t=19618 as encountered on the french forum]), will not notice changes to boot entries unless the system is booted with another pre-existing boot entry before booting the updated EFISTUB entry.<br />
<br />
== See also ==<br />
<br />
* [https://docs.kernel.org/admin-guide/efi-stub.html Linux Kernel Documentation on EFISTUB]<br />
* [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=291f36325f9f252bd76ef5f603995f37e453fc60;hp=55839d515495e766605d7aaabd9c2758370a8d27 Linux Kernel EFISTUB Git Commit]<br />
* [https://www.rodsbooks.com/efi-bootloaders/efistub.html Rod Smith's page on EFISTUB]</div>Michael Arthur Longhttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T420&diff=482416Lenovo ThinkPad T4202017-07-20T08:19:43Z<p>Michael Arthur Long: Fixed link to fingerprint-gui</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[zh-hans:Lenovo ThinkPad T420]]<br />
{{Out of date|{{ic|rc.conf}} references}}<br />
This article covers the installation and configuration of Arch Linux on a Lenovo T420 laptop.<br />
<br />
== Installation ==<br />
<br />
This laptop supports [[UEFI]] as well as the traditional BIOS.<br />
<br />
There are no issues with installing Arch Linux with the latest [https://www.archlinux.org/download/ Archiso].<br />
<br />
The rest of the installation process can be followed with the [[Installation guide]].<br />
<br />
== Hardware ==<br />
<br />
All hardware works out of the box except the following:<br />
<br />
=== Fingerprint reader ===<br />
<br />
Fingerprint reader works great with fprint and PAM (installation of fingerprint-gui recommended).<br />
<br />
See [[Fingerprint-gui]] for more information.<br />
<br />
=== Some Media keys ===<br />
<br />
* See [[#Media Keys|Media Keys]]<br />
<br />
=== Untested ===<br />
<br />
* Firewire<br />
<br />
==Laptop Settings==<br />
<br />
===ACPI===<br />
<br />
[[ACPI_modules|ACPI]] is well supported here. No obvious troubleshoots.<br />
<br />
=== Tp_smapi ===<br />
<br />
Unfortunately, [[tp_smapi]] is only partially supported on the Thinkpad T420. A number of features work since version 0.41. For example, the hard drive protection mechanism [[HDAPS]] now works well. See the linked wiki entry.<br />
<br />
Some features like setting the starting threshold for charging the battery do not yet work. To control the battery charging thresholds, install the Perl script {{Pkg|tpacpi-bat}} from the [[AUR]].<br />
<br />
Insert the {{ic|acpi_call}} kernel module by running<br />
modprobe acpi_call<br />
<br />
Manually set the thresholds by calling<br />
/usr/bin/perl /usr/bin/tpacpi-bat -v -s SP 0 80 <br />
/usr/bin/perl /usr/bin/tpacpi-bat -v -s ST 0 40<br />
The example values 40 and 80 given here represent the percentage of full battery capacity remaining. Adjust them to your own needs. You may also want to write a simple {{ic|set-battery.service}} and enable it to set them at startup. While these values should be permanent, they will be reset any time the battery is removed.<br />
<br />
[Unit]<br />
Description=Set battery capacity<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/perl /usr/bin/tpacpi-bat -v -s SP 0 80<br />
ExecStart=/usr/bin/perl /usr/bin/tpacpi-bat -v -s ST 0 40<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
<br />
Also, if you are dual booting with Windows, you can still control the battery charging thresholds with Lenovo's Power Manager which communicates directly to the battery controller.<br />
<br />
When using systemd, you may want to blacklist the tp_smapi module if your systemd-modules-load.service fails, as new ThinkPads handle everything over acpi.<br />
<br />
=== CPU frequency scaling ===<br />
<br />
[[CPU frequency scaling]] is fully supported with all of the available processor models with this laptop.<br />
<br />
=== Fans ===<br />
<br />
Install the package {{AUR|thinkfan}}. It will automatically create the necessary acpi configuration file in {{ic|/usr/lib/modprobe.d/thinkpad_acpi.conf}}.<br />
<br />
Copy the example sensor settings file from "/usr/share/doc/thinkfan/examples/thinkfan.conf.simple" to "/etc/thinkfan.conf".<br />
{{bc|# cp /usr/share/doc/thinkfan/examples/thinkfan.conf.simple /etc/thinkfan.conf}}<br />
<br />
Aftwards replace the default {{ic|hwmon}} in the settings file {{ic|/etc/thinkfan.conf}} with the following:<br />
{{hc|/etc/thinkfan.conf|hwmon /sys/devices/virtual/thermal/thermal_zone0/temp}}<br />
<br />
Alternatively, sensors can be generated using following command. Add {{ic|hwmon}} before the sensor lines.<br />
{{bc|find /sys/devices -type f -name "temp*_input"}}<br />
<br />
In the same configuration file replace the default fan level settings with your needs (the last lines of the file). Useful values are<br />
{{bc|(0, 0, 42)<br />
(1, 40, 47)<br />
(2, 45, 52)<br />
(3, 50, 57)<br />
(4, 55, 62)<br />
(5, 60, 67)<br />
(6, 65, 72)<br />
(7, 70, 77)<br />
(127, 75, 32767)}}<br />
<br />
Finally [[enable]] the '''thinkfan''' service.<br />
{{bc|# systemctl enable thinkfan}}<br />
<br />
=== Laptop Mode Tools ===<br />
<br />
No significant issues were found using [[Laptop Mode Tools]].<br />
<br />
Possible bug with [[#Shutdown on battery]].<br />
<br />
The package {{Pkg|tlp}} is an alternative tool that can replace {{AUR|laptop-mode-tools}}.<br />
<br />
=== NVIDIA Optimus ===<br />
<br />
[[Bumblebee]] works as intended on models with NVIDIA Optimus<br />
<br />
=== Optional kernel boot arguments ===<br />
Using the following kernel boot parameters [http://www.phoronix.com/scan.php?page=article&item=intel_i915_power&num=1| reduces battery drain]:<br />
<br />
{{bc|<nowiki><br />
i915.i915_enable_rc6=1<br />
i915.i915_enable_fbc=1<br />
i915.lvds_downclock=1 <br />
i915.semaphores=1<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Media Keys ===<br />
<br />
Media keys that (should) work out of the box:<br />
* Wireless On/Off<br />
* Backlight Brightness settings<br />
* Thinklight<br />
* Mute<br />
* Microphone mute<br />
<br />
Media Keys that Do Not work out of the box:<br />
* [[#Volume_up.2Fdown_not_changing_volume|Volume keys]] (Works out-of-the-box in [[GNOME]])<br />
You must find a workaround and bind the keys yourself for the rest of them.<br />
<br />
[[xbindkeys]] and {{AUR|xbindkeys_config-gtk2}} can be a solution for media keys that are not working. This solution also allows you to rebind the ThinkVantage button and certain FN layer shortcuts (the blue logos on the keyboard).<br />
<br />
=== Rebind Forward and Back keys ===<br />
<br />
Keys forward and back (next to cursor keys) can be easily remapped to PageDown/PageUp.<br />
<br />
[[Install]] xmodmap with the package {{Pkg|xorg-xmodmap}}<br />
<br />
Create a {{ic|~/.Xmodmap}} file with content:<br />
keysym XF86Back = Page_Up<br />
keysym XF86Forward = Page_Down<br />
<br />
Add this line to your {{ic|~/.xinitrc}} to make it work:<br />
xmodmap ~/.Xmodmap<br />
<br />
You can also re-map AudioPrev ({{ic|Fn+Left}}) and AudioNext ({{ic|Fn+Right}}) to Home/End:<br />
keysym XF86AudioNext = End<br />
keysym XF86AudioPrev = Home<br />
<br />
{{Note|<br />
* You have to log out for the changes to take effect.<br />
* The keys should work out of the box, at least on [[KDE]].<br />
}}<br />
<br />
=== Turn touchpad on and off ===<br />
<br />
For some, the ({{ic|Fn+F8}}) key does not switch the touchpad on and off. See [[Touchpad Synaptics#Software toggle]] for a workaround.<br />
<br />
=== Volume up/down not changing volume ===<br />
<br />
See [[Xbindkeys]].<br />
<br />
=== Shutdown on battery ===<br />
<br />
Some users have reported that the T420 was rebooting on shutdown on battery power. There have been quite a few attempts to fix this. Three are detailed here. <br />
<br />
One way is to disable the module {{ic|ehci_hcd}}. See [[Kernel modules#Blacklisting]] for more information.<br />
<br />
Or try disable Laptop-mode. <br />
Add {{Ic|!laptop-mode}} to the {{Ic|DAEMONS}} array in {{ic|/etc/rc.conf}}:<br />
DAEMONS=(...!laptop-mode...)<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?pid=1106437#p1106437 This forum post] details another way to have your computer not reboot on shutdown. Turning off the {{ic|laptop-mode}} daemon causes battery life to suffer, so when on the move and in need of a simple way to shutdown, this seems to work better.<br />
<br />
=== Hang on reboot ===<br />
<br />
This is a problem on many laptops and can be fixed by [[blacklisting]] the {{ic|e1000e}} kernel module.<br />
<br />
== See also ==<br />
<br />
* [[Lenovo ThinkPad T420s]]<br />
* [http://sysphere.org/~anrxc/j/articles/thinkpad-t420/index.html Arch Linux on ThinkPad T420i]</div>Michael Arthur Longhttps://wiki.archlinux.org/index.php?title=Fingerprint_GUI&diff=451195Fingerprint GUI2016-09-20T04:26:44Z<p>Michael Arthur Long: Fixed links from last changes.</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Laptops]]<br />
[[ja:Fingerprint-gui]]<br />
{{Related articles start}}<br />
{{Related|Fprint}}<br />
{{Related|ThinkFinger}}<br />
{{Related articles end}}<br />
<br />
[http://www.ullrich-online.cc/fingerprint/ Fingerprint-gui] is a program that provides an interface and drivers for fingerprint readers. The package includes drivers from the open-source project [[fprint]] as well as proprietary drivers not included in fprint.<br />
<br />
== Installation ==<br />
Install {{AUR|fingerprint-gui}} from [[AUR]]. The package includes an installation guide in html format at {{ic|/usr/share/doc/fingerprint-gui/Manual_en.html}}.<br />
<br />
If you are using [[GNOME]] or [[KDE]] follow the instructions pacman gives and remove the following files:<br />
{{hc|/etc/xdg/autostart/|<br />
polkit-gnome-authentication-agent-1.desktop<br />
polkit-kde-authentication-agent-1.desktop<br />
}}<br />
<br />
If you are using a [[window manager]], you may need an [[Polkit#Authentication_agents|authentication agent]].<br />
<br />
== Registering Fingerprints ==<br />
After installation, test if your hardware is recognized and correctly working by launching the configuration utility:<br />
<br />
$ fingerprint-gui -d<br />
<br />
The '-d' is for debugging, and simply creates a verbose log of events. If you are comfortable without the debug info, you may safely omit the flag.<br />
<br />
If your device is not recognized, you might need to reboot in order for udev to set the correct permissions for the device. You may need to add your user to the plugdev and scanner groups.<br />
<br />
To start registering your fingerprints with the configuration utility, select the tab '''Finger''', select a finger and choose next.<br />
<br />
== Authentication ==<br />
<br />
Once your fingerprints have been registered, you may notice that in the setup procedure that the "test" section does not yet work. This is because the necessary authentication has not been approved in the appropriate {{ic|pam.d}} files.<br />
<br />
As an example of how to set up fingerprint authetication for a given service, we will first start with [[sudo]]. Open {{ic|/etc/pam.d/sudo}} in your [[List of applications#Text editors|text editor]] and insert the following '''bold text''':<br />
<br />
{{hc|/etc/pam.d/sudo|<br />
#%PAM-1.0<br />
'''auth sufficient pam_fingerprint-gui.so'''<br />
auth required pam_unix.so<br />
auth required pam_nologin.so}}<br />
<br />
Keep in mind that your 'sudo' file may contain more entries.<br />
<br />
Some users may not have (or want to have) [[sudo]] installed on their systems. In this case, it is still possible to use your fingerprint to autheticate [[su]]. This can be done just like the sudo example, of course instead adding an entry to {{ic|/etc/pam.d/su}}. Again, add the following '''bold text'''.<br />
<br />
{{hc|/etc/pam.d/su|<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
'''auth sufficient pam_fingerprint-gui.so'''<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so}}<br />
<br />
One may also configure such things as GDM, KDM, LightDM and the Gnome-Screensaver. Again, if more information or instruction is needed, please refer to the included manual. The [http://www.ullrich-online.cc/fingerprint/doc/Step-by-step-manual.html Package Maintainer's Manual] might provide further information that cannot be obtained by the included manual.<br />
<br />
== Verification ==<br />
<br />
Now that the necessary authentication has been added to pam, you may wish the confirm the functionality of your setup. The easiest way to do this is to, again, launch the fingerprint-gui. Rather than go through the steps (as your fingerprints should already be established), click directly on the ''Settings'' tab. From here you may select the function you wish to test (ie. sudo, su, gdm, etc).<br />
<br />
There is also an included utility to simply confirm that your registered fingerprints are recognized. This can be done by simply running:<br />
<br />
$ fingerprint-identifier<br />
<br />
and following the onscreen instructions.<br />
<br />
== Exporting ==<br />
<br />
If you wish to save your user's fingerprint data to a file, simple use the ''Export'' button in the ''Settings'' tab. A file Fingerprints.tar.gz" will be created in the desired directory. At this time, I have not yet figured out what exactly to do with this saved file though, as I have not come across an "Import" function.<br />
<br />
== Password ==<br />
<br />
In some cases, using your fingerprint to log into the system may inhibit certain other functions of the desktop environment. For example, [[GNOME Keyring]] is dependent on your password, as it is used to encrypt the data in your keyring. To overcome this, fingerprint-gui contains a feature that allows you to store your encrypted password on removable media (USB). You may then use the key to decrypt your keychain by authenticating your fingerprint while the removable media is plugged in.<br />
<br />
The manual indicates that to use this function, mount your USB drive and ensure that you have write access to it. Under the "Password" tab of fingerprint-gui, indicate the appropriate path to your device where it says "Save to directory" (ie. if using gvfs it should be under {{ic|/run/media/''your_uid''/''device''}}). Enter your password and re-enter it and select "save". This will create a hidden directory on your removable media {{ic|/.fingerprints}} and create a file {{ic|''username''@''hostname''.xml}}. On the local machine, this will also create the file {{ic|/var/lib/fingerprint-gui/''username''/config.xml}}.<br />
<br />
{{Note|Security warning: Everyone who has access to both, your computer and the external media, can decrypt the password-file! Never leave the computer and the media unattended at the same place! Connect this media only while logon and don't use it if other persons have root-access to your computer.}}</div>Michael Arthur Longhttps://wiki.archlinux.org/index.php?title=Fingerprint_GUI&diff=451194Fingerprint GUI2016-09-20T04:12:32Z<p>Michael Arthur Long: Added info for window manager users, fixed broken section link.</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Laptops]]<br />
[[ja:Fingerprint-gui]]<br />
{{Related articles start}}<br />
{{Related|Fprint}}<br />
{{Related|ThinkFinger}}<br />
{{Related articles end}}<br />
<br />
[http://www.ullrich-online.cc/fingerprint/ Fingerprint-gui] is a program that provides an interface and drivers for fingerprint readers. The package includes drivers from the open-source project [[fprint]] as well as proprietary drivers not included in fprint.<br />
<br />
== Installation ==<br />
Install {{AUR|fingerprint-gui}} from [[AUR]]. The package includes an installation guide in html format at {{ic|/usr/share/doc/fingerprint-gui/Manual_en.html}}.<br />
<br />
If you are using [[GNOME]] or [[KDE]] follow the instructions pacman gives and remove the following files:<br />
{{hc|/etc/xdg/autostart/|<br />
polkit-gnome-authentication-agent-1.desktop<br />
polkit-kde-authentication-agent-1.desktop<br />
}}<br />
<br />
If you are using a [[window manager]], you may need an [[Polkit#Authentication_agentsPolkit#Authentication_agentsl|authentication agent]].<br />
<br />
== Registering Fingerprints ==<br />
After installation, test if your hardware is recognized and correctly working by launching the configuration utility:<br />
<br />
$ fingerprint-gui -d<br />
<br />
The '-d' is for debugging, and simply creates a verbose log of events. If you are comfortable without the debug info, you may safely omit the flag.<br />
<br />
If your device is not recognized, you might need to reboot in order for udev to set the correct permissions for the device. You may need to add your user to the plugdev and scanner groups.<br />
<br />
To start registering your fingerprints with the configuration utility, select the tab '''Finger''', select a finger and choose next.<br />
<br />
== Authentication ==<br />
<br />
Once your fingerprints have been registered, you may notice that in the setup procedure that the "test" section does not yet work. This is because the necessary authentication has not been approved in the appropriate {{ic|pam.d}} files.<br />
<br />
As an example of how to set up fingerprint authetication for a given service, we will first start with [[sudo]]. Open {{ic|/etc/pam.d/sudo}} in your [[Common Applications#Text Editors|text editor]] and insert the following '''bold text''':<br />
<br />
{{hc|/etc/pam.d/sudo|<br />
#%PAM-1.0<br />
'''auth sufficient pam_fingerprint-gui.so'''<br />
auth required pam_unix.so<br />
auth required pam_nologin.so}}<br />
<br />
Keep in mind that your 'sudo' file may contain more entries.<br />
<br />
Some users may not have (or want to have) [[sudo]] installed on their systems. In this case, it is still possible to use your fingerprint to autheticate [[su]]. This can be done just like the sudo example, of course instead adding an entry to {{ic|/etc/pam.d/su}}. Again, add the following '''bold text'''.<br />
<br />
{{hc|/etc/pam.d/su|<br />
#%PAM-1.0<br />
auth sufficient pam_rootok.so<br />
'''auth sufficient pam_fingerprint-gui.so'''<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
session required pam_unix.so}}<br />
<br />
One may also configure such things as GDM, KDM, LightDM and the Gnome-Screensaver. Again, if more information or instruction is needed, please refer to the included manual. The [http://www.ullrich-online.cc/fingerprint/doc/Step-by-step-manual.html Package Maintainer's Manual] might provide further information that cannot be obtained by the included manual.<br />
<br />
== Verification ==<br />
<br />
Now that the necessary authentication has been added to pam, you may wish the confirm the functionality of your setup. The easiest way to do this is to, again, launch the fingerprint-gui. Rather than go through the steps (as your fingerprints should already be established), click directly on the ''Settings'' tab. From here you may select the function you wish to test (ie. sudo, su, gdm, etc).<br />
<br />
There is also an included utility to simply confirm that your registered fingerprints are recognized. This can be done by simply running:<br />
<br />
$ fingerprint-identifier<br />
<br />
and following the onscreen instructions.<br />
<br />
== Exporting ==<br />
<br />
If you wish to save your user's fingerprint data to a file, simple use the ''Export'' button in the ''Settings'' tab. A file Fingerprints.tar.gz" will be created in the desired directory. At this time, I have not yet figured out what exactly to do with this saved file though, as I have not come across an "Import" function.<br />
<br />
== Password ==<br />
<br />
In some cases, using your fingerprint to log into the system may inhibit certain other functions of the desktop environment. For example, [[GNOME Keyring]] is dependent on your password, as it is used to encrypt the data in your keyring. To overcome this, fingerprint-gui contains a feature that allows you to store your encrypted password on removable media (USB). You may then use the key to decrypt your keychain by authenticating your fingerprint while the removable media is plugged in.<br />
<br />
The manual indicates that to use this function, mount your USB drive and ensure that you have write access to it. Under the "Password" tab of fingerprint-gui, indicate the appropriate path to your device where it says "Save to directory" (ie. if using gvfs it should be under {{ic|/run/media/''your_uid''/''device''}}). Enter your password and re-enter it and select "save". This will create a hidden directory on your removable media {{ic|/.fingerprints}} and create a file {{ic|''username''@''hostname''.xml}}. On the local machine, this will also create the file {{ic|/var/lib/fingerprint-gui/''username''/config.xml}}.<br />
<br />
{{Note|Security warning: Everyone who has access to both, your computer and the external media, can decrypt the password-file! Never leave the computer and the media unattended at the same place! Connect this media only while logon and don't use it if other persons have root-access to your computer.}}</div>Michael Arthur Long