https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rad3k&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:26:45ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd&diff=233899Systemd2012-11-05T18:31:10Z<p>Rad3k: /* Sleep hooks */ Fixed broken link to another section</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Systemd/Services}}<br />
{{Article summary wiki|Systemd FAQ}}<br />
{{Article summary wiki|Init Rosetta}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
'''''systemd''' is a system and service manager for Linux, compatible with SysV and LSB init scripts. '''systemd''' provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for [[SysVinit|sysvinit]].''<br />
<br />
{{Note|1=For a detailed explanation as to why Arch has moved to systemd, see [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 this forum post].}}<br />
<br />
See also the [[Wikipedia:Systemd|Wikipedia article]].<br />
<br />
== Things to consider before you switch ==<br />
<br />
* It is highly recommended to switch to the new '''initscripts''' configuration system described in the [[rc.conf|rc.conf article]]. Once you have this configuration established, you will have done most of the work needed to make the switch to systemd.<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about systemd.<br />
* Note the fact that systemd has a '''journal''' system that replaces '''syslog''', although the two can co-exist. See the [[#Journal|section on the journal]] below.<br />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<br />
Systemd can be installed side-by-side with the regular Arch Linux {{Pkg|initscripts}} package, and they can be toggled by adding/removing the {{ic|1=init=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== Mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and SysVinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration format (there should be warnings at boot) to the [[#Native configuration|native systemd configuration files]], and reboot to verify that initscipts work as expected.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively (see [[#Initscripts emulation]] below). If the legacy support for {{ic|DAEMONS}} in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
If you were starting a login manager (SLiM, GDM, etc.) using {{ic|/etc/inittab}} it will no longer start, because systemd doesn't use {{ic|inittab}}. The wiki page for the [[Login_Manager|login manager]] should tell you how to add it as a systemd service.<br />
<br />
{{Warning|In case you have daemons in the {{ic|DAEMONS}} array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
{{Warning|Systemd is an asynchronous starting process, compared to the sequential {{ic|DAEMONS}} startup. In particular, {{ic|network}} being a legacy service, may start too late to enable interfaces which are required by other services. You are advised to move to [[netcfg]] or [[NetworkManager]] before embarking to systemd. }}<br />
<br />
=== Mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents (see [[#Initscripts emulation]] below).<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation.<br />
# [[#Using Units|Enable daemons]] formerly listed in {{ic|/etc/rc.conf}} with {{ic|systemctl enable ''daemonname''}}. For a translation of the daemons from {{ic|/etc/rc.conf}} to systemd services, see: [[Daemons List|List of Daemons]] and [[Systemd/Services|Services]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so that systemd starts the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry from the kernel parameters in your bootloader as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== Pure systemd installation ===<br />
<br />
Finally, it is possible to remove {{pkg|initscripts}} and {{pkg|sysvinit}} entirely and use only systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation.<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove {{pkg|initscripts}} from your system.<br />
<br />
{{Warning|Do '''not''' remove {{pkg|systemd-sysvcompat}}, as that package is in the {{grp|base}} group.}}<br />
<br />
=== Supplementary information ===<br />
<br />
* Adding your user to [[Users and Groups|groups]] ({{ic|optical}}, {{ic|audio}}, {{ic|scanner}}, etc.) is '''not''' necessary for most use cases with systemd. The groups can even cause some functionality to break. For example, the audio group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].<br />
<br />
{{Note|Systemd-logind replaced [[ConsoleKit]], which was removed from the repositories, so a system must be booted with systemd to be fully functional. See [https://www.archlinux.org/news/consolekit-replaced-by-logind/ here] for more info.}}<br />
<br />
* If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.<br />
<br />
== Native configuration ==<br />
<br />
{{Note|You may need to create these files. All files should have '''644''' permissions and '''root:root''' ownership.}}<br />
<br />
=== Hostname ===<br />
<br />
The hostname is configured in {{ic|/etc/hostname}}. The file should not contain the system's domain, if any. To set the hostname, do:<br />
<br />
# hostnamectl set-hostname '''myhostname'''<br />
<br />
See {{ic|man 5 hostname}} and {{ic|man 1 hostnamectl}} for details.<br />
<br />
Here is an example file:<br />
{{hc|/etc/hostname|<br />
myhostname<br />
}}<br />
<br />
=== Locale ===<br />
<br />
The default system locale is configured in {{ic|/etc/locale.conf}}. To set the default locale, do:<br />
<br />
# localectl set-locale LANG="de_DE.utf8"<br />
<br />
{{Note|Before you set the default locale, you first need to enable locales available to the system by uncommenting them in {{ic|/etc/locale.gen}} and then executing {{ic|locale-gen}} as root. The locale set via {{ic|localectl}} must be one of the '''uncommented''' locales in {{ic|/etc/locale.gen}}.}}<br />
<br />
See {{ic|man 1 localectl}} and {{ic|man 5 locale.conf}} for details.<br />
<br />
* For more information, see [[Locale]].<br />
<br />
Here is an example file:<br />
{{hc|/etc/locale.conf|<nowiki><br />
LANG=en_US.utf8<br />
</nowiki>}}<br />
<br />
=== Virtual console ===<br />
<br />
The virtual console (keyboard mapping, console font and console map) is configured in {{ic|/etc/vconsole.conf}}:<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<br />
<br />
{{Note|As of {{pkg|systemd-194}}, the built-in ''kernel'' font and the ''us'' keymap are used if {{ic|1=KEYMAP=}} and {{ic|1=FONT=}} are empty or not set.}}<br />
<br />
Another way to set the keyboard mapping (keymap) is doing:<br />
<br />
# localectl set-keymap de<br />
<br />
This has the advantage that it will also set the same keymap for use in X11.<br />
<br />
See {{ic|man 1 localectl}} and {{ic|man 5 vconsole.conf}} for details.<br />
<br />
* For more information, see [[Fonts#Console fonts|console fonts]] and [[KEYMAP|keymaps]].<br />
<br />
=== Time zone ===<br />
<br />
The time zone is configured by creating an appropriate {{ic|/etc/localtime}} symlink, pointing to a zoneinfo file under {{ic|/usr/share/zoneinfo/}}. To do this automatically:<br />
<br />
# timedatectl set-timezone America/Toronto<br />
<br />
See {{ic|man 1 timedatectl}} and {{ic|man 5 localtime}} for more details.<br />
<br />
Alternatively, create the symlink yourself:<br />
<br />
# ln -sf ../usr/share/zoneinfo/America/Toronto /etc/localtime<br />
<br />
=== Hardware clock ===<br />
<br />
Systemd will use '''UTC''' for the hardware clock by default.<br />
<br />
{{Tip|It is advised to have a [[NTP|Network Time Protocol daemon]] running to keep the system time synchronized with Internet time and the hardware clock.}}<br />
<br />
==== Hardware clock in localtime ====<br />
<br />
If you want to change the hardware clock to use local time ('''STRONGLY DISCOURAGED''') do:<br />
<br />
# timedatectl set-local-rtc true<br />
<br />
If you want to revert to the hardware clock being in UTC, do:<br />
<br />
# timedatectl set-local-rtc false<br />
<br />
Be warned that, if the hardware clock is set to localtime, dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). Recent kernels set the system time from the RTC directly on boot, assuming that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is the root of certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
One reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). However, Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC_in_Windows|registry fix]]. There, it is recommended that Windows are changed to use UTC, rather than Linux to use localtime.<br />
<br />
* For more information, see [[Time]].<br />
<br />
=== Kernel modules ===<br />
<br />
Today, all necessary module loading is handled automatically by [[udev]], so that, if you don't want/need to use any out-of-tree kernel modules, there is no need to put modules that should be loaded at boot in any config file. However, there are cases where you might want to load an extra module during the boot process, or blacklist another one for your computer to function properly.<br />
<br />
==== Extra modules to load at boot ====<br />
<br />
Extra kernel modules to be loaded during boot are configured as a static list in files under {{ic|/etc/modules-load.d/}}. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. Configuration files simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See {{ic|man 5 modules-load.d}} for more details.<br />
<br />
==== Blacklisting ====<br />
<br />
Module blacklisting works the same way as with {{Pkg|initscripts}} since it is actually handled by {{Pkg|kmod}}. See [[Kernel modules#Blacklisting|Module Blacklisting]] for details.<br />
<br />
=== Filesystem mounts ===<br />
<br />
The default setup will automatically fsck and mount filesystems before starting services that need them to be mounted. For example, systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore, local and remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
See {{ic|man 5 systemd.mount}} for details.<br />
<br />
==== Automount ====<br />
<br />
* If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is being fsck'ed. This can be achieved by adding the following options to the fstab entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
* The same applies to remote filesystem mounts. If you want them to be mounted only upon access, you will need to use the {{ic|noauto,x-systemd.automount}} parameters. In addition, you can use the {{ic|1=x-systemd.device-timeout=#}} option to specify a timeout in case the network resource is not available.<br />
<br />
* If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. Systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:<br />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
==== LVM ====<br />
<br />
If you have LVM volumes not activated via the [[Mkinitcpio|initramfs]], enable {{ic|lvm.service}} (provided by the {{pkg|lvm2}} package):<br />
<br />
# systemctl enable lvm<br />
<br />
Similarly, if you have LVM on encrypted devices mounted later during boot (e.g. from {{ic|/etc/crypttab}}), enable {{ic|lvm-on-crypt.service}} (also provided by the {{pkg|lvm2}} package):<br />
<br />
# systemctl enable lvm-on-crypt<br />
<br />
=== ACPI power management ===<br />
<br />
Systemd handles some power-related ACPI events. They can be configured via the following options from {{ic|/etc/systemd/logind.conf}}:<br />
<br />
* {{ic|HandlePowerKey}}: specifies which action is invoked when the power key is pressed.<br />
* {{ic|HandleSuspendKey}}: specifies which action is invoked when the suspend key is pressed.<br />
* {{ic|HandleHibernateKey}}: specifies which action is invoked when the hibernate key is pressed.<br />
* {{ic|HandleLidSwitch}}: specifies which action is invoked when the lid is closed.<br />
<br />
The specified action can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.<br />
<br />
If these options are not configured, systemd will use its defaults: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
On systems which run no graphical setup or only a simple window manager like [[i3]] or [[awesome]], this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
In the current version of systemd, the {{ic|Handle}} options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Warning|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. New versions are on the way that will include this functionality.}}<br />
<br />
{{Note|Systemd can also use other suspend backends (such as [[Uswsusp]] or [[TuxOnIce]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate.}}<br />
<br />
==== Sleep hooks ====<br />
<br />
Systemd does not use [[pm-utils]] to put the machine to sleep when using {{ic|systemctl suspend}} or {{ic|systemctl hibernate}}, therefore [[pm-utils]] hooks including any [[Pm-utils#Creating_your_own_hooks|custom hooks]] created will not be run. However, systemd provides a similar mechanism to run custom scripts on these events. Systemd runs all executables in {{ic|/usr/lib/systemd/system-sleep/}} and passes two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: either {{ic|suspend}} or {{ic|hibernate}}, depending on what has been invoked<br />
<br />
In contrast to [[pm-utils]], systemd will run these scripts concurrently and not one after another.<br />
<br />
The output of your script will be logged by {{ic|systemd-suspend.service}} or {{ic|systemd-hibernate.service}} so you can see its output in the [[Systemd#Journal|journal]]:<br />
# journalctl -b -u systemd-suspend<br />
<br />
Note that you can also use {{ic|sleep.target}}, {{ic|suspend.target}} or {{ic|hibernate.target}} to hook units into the sleep state logic instead of using scripts.<br />
<br />
Example:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac}}<br />
<br />
See {{ic|man 7 systemd.special}} and {{ic|man 8 systemd-sleep}} for details.<br />
<br />
=== Temporary files ===<br />
<br />
Systemd-tmpfiles uses configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/<program>.conf}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/var/run/samba}} to exist and to have the correct permissions. The corresponding tmpfile looks like this:<br />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<br />
<br />
However, tmpfiles may also be used to write values into certain files on boot. For example, if you use {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE}}<br />
<br />
The tmpfiles method is recommended in this case since systemd doesn't actually support {{ic|/etc/rc.local}}.<br />
<br />
See {{ic|man 5 tmpfiles.d}} for details.<br />
<br />
=== Units ===<br />
<br />
A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd. The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files.<br />
<br />
See {{ic|man 5 systemd.unit}} for details.<br />
<br />
== Transitioning from initscripts to systemd ==<br />
<br />
=== Initscripts emulation ===<br />
<br />
Integration with Arch's classic configuration is provided by the {{Pkg|initscripts}} package. When {{Pkg|initscripts}} are installed in parallel with systemd, with the system running on systemd, systemd will do the following:<br />
<br />
# Parse the {{ic|DAEMONS}} array of {{ic|/etc/rc.conf}} and start all listed daemons at boot<br />
# Execute {{ic|/etc/rc.local}} during boot<br />
# Execute {{ic|/etc/rc.local.shutdown}} during shutdown<br />
<br />
Initscripts emulation is simply meant as a transitional measure to ease users' move to systemd, and '''will eventually go away'''. Native systemd does not rely on {{ic|rc.conf}} centralised configuration, so it is recommended to use [[#Native configuration|native systemd configuration files]], which will take precedence over {{ic|/etc/rc.conf}}.<br />
<br />
{{Note|If you disabled {{keypress|Ctrl+Alt+Del}} to reboot in {{ic|/etc/inittab}}, you will have to reconfigure this setting for systemd by running {{ic|systemctl mask ctrl-alt-del.target}} as root.}}<br />
<br />
=== Moving away from the DAEMONS array ===<br />
<br />
For a pure systemd setup, you should remove the {{ic|/etc/rc.conf}} file entirely and enable services only via {{ic|systemctl}}. For each {{ic|<service_name>}} in the {{ic|DAEMONS}} array in {{ic|/etc/rc.conf}}, run:<br />
<br />
# systemctl enable <service_name><br />
<br />
{{Tip|For a list of commonly used daemons with their initscripts and systemd equivalents, see [[Daemons List|this table]].}}<br />
<br />
If {{ic|<service_name>.service}} does not exist:<br />
<br />
* Most probably, systemd uses a different name. For example, {{ic|cronie.service}} replaces the {{ic|crond}} init daemon; {{ic|alsa-store.service}} and {{ic|alsa-restore.service}} replace the {{ic|alsa}} init daemon. Another important instance is the {{ic|network}} daemon, which is replaced with another set of service files (see [[Configuring Network]] for more details.)<br />
* Otherwise, a service file may not be available for systemd. In that case, you'll need to keep {{ic|rc.conf}} to start the service during boot up.<br />
<br />
{{Tip|You may look inside a package that contains daemon start scripts for service names. For instance:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #Daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #Corresponding systemd daemon service<br />
[...]<br />
}}<br />
<br />
* Finally, some services do not need to be explicitly enabled by the user. For instance, {{ic|dbus.service}} will automatically be enabled when {{ic|dbus-core}} is installed. {{ic|alsa-store.service}} and {{ic|alsa-restore.service}} are also enabled automatically by systemd. Check the list of available services and their state using the {{ic|systemctl}} command like this: {{ic|systemctl status <service_name>}}.<br />
<br />
== Basic command usage examples ==<br />
<br />
* {{ic|systemctl}}: used to introspect and control the state of the systemd system and service manager.<br />
* {{ic|systemd-cgls}}: recursively shows the contents of the selected Linux control group hierarchy in a tree<br />
* {{ic|systemadm}}: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd (provided by the {{AUR|systemd-ui-git}} package from the [[AUR]]).<br />
<br />
View the man pages for more details.<br />
<br />
{{Tip|You can use all of the following {{ic|systemctl}} commands with the {{ic|-H <user>@<host>}} switch to control a systemd instance on a remote machine. This will use [[SSH]] to connect to the remote systemd instance.}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ systemctl --failed<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see list installed unit files by:<br />
<br />
$ systemctl list-unit-files<br />
<br />
=== Using units ===<br />
<br />
Units can be, for example, services ({{ic|.service}}), mount points ({{ic|.mount}}), devices ({{ic|.device}}) or sockets ({{ic|.socket}}).<br />
<br />
When using {{ic|systemctl}}, you generally have to specify the complete name of the unit file, including its suffix, for example {{ic|sshd.socket}}. There are however a few shortforms when specifying the unit in the following {{ic|systemctl}} commands:<br />
<br />
* If you don't specify the suffix, systemctl will assume {{ic|.service}}. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are treated equivalent.<br />
* Mount points will automatically be translated into the appropriate {{ic|.mount}} unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similiar to mount points, devices are automatically translated into the appropriate {{ic|.device}} unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note|If services do not have an {{ic|Install}} section, it usually means they are called automatically by other services. But if you need to install them manually, use the following command, replacing {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ systemctl help <unit><br />
<br />
=== Power management ===<br />
<br />
If you are in a local {{ic|systemd-logind}} user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.<br />
<br />
Shut down and reboot the system:<br />
<br />
$ systemctl reboot<br />
<br />
Shut down and power-off/shutdown the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Put your system into hibernation:<br />
<br />
$ systemctl hibernate<br />
<br />
== Writing custom .service files ==<br />
<br />
=== Handling dependencies ===<br />
<br />
With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit {{ic|A}} requires the unit {{ic|B}} to be running before {{ic|A}} is started. In that case add {{ic|1=Requires=B}} and {{ic|1=After=B}} to the {{ic|[Unit]}} section of {{ic|A}}. If the dependency is optional, add {{ic|1=Wants=B}} and {{ic|1=After=B}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, {{ic|network.target}} is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since {{ic|network.target}} is started anyway.<br />
<br />
=== Type ===<br />
<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
<br />
* {{ic|1=Type=simple}}: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so systemd can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: This is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=}} as well so that systemd still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: Identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by {{ic|libsystemd-daemon.so}}.<br />
* {{ic|1=Type=dbus}}: The service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
=== Replacing provided unit files ===<br />
<br />
The unit files in {{ic|/etc/systemd/system/}} take precedence over the ones in {{ic|/usr/lib/systemd/system/}}.<br />
To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from {{ic|/usr/lib/}} to {{ic|/etc/}} and make your changes there. Alternatively you can use {{ic|.include}} to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:<br />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<br />
{{Tip|You can use {{ic|systemd-delta}} to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
=== Syntax highlighting for units within Vim ===<br />
<br />
Syntax highlighting for systemd unit files within [[Vim]] can be enabled by installing {{AUR|vim-systemd}} from the [[Arch User Repository|AUR]].<br />
<br />
== Targets ==<br />
<br />
Systemd uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''targets'' are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are systemd ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command.<br />
<br />
=== Get current targets ===<br />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
$ systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd ''target'' as {{ic|/etc/systemd/system/<your target>}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/<your target>.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
<br />
{| border="1"<br />
! SysV Runlevel !! systemd Target !! Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current target ===<br />
<br />
In systemd targets are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<br />
This will only change the current target, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default target to boot into ===<br />
<br />
The standard target is {{ic|default.target}}, which is aliased by default to {{ic|graphical.target}} (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following [[kernel parameters]] to your bootloader:<br />
<br />
{{Tip|The {{ic|.target}} extension can be left out.}}<br />
<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change {{ic|default.target}}. This can be done using {{ic|systemctl}}:<br />
<br />
# systemctl enable multi-user.target<br />
<br />
The effect of this command is outputted by {{ic|systemctl}}; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
<br />
[Install]<br />
Alias=default.target<br />
<br />
is in the target's configuration file. Currently, {{ic|multi-user.target}} and {{ic|graphical.target}} both have it.<br />
<br />
== Journal ==<br />
<br />
Since version 38, systemd has its own logging system, the journal. Therefore, running a syslog daemon is no longer required. To read the log, use:<br />
<br />
# journalctl<br />
<br />
By default (when {{ic|Storage&#61;}} is set to {{ic|auto}} in {{ic|/etc/systemd/journald.conf}}), the journal writes to {{ic|/var/log/journal/}}. If the directory {{ic|/var/log/journal/}} does not exist (e.g. if you or some program delete it), systemd will '''not''' create it automatically, but instead write its logs to {{ic|/run/systemd/journal}}. This means that logs will be lost on reboot.<br />
<br />
=== Filtering output ===<br />
<br />
{{ic|journalctl}} allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages by a specific executable:<br />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# journalctl -u netcfg<br />
<br />
See {{ic|man journalctl}} and {{ic|systemd.journal-fields}} for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. E.g. with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with syslog ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). The {{pkg|syslog-ng}} package in the repositories automatically provides the necessary configuration.<br />
<br />
# systemctl enable syslog-ng<br />
<br />
== Running DEs under systemd ==<br />
<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]] and [[LightDM]].<br />
<br />
# systemctl enable kdm<br />
<br />
This should work out of the box. If not, you might have a {{ic|default.target}} set manually or from a older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|<br />
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and systemd will use its stock {{ic|default.target}} (i.e. {{ic|graphical.target}}).<br />
<br />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using systemd-logind ===<br />
<br />
{{Note|As of 2012-10-30, [[ConsoleKit]] has been [https://www.archlinux.org/news/consolekit-replaced-by-logind/ replaced by systemd-logind] as the default mechanism to login to the DE.}}<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. All [[PolicyKit]] actions like suspending the system or mounting external drives will work out of the box.<br />
<br />
$ loginctl show-session $XDG_SESSION_ID<br />
<br />
== Optimization ==<br />
<br />
=== Analyzing the boot process ===<br />
<br />
==== Using systemd-analyze ====<br />
<br />
Systemd provides a tool called {{ic|systemd-analyze}} that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install {{Pkg|python2-dbus}} and {{Pkg|python2-cairo}} to use it.<br />
<br />
To see how much time was spent in kernelspace and userspace on boot, simply use:<br />
<br />
$ systemd-analyze<br />
<br />
{{Tip|To see how much time was spent in the initramfs, append the {{ic|timestamp}} hook to your {{ic|HOOKS}} array in {{ic|/etc/[[mkinitcpio]].conf}} and as root, rebuild your initramfs with {{ic|mkinitcpio -p linux}} }}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process graphically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Using bootchart ====<br />
<br />
You could also use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2}} package from [[AUR]] comes with an undocumented systemd service. After you've installed bootchart2 do:<br />
<br />
# systemctl enable bootchart<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Enabling readahead ===<br />
<br />
Systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:<br />
<br />
# systemctl enable systemd-readahead-collect systemd-readahead-replay<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
=== Forcing early start for services ===<br />
<br />
One central feature of systemd is [[D-Bus]] and socket activation. This causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like [[UPower]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
# systemctl enable upower<br />
<br />
This will cause systemd to start UPower as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
=== Less output during boot ===<br />
<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
=== Creating shell shortcuts ===<br />
<br />
Systemd daemon management requires a bit more text entry to accomplish tasks such as start, stopped, enabling, checking status, etc. The following functions can be added to one's {{ic|~/.bashrc}} file to help streamline interactions with systemd and to improve the overall experience.<br />
<br />
{{bc|<br />
# simplified systemd command, for instance "sudo systemctl stop xxx" - > "0.stop xxx"<br />
if ! systemd-notify --booted;<br />
then # for not systemd<br />
0.start() {<br />
sudo rc.d start $@<br />
}<br />
<br />
0.restart() {<br />
sudo rc.d restart $@<br />
}<br />
<br />
0.stop() {<br />
sudo rc.d stop $@<br />
}<br />
else<br />
# start systemd service<br />
0.start() {<br />
sudo systemctl start $@<br />
}<br />
# restart systemd service<br />
0.restart() {<br />
sudo systemctl restart $@<br />
}<br />
# stop systemd service<br />
0.stop() {<br />
sudo systemctl stop $@<br />
}<br />
# enable systemd service<br />
0.enable() {<br />
sudo systemctl enable $@<br />
}<br />
# disable a systemd service<br />
0.disable() {<br />
sudo systemctl disable $@<br />
}<br />
# show the status of a service<br />
0.status() {<br />
systemctl status $@<br />
}<br />
# reload a service configuration<br />
0.reload() {<br />
sudo systemctl reload $@<br />
}<br />
# list all running service<br />
0.list() {<br />
systemctl<br />
}<br />
# list all failed service<br />
0.failed () {<br />
systemctl --failed<br />
}<br />
# list all systemd available unit files<br />
0.list-files() {<br />
systemctl list-unit-files<br />
}<br />
# check the log<br />
0.log() {<br />
sudo journalctl<br />
}<br />
# show wants<br />
0.wants() {<br />
systemctl show -p "Wants" $1.target<br />
}<br />
# analyze the system<br />
0.analyze() {<br />
systemd-analyze $@<br />
}<br />
fi<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Shutdown/reboot takes terribly long ===<br />
<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. Systemd waits some time for each service to exit before trying to kill it. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
== See also ==<br />
<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official Web Site]<br />
*[http://0pointer.de/public/systemd-man/ Manual Pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug systemd problems]<br />
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Booting up: Tools and tips for systemd, a Linux init tool. In The H]<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]<br />
*[http://0pointer.de/blog/projects/why.html most recent summary]<br />
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]</div>Rad3khttps://wiki.archlinux.org/index.php?title=MPX&diff=118160MPX2010-09-26T22:16:50Z<p>Rad3k: Created an alternative page with a redirect to "Multi-pointer X"</p>
<hr />
<div>#REDIRECT [[Multi-pointer X]]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118122Multi-pointer X2010-09-26T16:03:34Z<p>Rad3k: Removed the stub status</p>
<hr />
<div>[[Category:X Server (English)]]<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Configuration ==<br />
=== configuration file ===<br />
{{Note|Information how to configure multipointer with {{Filename|xorg.conf}} should be added}}<br />
=== xinput utility ===<br />
More pointers can be added with {{Codeline|xinput}} CLI utility. Here is how to do it:<br />
<br />
Create a new pair of master devices named "''name'' pointer" and "''name'' keyboard":<br />
xinput create-master ''[name]''<br />
<br />
Find out names and ids of existing slave devices:<br />
xinput list<br />
<br />
Reattach slave devices to newly created master devices:<br />
xinput reattach ''[slave device name or id]'' ''[master device name or id]''<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.<br />
<br />
== Useful links ==<br />
* [http://www.x.org/wiki/Development/Documentation/MPX Xorg wiki article]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118121Multi-pointer X2010-09-26T15:08:59Z<p>Rad3k: /* Configuration */ Expanded the section</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Configuration ==<br />
=== configuration file ===<br />
{{Note|Information how to configure multipointer with {{Filename|xorg.conf}} should be added}}<br />
=== xinput utility ===<br />
More pointers can be added with {{Codeline|xinput}} CLI utility. Here is how to do it:<br />
<br />
Create a new pair of master devices named "''name'' pointer" and "''name'' keyboard":<br />
xinput create-master ''[name]''<br />
<br />
Find out names and ids of existing slave devices:<br />
xinput list<br />
<br />
Reattach slave devices to newly created master devices:<br />
xinput reattach ''[slave device name or id]'' ''[master device name or id]''<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.<br />
<br />
== Useful links ==<br />
* [http://www.x.org/wiki/Development/Documentation/MPX Xorg wiki article]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118120Multi-pointer X2010-09-26T14:32:44Z<p>Rad3k: /* Useful links */ Added link to Xorg wiki article</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Configuration ==<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.<br />
<br />
== Useful links ==<br />
* [http://www.x.org/wiki/Development/Documentation/MPX Xorg wiki article]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118119Multi-pointer X2010-09-26T14:30:22Z<p>Rad3k: </p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Configuration ==<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.<br />
<br />
== Useful links ==</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118118Multi-pointer X2010-09-26T14:22:27Z<p>Rad3k: Added few sections</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, the input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices always come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it always grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Configuration ==<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.<br />
<br />
== Useful links ==</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118114Multi-pointer X2010-09-26T13:00:35Z<p>Rad3k: /* Software support */ Added "Window managers" subsection</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, the input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices always come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it always grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
<br />
=== Window managers ===<br />
In window managers multi-pointer support could mean:<br />
* recognizing multiple focuses<br />
* setting the client pointer of a focused window to the pointer that "focused" it<br />
* letting move and resize windows simultaneously<br />
As of 26 September 2010, none of major window managers support multi-pointer.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118113Multi-pointer X2010-09-26T12:48:24Z<p>Rad3k: /* Introduction */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate physical input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, the input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices always come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it always grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
As of 26 September 2010, none of major window managers fully support multi-pointer.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118112Multi-pointer X2010-09-26T12:35:44Z<p>Rad3k: /* Client pointer */ Corrected a typo</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, the input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices always come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it always grabs a master device that is set as its client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
As of 26 September 2010, none of major window managers fully support multi-pointer.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118111Multi-pointer X2010-09-26T12:34:57Z<p>Rad3k: Expanded the article by "Basic concepts" and "Software support" sections.</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors (each with its own keyboard focus) on the screen and control them with separate input devices. It can be used as a crude [[Xorg multiseat|mutliseat]] solution.<br />
<br />
== Basic concepts ==<br />
=== Master and slave devices ===<br />
With the introduction of XInput2, the input devices are organised in a two-level hierarchy:<br />
* Master devices, which correspond to cursors on the screen<br />
* Slave devices, which correspond to physical input devices<br />
Master devices always come in pairs, one for pointer and one for keyboard. Each master device can have a number of slave devices attached, so that cursor of a master device can be controlled by all slave devices attached to it.<br />
<br />
=== Client pointer ===<br />
When an application grabs input (e.g. a fullscreen game), it always grabs a master device that is set as it's client pointer. By default, the client pointer is set to "Virtual core pointer", but it can be set to a different one with a "xinput" utility.<br />
<br />
== Software support ==<br />
It is possible to use multi-pointer with software that doesn't explicitly support it, but with limited functionality. Applications which don't support it won't distinguish between multiple pointers and will interpret all actions as if done by single master device pair.<br />
As of 26 September 2010, none of major window managers fully support multi-pointer.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118107Multi-pointer X2010-09-26T11:19:05Z<p>Rad3k: </p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors on the screen and control them with separate input devices.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118104Multi-pointer X2010-09-26T10:31:54Z<p>Rad3k: moved Mutli-pointer X to Multi-pointer X: Typo in article name</p>
<hr />
<div>[[Category: X Server]]<br />
[[Category: Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors on the screen and control them with separate input devices.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Multi-pointer_X&diff=118103Multi-pointer X2010-09-26T10:30:11Z<p>Rad3k: Created an article stub.</p>
<hr />
<div>[[Category: X Server]]<br />
[[Category: Stub]]<br />
{{Stub}}<br />
<br />
== Introduction ==<br />
Xorg servers starting from version 1.7 have a feature called "multi-pointer". Basically it allows to have multiple mouse cursors on the screen and control them with separate input devices.</div>Rad3khttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&diff=104426Install Arch Linux on a removable medium2010-04-22T15:33:04Z<p>Rad3k: /* Optimizing for the lifespan of flash memory */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This page discusses how to perform a regular Arch installation onto a USB key (or "flash drive"). The result will be a system that will be updated through normal use. Consider whether you're instead interested in [[Putting installation media on a USB key]].<br />
<br />
== Grab a big enough USB key ==<br />
If installing KDE and a large amount of applications, 3 GiB is the recommended minimum. GNOME and Xfce4, along with a typical set of packages for a desktop (GIMP, Pidgin, OpenOffice, Firefox, flashplugin) can be installed on a 2 GiB stick, leaving a small amount of room for user data.<br />
<br />
== Grab CD ==<br />
An Arch Linux CD can be used to install Arch onto the USB key, via booting the CD and installing using the regular method. Or, if you have another linux computer available (it needs not be Arch), you can follow the instructions to [[Install_from_Existing_Linux|install from existing linux]], and then skip to the configuration section.<br />
<br />
== Boot == <br />
It may be necessary to boot with the arch-noscsi kernel, if the usb-storage module gives errors when loaded with the standard kernel. After the system has booted, modprobe sd_mod and usb_storage (There are reports that the 7.2 CD contains no sd_mod; simply omit loading this module, as you can safely proceed without it). The USB key will appear in a few moments, after the device has settled. dmesg will show a device scan once the device has settled:<br />
<br />
usbcore: registered new interface driver usb-storage<br />
usb-storage: device found at 4<br />
usb-storage: waiting for device to settle before scanning<br />
USB Mass Storage support registered.<br />
scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 9407 PQ: 0 ANSI: 0<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sdc: sdc1<br />
sd 6:0:0:0: [sdc] Attached SCSI removable disk<br />
sd 6:0:0:0: Attached scsi generic sg3 type 0<br />
usb-storage: device scan complete<br />
<br />
It is the sdX: sdXY line that is important, as it shows the device name (in this case, sdc) and the partitions available on it (in this case, one, sdc1), if any.<br />
<br />
== Installation ==<br />
<br />
Launch the installer (/arch/setup). The setup process can be done normally, with only a few pointers:<br />
<br />
* It is best to manually partition the drive, as the auto partition may not work, and will create unnecessary partitions.<br />
* ext2 is the best option for use with a flash based storage medium, such as a USB key. Flash has a limited number of writes, and a journaling file system will use up these writes considerably faster than a non-journaled filesystem, which will greatly reduce the lifespan of the key. For this same reason, it is best to forgo a swap partition. Note that this does not effect installing onto a USB hard drive.<br />
* When it asks you whether you want USB boot support, choose ''yes''.<br />
<br />
== Configuration ==<br />
* Make sure that /etc/fstab includes the correct partition information for /, and for any other partitions on the USB key. Keep in mind the setup of the target machine when putting in the device names, as they may be different from the machine you are using for the installation. Example: if the installation machine has one hard drive, your USB key will likely be sdb. The target machine, however, may have no hard drives, in which case your USB key will likely be sda.<br />
<br />
* menu.lst, the Grub configuration file, should be edited to (loosely) match the following, replacing sda1 with the partition of the key on the target machine (note that, as grub is installed on the USB key, the key will always be hd0,0).<br />
<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
<br />
* Regenerate the initrd image, kernel26.img. Edit /etc/mkinitcpio.conf, changing the hooks to include (at a minimum): "base udev ide usb filesystems" ('''''Note:''' if using the 7.2 CD, and installing from the CD, you will have mkinitrd instead of mkinitcpio. During the configuration, you will be asked to edit mkinitrd.conf; simply change REMOVE_USB=1 to REMOVE_USB=0 and ignore the following command''). Then rebuild the image by issuing:<br />
# mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img.<br />
<br />
'''''Note:''' The kernel version (-k) must be the kernel version in the USB key, not the live cd's kernel version.''<br />
<br />
== Tips ==<br />
=== USB Support ===<br />
Should you see that the /arch/setup correctly installed a system on to your USB drive but it stills failed to boot from it by complaining that it could not find the root file system even though it had been specified with UUIDs, then you are most likely missing support for USB. In this case, boot back into your Arch Setup CD/USB media and do the following:<br />
<br />
* Edit the /etc/mkinitcpio.conf, and add "usb" to the "HOOKS=" line after udev:<br />
HOOKS="base udev '''usb''' autodetect pata scsci sata filesystems"<br />
* Mount your USB drive's first partition, most likely /dev/sdb1:<br />
# mount /dev/sdb1 /mnt <br />
* Regenerate the initrd image by running: <br />
# mkinitcpio -c /etc/mkinitcpio.conf -g /mnt/kernel26.img<br />
<br />
=== Using UUID ===<br />
Instead of using literal partition names, you can also use the [[UUID]] of your partition. This way is much better and more manageable in a setup where the USB drive is meant to boot at multiple PC's than using the partition literal names (/dev/sdb1). Run:<br />
$ blkid<br />
to find out which one points to the regular device node (ie, /dev/sdb1) that is your key.<br />
<br />
Now you can place this device node (in the form <code>UUID=7bf1d942-7b8c-4fb7-b55a-d3c40895906d</code>) into /etc/fstab in place of the regular node (ie, /dev/sdb1). Edit also your <code>kernel</code> line in menu.lst, so it will contain something like:<br />
kernel /boot/vmlinuz26 '''root=/dev/disk/by-uuid/7bf1d942-7b8c-4fb7-b55a-d3c40895906d''' ro vga=733<br />
<br />
'''''Note:''' The files may contain UUIDs already. Also note that you specifying "root (hdX,X) is also not required when using UUIDs.''<br />
<br />
=== Painless boot on different machines without using UUID ===<br />
When using the USB key on various target machines, it is helpful to have multiple entries in GRUB, for machines with different setups. For example, the GRUB configuration could contain:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux (first drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro<br />
initrd /boot/kernel26.img<br />
<br />
As well as<br />
<br />
# (1) Arch Linux<br />
title Arch Linux (second drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sdb1 ro<br />
initrd /boot/kernel26.img<br />
<br />
And so forth, giving you the option to select a configuration for a wider variety of machines. However, changing the <code>root=</code> option in GRUB does not change /etc/fstab and you must do something (in our example using udev symlink), so the root partition will always be mounted correctly.<br />
<br />
* Run <code>udevinfo -p /sys/block/sdx/ -a</code> (where sdx is the device name of your usb key)<br />
* Find unique information pertaining to your usb key. I chose `<code>SYSFS{model}=="DataTraveler 2.0"</code>` <br />
* Make a new file: /etc/udev/udev.rules/10-my-usb-key.rules and insert: <code>KERNEL=="sd**", SYSFS{product}=="DataTraveler 2.0", SYMLINK+="WHATEVERYOUWANTOTCALLIT%n"</code> (<code>KERNEL=="sd**"</code> is because the kernel - 2.6.16 here - names all usb devices sd as it uses the scsi sub-system and you want to look at every sd device and apply the setting to every partition), with <code>SYSFS{model}==</code> being the unique identifier collected from udevinfo.<br />
* Run <code>/etc/start-udev uevents</code> and make sure the symlinks appears in /dev. <br />
* If so, edit /etc/fstab, replacing your old sdx with the new symlinks.<br />
<br />
=== Optimizing for the lifespan of flash memory ===<br />
With flash based storage, disk writes are the most expensive operations, both in terms of storage device wear and speed. Here are some tips to reduce them:<br />
* consider putting your /tmp in RAM by adding the following line to /etc/fstab:<br />
none /tmp tmpfs defaults 0 0<br />
* if you don't need your logs to be preserved between reboots, you may do the same with /var/log<br />
* if you use firefox, disable the disk cache - in "about:config", set the boolean property "browser.cache.disk.enable" to "false"<br />
<br />
== See Also ==<br />
* [[Official Arch Linux Install Guide]]<br />
* [[Installing Arch Linux from VirtualBox]]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&diff=104423Install Arch Linux on a removable medium2010-04-22T15:06:05Z<p>Rad3k: /* Optimizing for the lifespan of flash memory */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This page discusses how to perform a regular Arch installation onto a USB key (or "flash drive"). The result will be a system that will be updated through normal use. Consider whether you're instead interested in [[Putting installation media on a USB key]].<br />
<br />
== Grab a big enough USB key ==<br />
If installing KDE and a large amount of applications, 3 GiB is the recommended minimum. GNOME and Xfce4, along with a typical set of packages for a desktop (GIMP, Pidgin, OpenOffice, Firefox, flashplugin) can be installed on a 2 GiB stick, leaving a small amount of room for user data.<br />
<br />
== Grab CD ==<br />
An Arch Linux CD can be used to install Arch onto the USB key, via booting the CD and installing using the regular method. Or, if you have another linux computer available (it needs not be Arch), you can follow the instructions to [[Install_from_Existing_Linux|install from existing linux]], and then skip to the configuration section.<br />
<br />
== Boot == <br />
It may be necessary to boot with the arch-noscsi kernel, if the usb-storage module gives errors when loaded with the standard kernel. After the system has booted, modprobe sd_mod and usb_storage (There are reports that the 7.2 CD contains no sd_mod; simply omit loading this module, as you can safely proceed without it). The USB key will appear in a few moments, after the device has settled. dmesg will show a device scan once the device has settled:<br />
<br />
usbcore: registered new interface driver usb-storage<br />
usb-storage: device found at 4<br />
usb-storage: waiting for device to settle before scanning<br />
USB Mass Storage support registered.<br />
scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 9407 PQ: 0 ANSI: 0<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sdc: sdc1<br />
sd 6:0:0:0: [sdc] Attached SCSI removable disk<br />
sd 6:0:0:0: Attached scsi generic sg3 type 0<br />
usb-storage: device scan complete<br />
<br />
It is the sdX: sdXY line that is important, as it shows the device name (in this case, sdc) and the partitions available on it (in this case, one, sdc1), if any.<br />
<br />
== Installation ==<br />
<br />
Launch the installer (/arch/setup). The setup process can be done normally, with only a few pointers:<br />
<br />
* It is best to manually partition the drive, as the auto partition may not work, and will create unnecessary partitions.<br />
* ext2 is the best option for use with a flash based storage medium, such as a USB key. Flash has a limited number of writes, and a journaling file system will use up these writes considerably faster than a non-journaled filesystem, which will greatly reduce the lifespan of the key. For this same reason, it is best to forgo a swap partition. Note that this does not effect installing onto a USB hard drive.<br />
* When it asks you whether you want USB boot support, choose ''yes''.<br />
<br />
== Configuration ==<br />
* Make sure that /etc/fstab includes the correct partition information for /, and for any other partitions on the USB key. Keep in mind the setup of the target machine when putting in the device names, as they may be different from the machine you are using for the installation. Example: if the installation machine has one hard drive, your USB key will likely be sdb. The target machine, however, may have no hard drives, in which case your USB key will likely be sda.<br />
<br />
* menu.lst, the Grub configuration file, should be edited to (loosely) match the following, replacing sda1 with the partition of the key on the target machine (note that, as grub is installed on the USB key, the key will always be hd0,0).<br />
<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
<br />
* Regenerate the initrd image, kernel26.img. Edit /etc/mkinitcpio.conf, changing the hooks to include (at a minimum): "base udev ide usb filesystems" ('''''Note:''' if using the 7.2 CD, and installing from the CD, you will have mkinitrd instead of mkinitcpio. During the configuration, you will be asked to edit mkinitrd.conf; simply change REMOVE_USB=1 to REMOVE_USB=0 and ignore the following command''). Then rebuild the image by issuing:<br />
# mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img.<br />
<br />
'''''Note:''' The kernel version (-k) must be the kernel version in the USB key, not the live cd's kernel version.''<br />
<br />
== Tips ==<br />
=== USB Support ===<br />
Should you see that the /arch/setup correctly installed a system on to your USB drive but it stills failed to boot from it by complaining that it could not find the root file system even though it had been specified with UUIDs, then you are most likely missing support for USB. In this case, boot back into your Arch Setup CD/USB media and do the following:<br />
<br />
* Edit the /etc/mkinitcpio.conf, and add "usb" to the "HOOKS=" line after udev:<br />
HOOKS="base udev '''usb''' autodetect pata scsci sata filesystems"<br />
* Mount your USB drive's first partition, most likely /dev/sdb1:<br />
# mount /dev/sdb1 /mnt <br />
* Regenerate the initrd image by running: <br />
# mkinitcpio -c /etc/mkinitcpio.conf -g /mnt/kernel26.img<br />
<br />
=== Using UUID ===<br />
Instead of using literal partition names, you can also use the [[UUID]] of your partition. This way is much better and more manageable in a setup where the USB drive is meant to boot at multiple PC's than using the partition literal names (/dev/sdb1). Run:<br />
$ blkid<br />
to find out which one points to the regular device node (ie, /dev/sdb1) that is your key.<br />
<br />
Now you can place this device node (in the form <code>UUID=7bf1d942-7b8c-4fb7-b55a-d3c40895906d</code>) into /etc/fstab in place of the regular node (ie, /dev/sdb1). Edit also your <code>kernel</code> line in menu.lst, so it will contain something like:<br />
kernel /boot/vmlinuz26 '''root=/dev/disk/by-uuid/7bf1d942-7b8c-4fb7-b55a-d3c40895906d''' ro vga=733<br />
<br />
'''''Note:''' The files may contain UUIDs already. Also note that you specifying "root (hdX,X) is also not required when using UUIDs.''<br />
<br />
=== Painless boot on different machines without using UUID ===<br />
When using the USB key on various target machines, it is helpful to have multiple entries in GRUB, for machines with different setups. For example, the GRUB configuration could contain:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux (first drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro<br />
initrd /boot/kernel26.img<br />
<br />
As well as<br />
<br />
# (1) Arch Linux<br />
title Arch Linux (second drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sdb1 ro<br />
initrd /boot/kernel26.img<br />
<br />
And so forth, giving you the option to select a configuration for a wider variety of machines. However, changing the <code>root=</code> option in GRUB does not change /etc/fstab and you must do something (in our example using udev symlink), so the root partition will always be mounted correctly.<br />
<br />
* Run <code>udevinfo -p /sys/block/sdx/ -a</code> (where sdx is the device name of your usb key)<br />
* Find unique information pertaining to your usb key. I chose `<code>SYSFS{model}=="DataTraveler 2.0"</code>` <br />
* Make a new file: /etc/udev/udev.rules/10-my-usb-key.rules and insert: <code>KERNEL=="sd**", SYSFS{product}=="DataTraveler 2.0", SYMLINK+="WHATEVERYOUWANTOTCALLIT%n"</code> (<code>KERNEL=="sd**"</code> is because the kernel - 2.6.16 here - names all usb devices sd as it uses the scsi sub-system and you want to look at every sd device and apply the setting to every partition), with <code>SYSFS{model}==</code> being the unique identifier collected from udevinfo.<br />
* Run <code>/etc/start-udev uevents</code> and make sure the symlinks appears in /dev. <br />
* If so, edit /etc/fstab, replacing your old sdx with the new symlinks.<br />
<br />
=== Optimizing for the lifespan of flash memory ===<br />
With flash based storage, disk writes are the most expensive operations, both in terms of storage device lifespan and speed. Here are some tips to reduce them:<br />
* consider putting your /tmp in RAM by adding the following line to /etc/fstab:<br />
none /tmp tmpfs defaults 0 0<br />
* if you don't need your logs to be preserved between reboots, you may do the same with /var/log<br />
* if you use firefox, disable the disk cache - in "about:config", set the boolean property "browser.cache.disk.enable" to "false"<br />
<br />
== See Also ==<br />
* [[Official Arch Linux Install Guide]]<br />
* [[Installing Arch Linux from VirtualBox]]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&diff=104422Install Arch Linux on a removable medium2010-04-22T14:59:01Z<p>Rad3k: /* Tips */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
This page discusses how to perform a regular Arch installation onto a USB key (or "flash drive"). The result will be a system that will be updated through normal use. Consider whether you're instead interested in [[Putting installation media on a USB key]].<br />
<br />
== Grab a big enough USB key ==<br />
If installing KDE and a large amount of applications, 3 GiB is the recommended minimum. GNOME and Xfce4, along with a typical set of packages for a desktop (GIMP, Pidgin, OpenOffice, Firefox, flashplugin) can be installed on a 2 GiB stick, leaving a small amount of room for user data.<br />
<br />
== Grab CD ==<br />
An Arch Linux CD can be used to install Arch onto the USB key, via booting the CD and installing using the regular method. Or, if you have another linux computer available (it needs not be Arch), you can follow the instructions to [[Install_from_Existing_Linux|install from existing linux]], and then skip to the configuration section.<br />
<br />
== Boot == <br />
It may be necessary to boot with the arch-noscsi kernel, if the usb-storage module gives errors when loaded with the standard kernel. After the system has booted, modprobe sd_mod and usb_storage (There are reports that the 7.2 CD contains no sd_mod; simply omit loading this module, as you can safely proceed without it). The USB key will appear in a few moments, after the device has settled. dmesg will show a device scan once the device has settled:<br />
<br />
usbcore: registered new interface driver usb-storage<br />
usb-storage: device found at 4<br />
usb-storage: waiting for device to settle before scanning<br />
USB Mass Storage support registered.<br />
scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 9407 PQ: 0 ANSI: 0<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sd 6:0:0:0: [sdc] 3994624 512-byte hardware sectors (2045 MB)<br />
sd 6:0:0:0: [sdc] Write Protect is off<br />
sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00<br />
sd 6:0:0:0: [sdc] Assuming drive cache: write through<br />
sdc: sdc1<br />
sd 6:0:0:0: [sdc] Attached SCSI removable disk<br />
sd 6:0:0:0: Attached scsi generic sg3 type 0<br />
usb-storage: device scan complete<br />
<br />
It is the sdX: sdXY line that is important, as it shows the device name (in this case, sdc) and the partitions available on it (in this case, one, sdc1), if any.<br />
<br />
== Installation ==<br />
<br />
Launch the installer (/arch/setup). The setup process can be done normally, with only a few pointers:<br />
<br />
* It is best to manually partition the drive, as the auto partition may not work, and will create unnecessary partitions.<br />
* ext2 is the best option for use with a flash based storage medium, such as a USB key. Flash has a limited number of writes, and a journaling file system will use up these writes considerably faster than a non-journaled filesystem, which will greatly reduce the lifespan of the key. For this same reason, it is best to forgo a swap partition. Note that this does not effect installing onto a USB hard drive.<br />
* When it asks you whether you want USB boot support, choose ''yes''.<br />
<br />
== Configuration ==<br />
* Make sure that /etc/fstab includes the correct partition information for /, and for any other partitions on the USB key. Keep in mind the setup of the target machine when putting in the device names, as they may be different from the machine you are using for the installation. Example: if the installation machine has one hard drive, your USB key will likely be sdb. The target machine, however, may have no hard drives, in which case your USB key will likely be sda.<br />
<br />
* menu.lst, the Grub configuration file, should be edited to (loosely) match the following, replacing sda1 with the partition of the key on the target machine (note that, as grub is installed on the USB key, the key will always be hd0,0).<br />
<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
<br />
* Regenerate the initrd image, kernel26.img. Edit /etc/mkinitcpio.conf, changing the hooks to include (at a minimum): "base udev ide usb filesystems" ('''''Note:''' if using the 7.2 CD, and installing from the CD, you will have mkinitrd instead of mkinitcpio. During the configuration, you will be asked to edit mkinitrd.conf; simply change REMOVE_USB=1 to REMOVE_USB=0 and ignore the following command''). Then rebuild the image by issuing:<br />
# mkinitcpio -k 2.6.25-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img.<br />
<br />
'''''Note:''' The kernel version (-k) must be the kernel version in the USB key, not the live cd's kernel version.''<br />
<br />
== Tips ==<br />
=== USB Support ===<br />
Should you see that the /arch/setup correctly installed a system on to your USB drive but it stills failed to boot from it by complaining that it could not find the root file system even though it had been specified with UUIDs, then you are most likely missing support for USB. In this case, boot back into your Arch Setup CD/USB media and do the following:<br />
<br />
* Edit the /etc/mkinitcpio.conf, and add "usb" to the "HOOKS=" line after udev:<br />
HOOKS="base udev '''usb''' autodetect pata scsci sata filesystems"<br />
* Mount your USB drive's first partition, most likely /dev/sdb1:<br />
# mount /dev/sdb1 /mnt <br />
* Regenerate the initrd image by running: <br />
# mkinitcpio -c /etc/mkinitcpio.conf -g /mnt/kernel26.img<br />
<br />
=== Using UUID ===<br />
Instead of using literal partition names, you can also use the [[UUID]] of your partition. This way is much better and more manageable in a setup where the USB drive is meant to boot at multiple PC's than using the partition literal names (/dev/sdb1). Run:<br />
$ blkid<br />
to find out which one points to the regular device node (ie, /dev/sdb1) that is your key.<br />
<br />
Now you can place this device node (in the form <code>UUID=7bf1d942-7b8c-4fb7-b55a-d3c40895906d</code>) into /etc/fstab in place of the regular node (ie, /dev/sdb1). Edit also your <code>kernel</code> line in menu.lst, so it will contain something like:<br />
kernel /boot/vmlinuz26 '''root=/dev/disk/by-uuid/7bf1d942-7b8c-4fb7-b55a-d3c40895906d''' ro vga=733<br />
<br />
'''''Note:''' The files may contain UUIDs already. Also note that you specifying "root (hdX,X) is also not required when using UUIDs.''<br />
<br />
=== Painless boot on different machines without using UUID ===<br />
When using the USB key on various target machines, it is helpful to have multiple entries in GRUB, for machines with different setups. For example, the GRUB configuration could contain:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux (first drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro<br />
initrd /boot/kernel26.img<br />
<br />
As well as<br />
<br />
# (1) Arch Linux<br />
title Arch Linux (second drive)<br />
root (hd0,0)<br />
kernel /boot/vmlinuz26 root=/dev/sdb1 ro<br />
initrd /boot/kernel26.img<br />
<br />
And so forth, giving you the option to select a configuration for a wider variety of machines. However, changing the <code>root=</code> option in GRUB does not change /etc/fstab and you must do something (in our example using udev symlink), so the root partition will always be mounted correctly.<br />
<br />
* Run <code>udevinfo -p /sys/block/sdx/ -a</code> (where sdx is the device name of your usb key)<br />
* Find unique information pertaining to your usb key. I chose `<code>SYSFS{model}=="DataTraveler 2.0"</code>` <br />
* Make a new file: /etc/udev/udev.rules/10-my-usb-key.rules and insert: <code>KERNEL=="sd**", SYSFS{product}=="DataTraveler 2.0", SYMLINK+="WHATEVERYOUWANTOTCALLIT%n"</code> (<code>KERNEL=="sd**"</code> is because the kernel - 2.6.16 here - names all usb devices sd as it uses the scsi sub-system and you want to look at every sd device and apply the setting to every partition), with <code>SYSFS{model}==</code> being the unique identifier collected from udevinfo.<br />
* Run <code>/etc/start-udev uevents</code> and make sure the symlinks appears in /dev. <br />
* If so, edit /etc/fstab, replacing your old sdx with the new symlinks.<br />
<br />
=== Optimizing for the lifespan of flash memory ===<br />
With flash based storage, disk writes are the most expensive operations, both in terms of storage device lifespan and speed. Here are some tips to reduce them:<br />
* consider putting your /tmp in RAM by adding the following line to /etc/fstab:<br />
none /tmp tmpfs defaults 0 0<br />
<br />
== See Also ==<br />
* [[Official Arch Linux Install Guide]]<br />
* [[Installing Arch Linux from VirtualBox]]</div>Rad3khttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=98168Dm-crypt2010-02-24T21:06:49Z<p>Rad3k: /* Storing the key between MBR and 1st partition */ added a parenthesised note to correct some information</p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
== Why Encryption? ==<br />
Encryption is useful for two (related) reasons. Firstly, it prevents anyone with physical access to your computer, and your hard drive in particular, from getting the data from it (unless they have your passphrase/key). Secondly, it allows you to wipe the data on your hard drive with far more confidence in the event of you selling or discarding your drive.<br />
<br />
Basically, it supplements the access control mechanisms of the operating system (like file permissions) by making it harder to bypass the operating system by inserting a boot CD, for example. Encrypting the root partition prevents anyone from using this method to insert viruses or trojans onto your computer.<br />
<br />
Note that we're not encrypting the boot partition - the bootloader needs to read that one!<br />
<br />
'''ATTENTION: Having encrypted partitions does not protect you from all possible attacks. The encryption is only as good as your key management, and there are other ways to break into computers while they are running. Read the CAVEATS section below!'''<br />
<br />
== Why LUKS for dm-crypt? ==<br />
There are either 3 or 4 rival disk encryption standards in Linux, depending on how you count them.<br />
<br />
The old cryptoloop is deprecated: it's old, insecure and unreliable.<br />
<br />
A much better version, loop-AES (http://loop-aes.sourceforge.net/), was created but, due to politics, never became favorable with the kernel developers. It's far more secure than either cryptoloop or straight device-mapper encryptions (and probably faster than any of the other 3 options), but is not user-friendly. It also requires non-standard kernel support, which ARCH's kernel26 doesn't have.<br />
<br />
The standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]) is another choice.<br />
<br />
[http://code.google.com/p/cryptsetup/ LUKS] essentially makes management of encrypted partitions easier. Without going into the hairy details (check out the [http://code.google.com/p/cryptsetup/ LUKS home page] if you're interested), it stores all the needed setup information on the disk itself. All you need then is the password, which can be in a separate file if you like. The Linux implementation uses dm-crypt and it can have up to eight different passwords, which can be changed or revoked easily. It is also supported by mkinitcpio in ARCH linux, which is nice.<br />
<br />
== Caveats ==<br />
<br />
=== Security (encryption) ===<br />
Disk encryption is not the be-all and end-all of security. Why not? Well, for a start, it won't prevent people from hacking into a running computer (either over the network or at a console) if there is a security hole to exploited (and there invariably is). There are a dozen and one things you can (and should) do to secure your computer against this type of attack, but they are all outside the scope of this document.<br />
<br />
What's more, even in situations this type of encryption is useful for (physical access to storage media), it isn't worth a thing if someone has your key. In other words, if someone finds out or guesses your passphrase, or gets access to your external key file if you're using one, they can unlock the encryption on the hard drive in exactly the same way that you can.<br />
<br />
What does this mean for you? Well, if you use an external key file, keep the device it is on '''SAFE'''. Attach it to your keyring or whatever. If you use a passphrase, '''make it hard to guess'''. There are [http://www.google.co.uk/search?q=create+secure+password hundreds of documents] all over the internet telling you how to come up with a secure passphrase; we're not going to go over it here. Note, however, that we use the term "passphrase": '''it doesn't have to be a single word'''.<br />
<br />
== Getting started ==<br />
If you're not starting from an unused hard drive, '''BACK UP YOUR DATA!''' I cannot stress this enough. Ideally, you should be doing this regularly anyway, and it's particularly important with an encrypted hard drive. But beware: if you have unencrypted backups, is there any point in having an encrypted hard drive? Think about where you store your backups.<br />
<br />
'''Note:''' if you want to have encrypted swap, read the section below about Encrypted Swap and decide how you want to set it up ''before'' you start the rest of this HOWTO.<br />
<br />
Since Arch Linux 2009.08 the Arch installer provides a comfortable and easy way to configure dm_crypt (also in combination with [[LVM]]).<br />
Of course you can also do all the work manually.<br />
In either case it's recommended to overwrite the disk to wipe out former unencrypted content.<br />
<br />
== Preparation ==<br />
=== Overwriting ===<br />
Repartitioning and formatting your drive will only remove the filesystem metadata and will mostly leave the actual data intact, allowing determined attackers to recover data using tools like [http://foremost.sourceforge.net/ Foremost]. If your harddisk contained sensitive data from previous use, you might want to overwrite this data. Contrary to popular believe overwriting several times or using random data as source serves no purpose. Data won't be recoverable after being overwritten by zeros. [http://www.springerlink.com/content/408263ql11460147/]<br />
<br />
To overwrite your disk with zeros you can use<br />
# dd if=/dev/zero of=/dev/sda bs=1M<br />
<br />
If you want to check for bad blocks while writing you can use badblocks. <br />
The <tt>badblocks</tt> command will check your disk for bad blocks while writing random data. The pseudorandom algorithm used by this command is faster (although "less random") than <tt>/dev/urandom</tt>, so it can be useful for large disks. [[frandom]] is a fast random generator you might want to use for large disk.<br />
<br />
# badblocks -c 10240 -w -t random -s -v /dev/sda<br />
This will test blocks in groups of 10240 (i.e. 10MB) at a time, writing over them with random data and showing progress as it goes.<br />
<br />
However it should be noted that the pseudo random data generated by badblocks does not serve any other purpose than slowing down the wiping of your drive.<br />
<br />
== Arch Linux Installer (>2009.08) ==<br />
Since Arch Linux 2009.08 the installer supports dm_crypt and LVM (and combination of both) out of the box.<br />
<br />
Just run the installer as usual, i.e. follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]].<br />
When you reach the "Prepare Hard Drive(s)" don't use "Auto-Prepare" but set up your partitions manually.<br />
Beware that you '''have to''' create a separate unencrypted <tt>/boot</tt> partition, or GRUB/LILO has no chance to load the operating system afterwards.<br />
The most important step towards an encrypted system is done in the "Manually Configure ..." step.<br />
<br />
=== Configuring filesystems and mountpoints ===<br />
At first select the device corresponding to your unencrypted <tt>/boot</tt> partition, choose e.g. ext2 as filesystem and select <tt>/boot</tt> as the mountpoint.<br />
For all other partitions you created and which you want to be encrypted select dm_crypt in the filesystem dialog.<br />
You should enter a label for the encrypted device, e.g. 'sda2crypt', or simply 'root'.<br />
<br />
Here is an example listing how it may look like:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt<br />
/dev/sda3 raw->dm_crypt;yes;no_mountpoint;no_opts;sda3crypt<br />
/dev/mapper/sda2crypt dm_crypt->ext3;yes;/;no_opts;no_label;no_params<br />
/dev/mapper/sda3crypt dm_crypt->ext3;yes;/home;no_opts;no_label;no_params<br />
<br />
'''Note''': you can also put a LVM inside the dm_crypt partition, or vice versa a dm_crypt partition inside a LVM volume. See [[#Encrypting a LVM setup|Encrypting a LVM setup]] for details.<br />
<br />
When you press 'DONE' the installer will create and mount the filesystem configuration automatically. You will be prompted for a LUKS passphrase 3 times (2x to set a new passphrase, 1x to unlock the device).<br />
<br />
That's it with the dm_crypt specific part for so far. Select your desired packages and install the system.<br />
The installer should perform all steps necessary for configuring the boot and mount process of your new system.<br />
You can check the configuration afterwards and compare them to the one in the section about manual configuration.<br />
Especially the HOOKS section in <tt>mkinitcpio.conf</tt> is important for an encrypted root partition.<br />
<br />
=== Further tweaks for USB keyfile authentication ===<br />
When you're planning to use a keyfile on an USB stick instead of passphrase authentication you have to do some further tweaks in <tt>mkinitcpio.conf</tt>:<br />
To mount the USB device with your keyfile in the boot process add ''usb'' somewhere before ''encrypt'' in the HOOKS variable e.g.<br />
HOOKS=" ... sata '''usb''' usbinput keymap encrypt filesystems ... "<br />
And for a FAT formated USB stick add the following to the MODULES variable<br />
MODULES=" ... '''nls_cp437 vfat''' ... "<br />
<br />
After exiting the installer you can now create a keyfile onto USB stick your for authentication.<br />
This is for example done with the following commands. Check out section [[#Generating the keyfile|Generating the keyfile]] for further details.<br />
<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile<br />
<br />
<br />
== Manually configuring LUKS ==<br />
As noted [[#Overwriting|above]] it's recommended for security reasons to overwrite the partition before going any further.<br />
<br />
=== Partitioning ===<br />
At first set up your partitions as you want. Make sure you have a separate partition for /boot. If you think about it, this is absolutely necessary. If your /boot partition is encrypted, then your bootloader would not be able to read the kernel image and you would not get far.<br />
# cfdisk /dev/sda<br />
<br />
The following - indicative - partition layout will be used:<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> swap<br />
/dev/sda3 -> /<br />
/dev/sda4 -> /home<br />
/dev/sda5 -> /tmp # especially useful if you don't want to encrypt the entire root (/) partition<br />
<br />
=== Loading kernel modules ===<br />
'''Note:''' this article will use XTS-AES as encryption algorithm because it was standardized as IEEE P1619 Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices and it is quite secure, however the XTS mode is still flagged as "experimental" in the Linux kernel, so if you want something less secure but more proven, you should go with the CBC-ESSIV mode. The XTS mode is supported by Linux 2.6.24 upwards (ISO of Arch 2008.06 upwards).<br />
<br />
'''Note:''' The XTS mode uses two keys of the same size, therefore available sizes (using XTS-AES) are 256 (128 * 2), 384 (192 * 2) and 512 (256 * 2).<br />
<br />
Load the dm-crypt and the optimized AES module:<br />
# modprobe dm-crypt<br />
# modprobe aes-i586<br />
<br />
'''Note:''' x86_64 users can also try the "aes-x86_64" optimized module instead of "aes-i586".<br />
<br />
=== Mapping partitions ===<br />
==== Passphrase ====<br />
Use this to create a password to unlock your encrypted partions with:<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda3<br />
Enter passphrase: mypassword<br />
Verify passphrase: mypassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda4<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda5<br />
Enter passphrase: myotherpassword<br />
Verify passphrase: myotherpassword<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup luksOpen /dev/sda3 root<br />
Enter any LUKS passphrase: mypassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda4 home<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup luksOpen /dev/sda5 tmp<br />
Enter any LUKS passphrase: myotherpassword<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Keyfile ====<br />
You can also do the following to create a keyfile instead of a passphrase. Of course you could put the keyfile everywhere you like, but most probably you'll want to put it onto an USB stick to unlock your encrypted partions.<br />
See the [[System Encryption with LUKS for dm-crypt#Storing the key externally (USB stick)|corresponding section]] below for further details on this.<br />
<br />
To store the keyfile on an USB stick mount it and change to the directory<br />
# mkdir /mnt/usbstick<br />
# mount -t vfat /dev/sdb1 /mnt/usbstick<br />
# cd /mnt/usbstick<br />
<br />
As said above the keyfile can be of any content and size.<br />
We'll generate a random keyfile of 2048 bytes onto the USB stick:<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
Create your new LUKS encrypted partitions:<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda3 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda4 /mnt/usbstick/mykeyfile<br />
# cryptsetup -c aes-xts-plain -s 512 -v luksFormat /dev/sda5 /mnt/usbstick/mykeyfile<br />
<br />
Note: if you've already created the LUKS partitions e.g. with passphrase authentication, you can add a keyfile as further authentication method by using<br />
# cryptsetup luksAddKey /dev/sdaX /mnt/usbstick/mykeyfile # replace X by 3,4,5<br />
<br />
Then open the newly created LUKS partitions:<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda3 root<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda4 home<br />
key slot 0 unlocked.<br />
Command successful.<br />
# cryptsetup -d /mnt/usbstick/mykeyfile luksOpen /dev/sda5 tmp<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
<br />
==== Explanation ====<br />
Now you should have a device called <tt>/dev/mapper/root</tt>, another one called <tt>/dev/mapper/home</tt> and another one called <tt>/dev/mapper/tmp</tt>. These are block devices like any other, but with a neat twist: whenever you write to them, the data is actually written to <tt>/dev/sda3</tt>, <tt>/dev/sda4</tt> or <tt>/dev/sda5</tt> respectively, but it is encrypted first! The only way to access the data on this encrypted partition is to re-create that <tt>/dev/mapper/root</tt>, <tt>/dev/mapper/home</tt> etc. device with cryptsetup each time you boot. With LUKS, you can use <tt>cryptsetup luksAddKey /dev/sda3</tt> to add a new password or <tt>cryptsetup luksDelKey /dev/sda3</tt> to revoke a password. Type <tt>cryptsetup -?</tt> or <tt>man cryptsetup</tt> (once you've booted your new Arch installation) for more info.<br />
<br />
'''Note:''' With LUKS, if you enter the wrong password, it will reject it. You don't have to worry about it possibly destroying your data.<br />
<br />
'''Note:''' You might also want to replace /var/tmp/ with a symbolic link to /tmp.<br />
<br />
'''Note:''' If you've decided to go for option two for encrypted swap (see Encrypted Swap below), you should set up <tt>/dev/mapper/swap</tt> in a similar way as you've just set up <tt>/dev/mapper/home</tt>. See Encrypted Swap below for details.<br />
<br />
<br />
=== Installing the system ===<br />
Now that <tt>/dev/mapper/root</tt> and <tt>/dev/mapper/home</tt> are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
'''Note:''' Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections these are marked below.<br />
<br />
==== Prepare hard drive ====<br />
Skip the Partitioning and Auto-Prepare business and go straight to manually configuration.<br />
Instead of choosing the hardware devices (/dev/sdaX) directly you have to select the mapper devices created above:<br />
Choose <tt>/dev/mapper/root</tt> for your root and <tt>/dev/mapper/home</tt> as home partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the home partition. Make sure you mount <tt>/dev/sda1</tt> as the /boot partition or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual, the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
'''Note: ''encrypt'' hook is only needed if your root partition is a ''LUKS'' partition (or for a LUKS partition that needs to be mounted ''before'' root). If it is a ''swap'' or ''any other partition'', all is taken care by ''rc.sysinit'' and ''/etc/crypttab'' file'''<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being <tt>/etc/mkinitcpio.conf</tt>. For detailed info on mkinitcpio (and its configuration) refer to [[Mkinitcpio]].You have to make sure that your <tt>HOOKS</tt> looks somehow like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the <tt>encrypt</tt> hook comes ''before'' the <tt>filesystems</tt> one. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add in usb before encrypt; not sure if they're run in the order they appear in mkinitcpio.conf or not. <br />
If you need support for foreign keymaps for your encryption password you have to specify the hook 'keyboard' as well. I suggest to put this in <tt>mkinitcpio.conf</tt> right before 'encrypt'.<br />
<br />
If you have USB keyboard you need the "usbinput" hook in mkinitcpio.conf. Without it, no USB keyboard will work in early userspace.<br />
<br />
=== Install Bootloader ===<br />
'''GRUB:''' You have to make some small changes to the entries generated by the installer by replacing <tt>/dev/mapper/root</tt> with <tt>/dev/sda3</tt>. The corrected config looks like this:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
For kernel >= 2.6.30:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 cryptdevice=/dev/sda3:root root=/dev/mapper/root ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' On Lilo, edit the Arch Linux section on /etc/lilo.conf and include a line for append option, over the initrd, with the "root=/dev/sda3" param. The append section make the same kernel line on grub. Also, you can ommit the root option, over the image option. The section look like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz26<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /kernel26.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
'''Note''' if you want to use a USB stick with a keyfile you have to append the ''cryptkey'' option. See the corresponding section below.<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the <tt>/etc/crypttab</tt> file so you don't have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. /home, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
Add the following line for the <tt>/home</tt> partition<br />
home /dev/sda4 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Keyfile|above]].<br />
Then add the following information to the <tt>/etc/crypttab</tt> file for automounting:<br />
home /dev/sda4 /path/of/your/keyfile<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for any LUKS password. Type it in and everything should boot.<br />
Once you've logged in, have a look at your mounted partitions by typing <tt>mount</tt>. You should have <tt>/dev/mapper/root</tt> mounted at <tt>/</tt> and, if you set up a separate encrypted home partition, <tt>/dev/mapper/home</tt> mounted at <tt>/home</tt>. If you set up encrypted swap, <tt>swapon -s</tt> should have <tt>/dev/mapper/swap</tt> listed as your swap partition.<br />
<br />
'''Note:''' eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it isn't, simply enter your password and press return.<br />
<br />
<br />
== Encrypting swap partition ==<br />
Sensitive data stored in memory may be written to swap at any time. If you've gone to the trouble of encrypting your root and home partitions, you should encrypt your swap as well. There are two options here: random encryption on each boot (better security), or the same encryption each time. We won't cover the second option here, as it is pretty much identical to how you set up the /home partition above. Just replace all references to home with swap, and sda4 with sda2.<br />
<br />
Arch Linux provides a convenient way for the first option, which uses dm-crypt directly without LUKS. If you're still in the archsetup process, just switch to a different virtual console (ALT+F2). If you've exited already, the new root will have been unmounted. Use <tt>mount /dev/mapper/root /mnt</tt> to mount it again.<br />
<br />
Now add an entry to the cryptsetup file:<br />
# echo swap /dev/sda2 SWAP "-c aes-xts-plain -h whirlpool -s 512" >> /mnt/etc/crypttab<br />
<br />
'''Note:''' Recommended hash algorithms are "whirlpool" (patent free), "sha256", "sha384" or "sha512". Default is "ripemd160" (not recommended).<br />
<br />
''[why is it not recommended? only RIPEMD (128bit) was hacked RIPEMD-160 is still safe[https://online.tu-graz.ac.at/tug_online/voe_main2.getvolltext?pDocumentNr=83310], isn't it? I heard wirlpool is at least twice as slow. ]''<br />
<br />
'''Note:''' Please take extra care to put the right partition here. The startup script won't ask before overwriting the provided device, destroying '''all''' data on it, unless it has a LUKS header, then it simply won't work. If you have been following these instructions closely, then in the section "Mapping Partitions" above you put a LUKS header on your swap partition. Erase it with something like the command below, replacing /dev/sda2 with the appropriate swap device:<br />
# dd if=/dev/zero of=/dev/sda2<br />
<br />
From now on, each time you boot, the partition will be encrypted automatically with a random key, and will then be formated with mkswap.<br />
<br />
Now all you have to do is adjust the corresponding entry in /etc/fstab:<br />
/dev/mapper/swap swap swap defaults 0 0<br />
<br />
And you're done! Carry on with installation or, if you've already finished, <tt>umount /mnt</tt>.<br />
<br />
== Encrypted swap with suspend-to-disk support ==<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a LUKS swap partition with a persistent key, which can be stored on the disk or input manually at startup. Because the resume takes place before the crypttab can be used, it is required to create a hook in mkinitcpio.conf to open the swap LUKS device before resuming.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it, first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above. Omit steps 1 and 2 if you don't intend to use a saved key file.<br><br><br />
1. Generate a random key file <b>in a safe place</b> - encrypted root partition like my examples or secure USB stick.<br />
# dd if=/dev/urandom bs=1 count=512 of=/etc/keys/swap.key<br />
2. For security reasons, no user except root should have read-access to this file.<br />
# chown root:root /etc/keys/swap.key<br />
# chmod go-rwx /etc/keys/swap.key<br />
3. Format the partition you want to use as swap with '''cryptsetup''', using the key stored previously. For performance reasons, you might want to use different ciphers with different key sizes. A benchmark can be found [http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio here].<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device> /etc/keys/swap.key<br />
* as stated in discussion: the -h parameter to specify hash function is (in this case) ignored, also the default hash - ripemd - is not recommended (citation needed). use aes-xts-plain:whirlpool , or aes-xts-sha256 instead. <br />
* check result with # cryptsetup luksDump /dev/<device>(sda3)<br />
<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup -c aes-xts-plain -s 256 -v luksFormat /dev/<device><br />
4. Open the partition in ''/dev/mapper'' using the key:<br />
# cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
If you don't use a saved key file, use this command:<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
5. Create a swap filesystem inside the mapped partition:<br />
# mkswap /dev/mapper/swapDevice<br />
Now you should have a LUKS swap partition which uses the key file stored in ''/etc/keys/swap.key'' or asks for the passphrase before mounting, depending on your choice. Make sure you remove any line in ''/etc/crypttab'' which uses this device. Now you have to create a hook to open the swap at boot time.<br><br><br />
6. Create a file ''/lib/initcpio/hooks/openswap'' containing the open command:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice -d /etc/keys/swap.key<br />
}<br />
If you don't use a saved key file, ''openswap'' should instead contain:<br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
7. Then create and edit the hook setup file ''/lib/initcpio/install/openswap'' as:<br />
# vim: set ft=sh:<br />
<br />
install ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
add_file "/etc/keys/swap.key"<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
If you don't use a saved key file, remove unnecessary line '''add_file "/etc/keys/swap.key"''' from the file above.<br><br><br />
8. Add the hook ''openswap'' in the HOOKS array in ''/etc/mkinitcpio.conf'', before ''filesystem'', but '''after''' ''encrypt'' which is mandatory as well.<br><br><br />
9. Regenerate the boot image:<br />
# mkinitcpio -p kernel26<br />
10. Add the mapped partition to ''/etc/fstab'':<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
11. Set-up your system to resume from ''/dev/mapper/swapDevice''. For example, if you use GRUB with kernel hibernation support, add "resume=/dev/mapper/swapDevice" to the kernel line in ''/boot/grub/menu.lst''. A line with encrypted root and swap partitions can look like this:<br />
kernel /vmlinuz26 cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
At boot time, the ''openswap'' hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they stand '''after''' ''openswap'' in the HOOKS array. Please note that because of initrd opening swap there is no entry for swapDevice in /etc/crypttab needed in this case.<br />
<br />
== Storing the key externally (USB stick) ==<br />
=== Preparation for permanent device names ===<br />
For reading the file from an USB stick it's important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. <tt>/dev/sdb1</tt> is somewhat arbitrary and depends on how many storage devices are attached and in what order etc.<br />
So in order to assure that the ''encrypt'' HOOK in the initcpio finds your keyfile you have to use a permanent device name. <br />
<br />
==== Quick method ====<br />
A quick method (as opposed to setting up a udev rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run <br />
# ls -l /dev/disk/by-label/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1<br />
or<br />
# ls -l /dev/disk/by-uuid/<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1<br />
<br />
In this case I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in /dev/disk/by-label/Keys, or If I had wanted to use the UUID I would find /dev/disk/by-uuid/4803-8A7B. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
'''Note:''' If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions (<tt>sdb1</tt>,<tt>sdb2</tt>,...) but not to the usb device (<tt>sdb</tt>) itself.<br />
Create a UDEV rule instead as described in the following section.<br />
<br />
==== Using UDEV ====<br />
Optionally you may choose to set up your stick with an udev rule. There's some documentation in the Arch wiki about that already, if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here's quickly how it goes.<br />
<br />
Get the serial number from your USB stick:<br />
lsusb -v | grep -A 5 Vendor<br />
Create a udev-rule for it:<br />
echo 'KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"' > /etc/udev/rules.d/8-usbstick.rules<br />
Replace $SYMLINK and $SERIAL with their respective values. %n will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute, if you have a custom rule of your own, you can put it in as well (e.g. using the vendor name). <br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of dev:<br />
ls /dev<br />
It should show your device with your desired name. <br />
<br />
=== Generating the keyfile ===<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. <tt>/media/sdb1</tt><br />
<br />
The keyfile can be of arbitrary content and size. We'll generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (due to journaling filesystems etc this is also not 100% secure)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
=== Storing the keyfile ===<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your /etc/mkinitcpio.conf, one for the stick's file system and one for the codepage. Further if you created a udev-rule you should tell mkinitcpio about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it's assumed, that you use a FAT formated stick. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
In addition insert the ''usb'' hook somewhere before the ''encrypt'' hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
Generate a new image (maybe you should take a copy of your old kernel26.img before):<br />
mkinitcpio -g /boot/kernel26.img<br />
<br />
==== Storing the key as plain (visible) file ====<br />
Be sure to choose a plain name for your key - a bit of 'security through obscurity' is always nice ;-). Avoid using dots (hidden files) and similar characters - the encrypt hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your menu.lst (grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes <tt>/dev/usbstick</tt> is the FAT partition of your choice. Replace it by <tt>/dev/disk/by-...</tt> or whatever your device is.<br />
<br />
That's all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We'll 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 - <b>it can cause data loss and damage your partitions or MBR on the stick!</b><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 (actually, it depends on the type of the file system, so don't rely on this too much), 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 />
<i>Optional</i><br />
If you don't know if you've got enough free space before the first partition you can do<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 />
xxd 64sectors | less # alternative hex viewer<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 as noted above.<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 menu.lst (Grub), it should look something like this:<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:2048:2048<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<br />
kernel /vmlinuz26 root=/dev/hda3 ro vga=791 cryptkey=/dev/usbstick:8192:2048<br />
That's all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
== Backup the cryptheader ==<br />
When the header of your crypted partition was destroyed, you will not be able to decrypt your data.<br />
So creating a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT to backup the cryptheader, even so it's a single point failure!<br />
In short, the problem is, that LUKS isn't aware of the duplicated cryptheader, which contains the masterkey which is used to encrypt all files on your partition. Of course this masterkey is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the masterkey and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq] for further details on this.<br />
<br />
=== Backup ===<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
'''Note:''' you can also backup the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]<br />
<br />
=== Preparation and mapping ===<br />
So, let's start by creating an encrypted container!<br />
<br />
dd if=/dev/zero of=/bigsecret bs=1M count=10 # you can also use if=/dev/urandom, if you're really paranoid<br />
<br />
This will create the file 'bigsecret' with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node /dev/loop0, so that we can mount/use our container. (Note: if it gives you the error "/dev/loop0: No such file or directory", you need to first load the kernel module with <tt>modprobe loop</tt>)<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file. (Note: if you get an error like "Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors", then run <tt>modprobe dm-mod</tt>)<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the devicefile /dev/mapper/secret.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
Pretty easy, huh?<br />
<br />
=== Encrypt using a key-file ===<br />
Let's first generate a 2048 Byte random keyfile :<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the luks device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device /dev/mapper/container with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise to encrypt your keyfile using your private GPG key and storing an offsite secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to create a second file with the size of the data we want to add:<br />
dd if=/dev/zero of=zeros bs=1M count=1024<br />
<br />
You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers.<br />
Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!<br />
cat zeros >> /bigsecret<br />
Now we have to map the container to the loopdevice:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption together with LVM. We are not going to cover the process of setting up LVM here as there is already a guide for that ([[Installing_with_Software_RAID_or_LVM]]).<br />
<br />
The best method and easier method to follow for a laptop is to set up the LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
To use encryption on top of LVM, you have to first setup your lvm volumes and then use them as base for the encrypted partitions. That means in short that you have to setup lvm at first. Then follow this guide, but replace all occurrences of /dev/sdXy in the guide with its lvm counterpart. (eg: /dev/sda4 -> /dev/<volume group name>/home).<br />
<br />
Don't forget to add the "lvm2" hook in /etc/mkinitcpio.conf '''before''' the "encrypt" hook. And you will have to change USELVM in /etc/rc.conf to yes.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08 LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for LVM on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM, see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partion which can later be split up into multiple logic volumes by LVM.<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
In <tt>/etc/rc.conf</tt> set USELVM="yes"<br />
In <tt>/etc/mkinitcpio.conf</tt> add ''lvm2'' '''before''' ''encrypt'' in the HOOKS variable.<br />
<br />
That's it for the LVM&dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.<br><br />
The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. not on any internal HD partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change fstab order (at least).<br><br />
Of course, if the cryptsetup package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking rc.sysinit or similar files. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
<br />
If you want to do this on a software RAID partition, there's one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices aren't brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like <br />
kernel /boot/vmlinuz26 md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID array you will notice the similarities with that setup ;-). Grub can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz26 root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM&dm-crypt manually (short version) ===<br />
==== Notes ====<br />
If you're enough smart enough for this, you'll be smart enough to ignore/replace LVM-specific things if you don't want to use LVM.<br />
<br />
==== Partitioning scheme ====<br />
/dev/sda1 -> /boot<br />
/dev/sda2 -> LVM<br />
==== The commands =====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
==== Install Arch Linux ====<br />
/arch/setup<br />
==== Configuration ====<br />
===== /etc/rc.conf =====<br />
Change ''USELVM="no"'' to ''USELVM="yes"''.<br />
===== /etc/mkinitcpio.conf =====<br />
Put ''lvm2 encrypt'' before ''filesystems.<br />
===== /boot/grub/menu.lst =====<br />
Change ''root=/dev/hda3'' to ''root=/dev/lvm/root''.<br><br />
For kernel >= 2.6.30, you should change ''root=/dev/hda3'' to:<br />
''cryptdevice=/dev/lvm/root:root root=/dev/mapper/root''<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After reboot ====<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on lvm on luks ===<br />
Make sure your kernel commandline looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
for example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root</div>Rad3k