https://wiki.archlinux.org/api.php?action=feedcontributions&user=Carlduff&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:01:11ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=427376User talk:Carlduff2016-03-23T13:12:29Z<p>Carlduff: /* vbox pacstrap */</p>
<hr />
<div>== <s>vbox pacstrap </s> ==<br />
<br />
Hi, <br />
I [https://wiki.archlinux.org/index.php?title=VirtualBox&diff=427155&oldid=427154 reworded] the warning you added a little. Whatever the reason for it may be (perhaps all the dependencies of the vbox guest packages), Alad mentions that it is in the wrong place anyway .. to which I agree. Why would you use ''pacstrap'' '''inside''' a vbox guest machine? Perhaps easier, instead of the warning, to just crosslink to [[install]] for the first two packages in [[VirtualBox#Install_the_Guest_Additions]]? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:19, 22 March 2016 (UTC)<br />
:Well, although the beginners' guide recommends booting into a basic base and dealing with everything else post-installation (including this sort of thing), it is possible to pretty much get everything installed and running in one go. That way you boot into something that won't require much more than theming your chosen DE/WM. As for the edit, I don't mind what happens to it. Just struck me as something potentially useful for some users. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 16:27, 22 March 2016 (UTC)<br />
<br />
::Yes, ok. The thing is the warning will probably confuse more readers in that section because of said sudden pacstrap reference, than help the others who get the idea of why it is in the instructions at that place. The rest of that subsection is not performable anyway without booting the guest first to my understanding. Therefore expanding on it in that section is distracting. I have moved it to troubleshooting: [https://wiki.archlinux.org/index.php?title=VirtualBox&type=revision&diff=427223&oldid=427158] so the info is not lost (CTRL-F pacstrap:). Cheers. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:04, 22 March 2016 (UTC)<br />
::: {{ic|arch-chroot <mountpoint> /bin/bash -c "<command>"}} allows full configuration without booting into the installed system ;-) [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 13:12, 23 March 2016 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=427191User talk:Carlduff2016-03-22T16:27:17Z<p>Carlduff: Response</p>
<hr />
<div>== vbox pacstrap ==<br />
<br />
Hi, <br />
I [https://wiki.archlinux.org/index.php?title=VirtualBox&diff=427155&oldid=427154 reworded] the warning you added a little. Whatever the reason for it may be (perhaps all the dependencies of the vbox guest packages), Alad mentions that it is in the wrong place anyway .. to which I agree. Why would you use ''pacstrap'' '''inside''' a vbox guest machine? Perhaps easier, instead of the warning, to just crosslink to [[install]] for the first two packages in [[VirtualBox#Install_the_Guest_Additions]]? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:19, 22 March 2016 (UTC)<br />
:Well, although the beginners' guide recommends booting into a basic base and dealing with everything else post-installation (including this sort of thing), it is possible to pretty much get everything installed and running in one go. That way you boot into something that won't require much more than theming your chosen DE/WM. As for the edit, I don't mind what happens to it. Just struck me as something potentially useful for some users. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 16:27, 22 March 2016 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=VirtualBox&diff=427067VirtualBox2016-03-22T10:30:34Z<p>Carlduff: /* Install the Guest Additions */ Note to Trilby and WormZY: try not to be so defensive and shit on people when they try to warn about this</p>
<hr />
<div>[[Category:Emulators]]<br />
[[Category:Hypervisors]]<br />
[[cs:VirtualBox]]<br />
[[de:VirtualBox]]<br />
[[el:VirtualBox]]<br />
[[es:VirtualBox]]<br />
[[fr:VirtualBox]]<br />
[[hu:VirtualBox]]<br />
[[it:VirtualBox]]<br />
[[ja:VirtualBox]]<br />
[[pt:VirtualBox]]<br />
[[ru:VirtualBox]]<br />
[[zh-CN:VirtualBox]]<br />
{{Related articles start}}<br />
{{Related|:Category:Hypervisors}}<br />
{{Related|PhpVirtualBox}}<br />
{{Related|Moving an existing install into (or out of) a virtual machine}}<br />
{{Related articles end}}<br />
<br />
[https://www.virtualbox.org VirtualBox] is a [[Wikipedia:Hypervisor|hypervisor]] used to run operating systems in a special environment, called a virtual machine, on top of the existing operating system. VirtualBox is in constant development and new features are implemented continuously. It comes with a [[Qt]] GUI interface, as well as headless and [[Wikipedia:Simple DirectMedia Layer|SDL]] command-line tools for managing and running virtual machines.<br />
<br />
In order to integrate functions of the host system to the guests, including shared folders and clipboard, video acceleration and a seamless window integration mode, ''guest additions'' are provided for some guest operating systems.<br />
<br />
== Installation steps for Arch Linux hosts ==<br />
<br />
In order to launch VirtualBox virtual machines on your Arch Linux box, follow these installation steps.<br />
<br />
=== Install the core packages ===<br />
<br />
[[install]] the {{Pkg|virtualbox}} package. {{Pkg|virtualbox-host-dkms}} will also be installed as a required dependency. To compile the virtualbox modules provided by {{ic|virtualbox-host-dkms}}, it will also be necessary to install the appropriate headers package(s) for your installed kernel(s)[https://lists.archlinux.org/pipermail/arch-dev-public/2016-March/027808.html]:<br />
<br />
* {{Pkg|linux}} kernel: {{Pkg|linux-headers}}<br />
* {{Pkg|linux-lts}} kernel: {{Pkg|linux-lts-headers}}<br />
* {{Pkg|linux-zen}} kernel: {{Pkg|linux-zen-headers}}<br />
* {{Pkg|linux-grsec}} kernel: {{Pkg|linux-grsec-headers}}<br />
<br />
You can also install the {{Pkg|qt4}} optional dependency in order to use the graphical interface which is based on [[Qt]]. This is not required if you intend to use VirtualBox in command-line only. [[#Use the right front-end|See below to learn the differences]].<br />
<br />
=== Install the VirtualBox kernel modules ===<br />
<br />
Next, to fully virtualize your guest installation, VirtualBox provides the following [[kernel modules]]: {{ic|vboxdrv}}, {{ic|vboxnetadp}}, {{ic|vboxnetflt}}, and {{ic|vboxpci}}. These must be added to your host kernel.<br />
<br />
The binary compatibility of kernel modules depends on the API of the kernel against which they have been compiled. The problem with the Linux kernel is that these interfaces might not be the same from one kernel version to another. In order to avoid compatibility problems and subtle bugs, each time the Linux kernel is upgraded, it is advised to recompile the kernel modules against the Linux kernel version that has just been installed. This is what Arch Linux packagers actually do with the VirtualBox kernel modules packages: each time a new Arch Linux kernel is released, the Virtualbox modules are upgraded accordingly.<br />
<br />
==== Hosts running a custom kernel ====<br />
<br />
If you use or intend to use a self-compiled kernel from sources, you have to know that VirtualBox does not require any virtualization modules (e.g. virtuo, kvm,...). The VirtualBox kernel modules provide all the necessary for VirtualBox to work properly. You can thus disable in your kernel ''.config'' file these virtualization modules if you do not use other hypervisors like Xen, KVM or QEMU.<br />
<br />
===== DKMS Install =====<br />
<br />
{{Tip|[[DKMS]] can automatically generate the modules of the current running kernel by running the following command:<br />
{{bc|<nowiki># dkms autoinstall</nowiki>}}<br />
}}<br />
<br />
As the {{Pkg|virtualbox-host-dkms}} package requires compilation, make sure you have the kernel headers corresponding to your custom kernel version to prevent this error from happening: {{ic|Your kernel headers for kernel ''your custom kernel version'' cannot be found at /usr/lib/modules/''your custom kernel version''/build or /usr/lib/modules/''your custom kernel version''/source}}<br />
<br />
Once {{Pkg|virtualbox-host-dkms}} is installed, simply generate the kernel modules for the custom kernel by running the following command:<br />
# dkms install vboxhost/''virtualbox-host-source version'' -k ''your custom kernel version''/''your architecture''<br />
<br />
{{Tip|Use this all-in-one command instead, if you do not want to adapt the above command:<br />
{{bc|<nowiki># dkms install vboxhost/$(pacman -Q virtualbox|awk '{print $2}'|sed 's/\-.\+//') -k $(uname -rm|sed 's/\ /\//')</nowiki>}}<br />
}}<br />
<br />
To automatically recompile the VirtualBox kernel modules when their sources get upgraded (i.e. when the {{Pkg|virtualbox-host-dkms}} package has been upgraded), enable the {{ic|dkms}} service.<br />
<br />
=== Load the VirtualBox kernel modules ===<br />
<br />
Since version 5.0.16, {{Pkg|virtualbox-host-dkms}} and {{Pkg|virtualbox-guest-dkms}} use '''systemd-modules-load''' service to load their modules at boot time.<br />
<br />
{{Note|If you don't want the VirtualBox modules to be loaded at boot time, you have to use the classic systemd logic to mask modules by putting an empty files (or symlink to {{ic|/dev/null}}) in {{ic|/etc/modules-load.d}}}}<br />
<br />
Among the [[kernel modules]] VirtualBox uses, there is a mandatory module named {{ic|vboxdrv}}, which must be loaded before any virtual machines can run.<br />
<br />
To load the module manually:<br />
# modprobe vboxdrv<br />
<br />
The following modules are optional but are recommended if you do not want to be bothered in some advanced configurations (precised here after): {{ic|vboxnetadp}}, {{ic|vboxnetflt}} and {{ic|vboxpci}}.<br />
<br />
* {{ic|vboxnetadp}} and {{ic|vboxnetflt}} are both needed when you intend to use the [https://www.virtualbox.org/manual/ch06.html#network_bridged bridged] or [https://www.virtualbox.org/manual/ch06.html#network_hostonly host-only networking] feature. More precisely, {{ic|vboxnetadp}} is needed to create the host interface in the VirtualBox global preferences, and {{ic|vboxnetflt}} is needed to launch a virtual machine using that network interface.<br />
<br />
* {{ic|vboxpci}} is needed when your virtual machine needs to pass through a PCI device on your host.<br />
<br />
{{Note|If the VirtualBox kernel modules were loaded in the kernel while you updated the modules, you need to reload them manually to use the new updated version. To do it, run {{ic|vboxreload}} as root.}}<br />
<br />
Finally, if you use the aforementioned "Host-only" or "bridge networking" feature, make sure {{pkg|net-tools}} is installed. VirtualBox actually uses {{ic|ifconfig}} and {{ic|route}} to assign the IP and route to the host interface configured with {{ic|VBoxManage hostonlyif}} or via the GUI in ''Settings > Network > Host-only Networks > Edit host-only network (space) > Adapter''.<br />
<br />
=== Add usernames to the vboxusers group ===<br />
<br />
To use the USB ports of your host machine in your virtual machines, add to the {{ic|vboxusers}} [[group]] the usernames that will be authorized to use this feature. The new group does not automatically apply to existing sessions; the user has to log out and log in again, or start a new environment with the {{ic|newgrp}} command or with {{ic|sudo -u $USER -s}}. To add the current user to the {{ic|vboxusers}} group, type:<br />
# gpasswd -a $USER vboxusers<br />
<br />
=== Guest additions disc ===<br />
<br />
It is also recommended to install the {{Pkg|virtualbox-guest-iso}} package on the host running VirtualBox. This package will act as a disc image that can be used to install the guest additions onto guest systems other than Arch Linux. The ''.iso'' file will be located at {{ic|/usr/lib/virtualbox/additions/VBoxGuestAdditions.iso}}, and may have to be mounted manually inside the virtual machine. Once mounted, you can run the guest additions installer inside the guest.<br />
<br />
=== Extension pack ===<br />
<br />
Since VirtualBox 4.0, non-GPL components have been split from the rest of the application. Despite being released under a non-free license and '''being only available for personal use''', you might be interested in installing the Oracle Extension Pack which provides [https://www.virtualbox.org/manual/ch01.html#intro-installing additional features]. To avoid manual manipulation, the {{aur|virtualbox-ext-oracle}} package is available, and a prebuilt version can be found in the [[Unofficial user repositories#seblu|seblu]] repository.<br />
<br />
If you prefer to use the traditional and manual way: download the extension manually and install it via the GUI (''File > Preferences > Extensions'') or via {{ic|VBoxManage extpack install <.vbox-extpack>}}, make sure you have a toolkit (like [[Polkit]], gksu, etc.) to grant privileged access to VirtualBox. The installation of this extension [https://www.virtualbox.org/ticket/8473 requires root access].<br />
<br />
=== Use the right front-end ===<br />
<br />
Now, you are ready to use VirtualBox. Congratulations!<br />
<br />
Multiple front-ends are available to you of which two are available by default:<br />
* If you want to use VirtualBox in command-line only (only launch and change settings of existing virtual machines), you can use the {{ic|VBoxSDL}} command. VBoxSDL does only provide a simple window that contains only the ''pure'' virtual machine, without menus or other controls.<br />
* If you want to use VirtualBox in command-line without any GUI running (e.g. on a server) to create, launch and configure virtual machines, use the {{ic|VBoxHeadless}} which produces no visible output on the host at all, but instead only delivers VRDP data (note: VRDP is only enabled if the extension pack is installed).<br />
<br />
If you installed the {{Pkg|qt4}} optional dependency, you can run {{ic|VirtualBox}} and have a nice-looking GUI interface with menus usable via the mouse.<br />
<br />
Finally, you can use [[PhpVirtualBox]] to administrate your virtual machines via a web interface.<br />
<br />
Refer to the [https://www.virtualbox.org/manual VirtualBox manual] to learn how to create virtual machines.<br />
<br />
{{Warning|If you intend to store virtual disk images on a [[Btrfs]] file system, before creating any images, you should consider disabling [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] for the destination directory of these images.}}<br />
<br />
== Installation steps for Arch Linux guests ==<br />
<br />
Boot the Arch installation media through one of the virtual machine's virtual drives. Then, complete the installation of a basic Arch system as explained in the [[Beginners' guide]] or the [[Installation guide]].<br />
<br />
==== Installation in EFI mode ====<br />
<br />
If you want to install Arch Linux in EFI mode inside VirtualBox, in the settings of the virtual machine, choose ''System'' item from the panel on the left and ''Motherboard'' tab from the right panel, and check the checkbox ''Enable EFI (special OSes only)''. After selecting the kernel from the Arch Linux installation media's menu, the media will hang for a minute or two and will continue to boot the kernel normally afterwards. Be patient.<br />
<br />
Once the system and the boot loader are installed, VirtualBox will first attempt to run {{ic|/EFI/BOOT/BOOTX64.EFI}} from the ESP. If that first option fails, VirtualBox will then try the EFI shell script {{ic|startup.nsh}} from the root of the ESP. This means that in order to boot the system you have the following options:<br />
<br />
* [[Unified Extensible Firmware Interface#UEFI Shell|Launch the bootloader manually]] from the EFI shell every time;<br />
* Move the bootloader to the default {{ic|/EFI/BOOT/BOOTX64.EFI}} path;<br />
* Create the {{ic|startup.nsh}} script at the ESP root containing the path to the boot loader application, e.g. {{ic|\EFI\grub\grubx64.efi}}.<br />
<br />
Do not bother with the VirtualBox Boot Manager (accessible with {{ic|F2}} at boot): EFI entries added to it manually at boot or with {{Pkg|efibootmgr}} will persist after a reboot [https://www.virtualbox.org/ticket/11177 but are lost when the VM is shut down].<br />
<br />
See also [https://bbs.archlinux.org/viewtopic.php?id=158003 UEFI Virtualbox installation boot problems].<br />
<br />
=== Install the Guest Additions ===<br />
{{Warning| If using {{ic|pacstrap}} to install guest additions, you will need to unmount {{ic|/mnt/dev}} before using {{ic|pacstrap}} again: {{ic|umount -l /mnt/dev}}. A failure to do this will render {{ic|pacstrap}} unusable.}}<br />
<br />
VirtualBox [https://www.virtualbox.org/manual/ch04.html Guest Additions] provides drivers and applications that optimize the guest operating system including improved image resolution and better control of the mouse. Within the installed guest system, if using a graphical environment, install {{Pkg|virtualbox-guest-utils}}. Otherwise install {{Pkg|virtualbox-guest-utils-nox}} for VirtualBox Guest utilities without X support.<br />
<br />
Both packages will install {{Pkg|virtualbox-guest-dkms}} as a dependency. To compile the virtualbox modules provided by {{ic|virtualbox-guest-dkms}}, it will also be necessary to install the appropriate headers package(s) for your installed kernel(s)[https://lists.archlinux.org/pipermail/arch-dev-public/2016-March/027808.html]:<br />
<br />
* {{Pkg|linux}} kernel: {{Pkg|linux-headers}}<br />
* {{Pkg|linux-lts}} kernel: {{Pkg|linux-lts-headers}}<br />
* {{Pkg|linux-zen}} kernel: {{Pkg|linux-zen-headers}}<br />
* {{Pkg|linux-grsec}} kernel: {{Pkg|linux-grsec-headers}}<br />
<br />
{{Note|<nowiki></nowiki><br />
* You can alternatively install the Guest Additions with the ISO from the {{Pkg|virtualbox-guest-iso}} package, provided you installed this on the host system. To do this, go to the device menu click Insert Guest Additions CD Image.<br />
* To recompile the vbox kernel modules, run {{ic|rcvboxdrv}} as root.<br />
}}<br />
<br />
=== Load the Virtualbox kernel modules ===<br />
<br />
To load the modules automatically, [[enable]] the {{ic|vboxservice}} service which loads the modules and synchronizes the guest's system time with the host.<br />
<br />
To load the modules manually, type:<br />
# modprobe -a vboxguest vboxsf vboxvideo<br />
<br />
To load the VirtualBox module at boot time, refer to [[Kernel modules#Automatic module handling]] and create a {{ic|*.conf}} file (e.g. {{ic|virtualbox.conf}}) in {{ic|/etc/modules-load.d/}} with these lines:<br />
{{hc|/etc/modules-load.d/virtualbox.conf|<br />
vboxguest<br />
vboxsf<br />
vboxvideo}}<br />
<br />
Note that depending on your choice of paravirtualization in VirtualBox, you may need to [[Systemd#Editing provided units|edit the unit]] with the following property to get it to load: {{ic|1=<br />
ConditionVirtualization=''paravirtualization''<br />
}}<br />
<br />
Run {{ic|systemd-detect-virt}} in the console to determine your paravirtualization.<br />
<br />
=== Launch the VirtualBox guest services ===<br />
<br />
After the rather big installation step dealing with VirtualBox kernel modules, now you need to start the guest services. The guest services are actually just a binary executable called {{ic|VBoxClient}} which will interact with your X Window System. {{ic|VBoxClient}} manages the following features:<br />
* shared clipboard and drag and drop between the host and the guest;<br />
* seamless window mode;<br />
* the guest display is automatically resized according to the size of the guest window;<br />
* checking the VirtualBox host version<br />
<br />
All of these features can be enabled independently with their dedicated flags:<br />
$ VBoxClient --clipboard --draganddrop --seamless --display --checkhostversion<br />
<br />
As a shortcut, the {{ic|VBoxClient-all}} bash script enables all of these features. You should set {{ic|VBoxClient}} to be automatically loaded as your [[desktop environment]] or [[window manager]] starts. In practice,<br />
* if you are using a [[desktop environment]], you just need to check a box or add the {{ic|/usr/sbin/VBoxClient-all}} to the autostart section in your [[desktop environment]] settings (the DE will typically set a flag to a ''.desktop'' file in {{ic|~/.config/autostart}}, see [[Autostart#Desktop entries|the Autostart section]] for more details);<br />
* if you do not have any [[desktop environment]], add the following line to the top of {{ic|~/.xinitrc}} above any {{ic|exec}} options. See [[Xinitrc]] for detail.<br />
{{hc|~/.xinitrc|<br />
/usr/bin/VBoxClient-all}}<br />
<br />
VirtualBox can also synchronize the time between the host and the guest. To do this, run {{ic|VBoxService}} as root. To set this to run automatically on boot, simply [[enable]] the {{ic|vboxservice}} service.<br />
<br />
Now, you should have a working Arch Linux guest. Note that features like clipboard sharing are disabled by default in VirtualBox, and you will need to turn them on in the per-VM settings if you actually want to use them (e.g. ''Settings > General > Advanced > Shared Clipboard'').<br />
<br />
=== Hardware acceleration ===<br />
<br />
Hardware acceleration can be activated from the VirtualBox options on the host computer. Note that when the gdm display manager 3.16+ is known to break hardware acceleration support[https://bbs.archlinux.org/viewtopic.php?id=200025], so if you get issues with hardware acceleration it might be a good idea to try out another display manager (lightdm seems to work fine). <br />
<br />
If you want to share folders between your host and your Arch Linux guest, read on.<br />
<br />
=== Enable shared folders ===<br />
<br />
Shared folders are managed on the host, in the settings of the Virtual Machine accessible via the GUI of VirtualBox, in the ''Shared Folders'' tab. There, ''Folder Path'', the name of the mount point identified by ''Folder name'', and options like ''Read-only'', ''Auto-mount'' and ''Make permanent'' can be specified. These parameters can be defined with the {{ic|VBoxManage}} command line utility. See [https://www.virtualbox.org/manual/ch04.html#sharedfolders there for more details].<br />
<br />
No matter which method you will use to mount your folder, all methods require some steps first.<br />
<br />
To avoid this issue {{ic|/sbin/mount.vboxsf: mounting failed with the error: No such device}}, make sure the {{ic|vboxsf}} kernel module is properly loaded. It should be, since we enabled all guest kernel modules previously.<br />
<br />
Two additional steps are needed in order for the mount point to be accessible from users other than root:<br />
* the {{Pkg|virtualbox-guest-utils}} package created a group {{ic|vboxsf}} (done in a previous step);<br />
* your username must be in this group, use this command {{ic|gpasswd -a $USER vboxsf}} to add your username and use {{ic|newgrp}} to apply the changes immediately;<br />
<br />
==== Manual mounting ====<br />
<br />
Use the following command to mount your folder in your Arch Linux guest:<br />
# mount -t vboxsf ''shared_folder_name'' ''mount_point_on_guest_system''<br />
<br />
The vboxsf filesystem offers other options which can be displayed with this command:<br />
# mount.vboxsf<br />
<br />
For example if the user was not in the ''vboxsf'' group, we could have used this command to give access our mountpoint to him:<br />
# mount -t vboxsf -o uid=1000,gid=1000 home /mnt/<br />
<br />
Where ''uid'' and ''gid'' are values corresponding to the users we want to give access to. These values are obtained from the {{ic|id}} command run against this user.<br />
<br />
==== Automounting ====<br />
<br />
In order for the automounting feature to work you must have checked the auto-mount checkbox in the GUI or used the optional {{ic|--automount}} argument with the command {{ic|VBoxManage sharedfolder}}.<br />
<br />
The shared folder should now appear in {{ic|/media/sf_''shared_folder_name''}}. If users in {{ic|media}} cannot access the shared folders, check that {{ic|media}} has permissions 755 or has group ownership {{ic|vboxsf}} if using permission 750. This is currently not the default if media is created by installing the {{ic|virtualbox-guest-utils}}.<br />
<br />
You can use symlinks if you want to have a more convenient access and avoid to browse in that directory, e.g.:<br />
$ ln -s /media/sf_''shared_folder_name'' ~/''my_documents''<br />
<br />
==== Mount at boot ====<br />
<br />
You can mount your directory with [[fstab]]. However, to prevent startup problems with systemd, {{ic|1=comment=systemd.automount}} should be added to {{ic|/etc/fstab}}. This way, the shared folders are mounted only when those mount points are accessed and not during startup. This can avoid some problems, especially if the guest additions are not loaded yet when systemd read fstab and mount the partitions.<br />
''sharedFolderName'' ''/path/to/mntPtOnGuestMachine'' vboxsf uid=''user'',gid=''group'',rw,dmode=700,fmode=600,comment=systemd.automount 0 0<br />
<br />
* {{ic|''sharedFolderName''}}: the value from the VirtualMachine's ''Settings > SharedFolders > Edit > FolderName'' menu. This value can be different from the name of the real folder name on the host machine. To see the VirtualMachine's ''Settings'' go to the host OS VirtualBox application, select the corresponding virtual machine and click on ''Settings''.<br />
* {{ic|''/path/to/mntPtOnGuestMachine''}}: if not existing, this directory should be created manually (for example by using [[Core utilities#mkdir|mkdir]])<br />
* {{ic|dmode}}/{{ic|fmode}} are directory/file permissions for directories/files inside {{ic|''/path/to/mntPtOnGuestMachine''}}.}}<br />
<br />
As of 2012-08-02, mount.vboxsf does not support the ''nofail'' option:<br />
''desktop'' ''/media/desktop'' vboxsf uid=''user'',gid=''group'',rw,dmode=700,fmode=600,nofail 0 0<br />
<br />
== Import/export VirtualBox virtual machines from/to other hypervisors ==<br />
<br />
If you plan to use your virtual machine on another hypervisor or want to import in VirtualBox a virtual machine created with another hypervisor, you might be interested in reading the following steps.<br />
<br />
=== Remove additions ===<br />
<br />
Guest additions are available in most hypervisor solutions: VirtualBox comes with the Guest Additions, VMware with the VMware Tools, Parallels with the Parallels Tools, etc. These additional components are designed to be installed inside a virtual machine after the guest operating system has been installed. They consist of device drivers and system applications that optimize the guest operating system for better performance and usability [https://www.virtualbox.org/manual/ch04.html by providing these features].<br />
<br />
If you have installed the additions to your virtual machine, please uninstall them first. Your guest, especially if it is using an OS from the Windows family, might behave weirdly, crash or even might not boot at all if you are still using the specific drivers in another hypervisor.<br />
<br />
=== Use the right virtual disk format ===<br />
<br />
This step will depend on the ability to convert the virtual disk image directly or not.<br />
<br />
==== Automatic tools ====<br />
<br />
Some companies provide tools which offer the ability to create virtual machines from a Windows or GNU/Linux operating system located either in a virtual machine or even in a native installation. With such a product, you do not need to apply this and the following steps and can stop reading here.<br />
* ''[http://www.parallels.com/products/transporter Parallels Transporter]'' which is non free, is a product from Parallels Inc. This solution basically consists in an piece of software called ''agent'' that will be installed in the guest you want to import/convert. Then, Parallels Transporter, <u>which only works on OS X</u>, will create a virtual machine from that ''agent'' which is contacted either by USB or Ethernet network.<br />
* ''[https://www.vmware.com/products/converter/ VMware vCenter Converter]'' which is free upon registration on the VMware webiste, works nearly the same way as Parallels Transporter, but the piece of software that will gather the data to create the virtual machine only works on a Windows platform.<br />
<br />
==== Manual conversion ====<br />
<br />
First, familiarize yourself with the [[#Formats supported by VirtualBox]] and [[Wikipedia:Comparison of platform virtual machines#Image type compatibility|those supported by third-party hypervisors]].<br />
<br />
* Importing or exporting a virtual machine from/to a VMware solution is not a problem at all if you use the VMDK or OVF disk format, otherwise converting [[#VMDK to VDI and VDI to VMDK]] is possible and the aforementioned VMware vCenter Converter tool is available.<br />
<br />
* Importing or exporting from/to QEMU is not a problem neither: some QEMU formats are supported directly by VirtualBox and conversion between [[#QCOW2 to VDI and VDI to QCOW2]] is still available if needed.<br />
<br />
* Importing or exporting from/to Parallels hypervisor is the hardest way: Parallels does only support its own HDD format (even the standard and portable OVF format is not supported!).<br />
:* To export your virtual machine to Parallels, you will need to use the Parallels Transporter tool described above.<br />
:* To import your virtual machine to VirtualBox, you will need to use the VMware vCenter Converter described above to convert the VM to the VMware format first. Then, apply the solution to migrate from VMware.<br />
<br />
=== Create the VM configuration for your hypervisor ===<br />
<br />
Each hypervisor have their own virtual machine configuration file: {{ic|.vbox}} for VirtualBox, {{ic|.vmx}} for VMware, a {{ic|config.pvs}} file located in the virtual machine bundle ({{ic|.pvm}} file), etc. You will have thus to recreate a new virtual machine in your new destination hypervisor and specify its hardware configuration as close as possible as your initial virtual machine.<br />
<br />
Pay a close attention to the firmware interface (BIOS or UEFI) used to install the guest operating system. While an option is available to choose between these 2 interfaces on VirtualBox and on Parallels solutions, on VMware, you will have to add manually the following line to your ''.vmx'' file.<br />
<br />
{{hc|ArchLinux_vm.vmx|2=<br />
firmware = "efi"<br />
}}<br />
<br />
Finally, ask your hypervisor to use the existing virtual disk you have converted and launch the virtual machine.<br />
{{Tip|<br />
* On VirtualBox, if you do not want to browse the whole GUI to find the right location to add your new virtual drive device, you can [[#Replace a virtual disk manually from the .vbox file]], or use the {{ic|VBoxManage storageattach}} described in [[#Increase virtual disks]] or in the [https://www.virtualbox.org/manual/ch08.html#vboxmanage-storageattach VirtualBox manual page].<br />
* Similarly, in VMware products, you can replace the location of the current virtual disk location by adapting the ''.vmdk'' file location in your ''.vmx'' configuration file.}}<br />
<br />
== Virtual disks management ==<br />
<br />
=== Formats supported by VirtualBox ===<br />
<br />
VirtualBox supports the following virtual disk formats:<br />
<br />
* VDI: The Virtual Disk Image is the VirtualBox own open container used by default when you create a virtual machine with VirtualBox.<br />
<br />
* VMDK: The Virtual Machine Disk has been initially developed by VMware for their products. The specification was initially closed source, but it became now an open format which is fully supported by VirtualBox. This format offers the ability to be split into several 2GB files. This feature is specially useful if you want to store the virtual machine on machines which do not support very large files. Other formats, excluding the HDD format from Parallels, do not provide such an equivalent feature.<br />
<br />
* VHD: The Virtual Hard Disk is the format used by Microsoft in Windows Virtual PC and Hyper-V. If you intend to use any of these Microsoft products, you will have to choose this format.<br />
:{{Tip|Since Windows 7, this format can be mounted directly without any additional application.}} <br />
<br />
* VHDX (read only): This is the eXtended version of the Virtual Hard Disk format developed by Microsoft, which has been released on 2012-09-04 with Hyper-V 3.0 coming with Windows Server 2012. This new version of the disk format does offer enhanced performance (better block alignment), larger blocks size, and journal support which brings power failure resiliency. VirtualBox [https://www.virtualbox.org/manual/ch15.html#idp63002176 should support this format in read only].<br />
<br />
* Version 2 of the HDD: The HDD format is developed by Parallels Inc and used in their hypervisor solutions like Parallels Desktop for Mac. Newer versions of this format (i.e. 3 and 4) are not supported due to the lack of documentation for this proprietary format. {{Note|There is currently a controversy regarding the support of the version 2 of the format. While the official VirtualBox manual [https://www.virtualbox.org/manual/ch05.html#vdidetails only reports the second version of the HDD file format as supported], Wikipedia's contributors are [[Wikipedia:Comparison of platform virtual machines#Image type compatibility|reporting the first version may work too]]. Help is welcome if you can perform some tests with the first version of the HDD format.}}<br />
<br />
* QED: The QEMU Enhanced Disk format is an old file format for QEMU, another free and open source hypervisor. This format was designed from 2010 in a way to provide a superior alternative to QCOW2 and others. This format features a fully asynchronous I/O path, strong data integrity, backing files, and sparse files. QED format is supported only for compatibility with virtual machines created with old versions of QEMU.<br />
<br />
* QCOW: The QEMU Copy On Write format is the current format for QEMU. The QCOW format does support zlib-based transparent compression and encryption (the latter has flaw and is not recommended). QCOW is available in two versions: QCOW and QCOW2. The latter tends to supersede the first one. QCOW is [https://www.virtualbox.org/manual/ch15.html#idp63002176 currently fully supported by VirtualBox]. QCOW2 comes in two revisions: QCOW2 0.10 and QCOW2 1.1 (which is the default when you create a virtual disk with QEMU). VirtualBox does not support this QCOW2 format (both revisions have been tried).<br />
<br />
* OVF: The Open Virtualization Format is an open format which has been designed for interoperability and distributions of virtual machines between different hypervisors. VirtualBox supports all revisions of this format via the [https://www.virtualbox.org/manual/ch08.html#idp55423424 VBoxManage import/export feature] but with [https://www.virtualbox.org/manual/ch14.html#KnownProblems known limitations].<br />
<br />
* RAW: This is the mode when the virtual disk is exposed directly to the disk without being contained in a specific file format container. VirtualBox supports this feature in several ways: converting RAW disk [https://www.virtualbox.org/manual/ch08.html#idp59139136 to a specific format], or by [https://www.virtualbox.org/manual/ch08.html#vboxmanage-clonevdi cloning a disk to RAW], or by using directly a VMDK file [https://www.virtualbox.org/manual/ch09.html#idp57804112 which points to a physical disk or a simple file].<br />
<br />
=== Disk image format conversion ===<br />
<br />
==== VMDK to VDI and VDI to VMDK ====<br />
<br />
VirtualBox can handle back and forth conversion between VDI and VMDK by itself with [https://www.virtualbox.org/manual/ch08.html#vboxmanage-clonevdi VBoxManage clonehd].<br />
<br />
VMDK to VDI:<br />
<br />
$ VBoxManage clonehd ''source.vmdk'' ''destination.vdi'' --format VDI<br />
<br />
VDI to VMDK:<br />
<br />
$ VBoxManage clonehd ''source.vdi'' ''destination.vmdk'' --format VMDK<br />
<br />
==== VHD to VDI and VDI to VHD ====<br />
<br />
VirtualBox can handle conversion back and forth this format with [https://www.virtualbox.org/manual/ch08.html#vboxmanage-clonevdi VBoxManage clonehd] too.<br />
<br />
VHD to VDI:<br />
<br />
$ VBoxManage clonehd ''source.vhd'' ''destination.vdi'' --format VDI<br />
<br />
VDI to VHD:<br />
<br />
$ VBoxManage clonehd ''source.vdi'' ''destination.vhd'' --format VHD<br />
<br />
==== QCOW2 to VDI and VDI to QCOW2 ====<br />
<br />
[https://www.virtualbox.org/manual/ch08.html#vboxmanage-clonevdi VBoxManage clonehd] cannot handle the QEMU format conversion; we will thus rely on another tool. The {{ic|qemu-img}} command from {{Pkg|qemu}} can be used to convert images back and forth from VDI to QCOW2. {{Note|{{ic|qemu-img}} can handle a bunch of other formats too. According to the {{ic|qemu-img --help}}, here are the supported formats this tool supports: "''vvfat vpc vmdk vhdx vdi ssh sheepdog sheepdog sheepdog raw host_cdrom host_floppy host_device file qed qcow2 qcow parallels nbd nbd nbd iscsi dmg tftp ftps ftp https http cow cloop bochs blkverify blkdebug'".}}<br />
<br />
QCOW2 to VDI:<br />
<br />
$ qemu-img convert -pO vdi ''source.qcow2'' ''destination.vdi''<br />
<br />
VDI to QCOW2:<br />
<br />
$ qemu-img convert -pO qcow2 ''source.vdi'' ''destination.qcow2''<br />
<br />
As QCOW2 comes in two revisions (see [[#Formats supported by VirtualBox]], use the flag {{ic|1=-o compat=}} to specify the revision.<br />
<br />
$ qemu-img convert -pO qcow2 ''source.vdi'' ''destination.qcow2'' -o compat=0.10<br />
or<br />
$ qemu-img convert -pO qcow2 ''source.vdi'' ''destination.qcow2'' -o compat=1.1<br />
<br />
{{Tip|The {{ic|-p}} parameter is used to get the progression of the conversion task.}}<br />
<br />
=== Mount virtual disks ===<br />
<br />
==== VDI ====<br />
<br />
Mounting vdi images only works with fixed size images (a.k.a. static images); dynamic (dynamically size allocating) images are not easily mountable.<br />
<br />
The offset of the partition (within the vdi) is needed, then add the value of {{ic|offData}} to {{ic|32256}} (e.g. 69632 + 32256 = 101888):<br />
<br />
$ VBoxManage internalcommands dumphdinfo <storage.vdi> | grep "offData"<br />
<br />
The can now be mounted with:<br />
<br />
# mount -t ext4 -o rw,noatime,noexec,loop,offset=101888 <storage.vdi> /mntpoint/<br />
<br />
You can also use [https://github.com/pld-linux/VirtualBox/blob/master/mount.vdi mount.vdi] script that, which you can use as (install script itself to {{ic|/usr/bin/}}):<br />
<br />
# mount -t vdi -o fstype=ext4,rw,noatime,noexec ''vdi_file_location'' ''/mnt/''<br />
<br />
Alternately you can use {{Pkg|qemu}}'s kernel module that can do this [[http://bethesignal.org/blog/2011/01/05/how-to-mount-virtualbox-vdi-image/ attrib]]:<br />
<br />
# modprobe nbd max_part=16<br />
# qemu-nbd -c /dev/nbd0 <storage.vdi><br />
# mount /dev/nbd0p1 /mnt/dir/<br />
# # to unmount:<br />
# umount /mnt/dir/<br />
# qemu-nbd -d /dev/nbd0<br />
<br />
If the partition nodes are not propagated try using {{ic|partprobe /dev/nbd0}}; otherwise, a vdi partition can be mapped directly to a node by: {{ic|qemu-nbd -P 1 -c /dev/nbd0 <storage.vdi>}}.<br />
<br />
=== Compact virtual disks ===<br />
<br />
Compacting virtual disks only works with {{ic|.vdi}} files and basically consists in the following steps.<br />
<br />
Boot your virtual machine and remove all bloat manually or by using cleaning tools like {{Pkg|bleachbit}} which is [http://bleachbit.sourceforge.net/download/windows available for Windows systems too].<br />
<br />
Wiping free space with zeroes can be achieved with several tools:<br />
* If you were previously using Bleachbit, check the checkbox ''System > Free disk space'' in the GUI, or use {{ic|bleachbit -c system.free_disk_space}} in CLI;<br />
* On UNIX-based systems, by using {{ic|dd}} or preferably {{Pkg|dcfldd}} (see [http://superuser.com/a/355322 here] to learn the differences) :<br />
:{{bc|1=# dcfldd if=/dev/zero of=''/fillfile'' bs=4M}}<br />
:When {{ic|fillfile}} reaches the limit of the partition, you will get a message like {{ic|1280 blocks (5120Mb) written.dcfldd:: No space left on device}}. This means that all of the user-space and non-reserved blocks of the partition will be filled with zeros. Using this command as root is important to make sure all free blocks have been overwritten. Indeed, by default, when using partitions with ext filesystem, a specified percentage of filesystem blocks is reserved for the super-user (see the {{ic|-m}} argument in the {{ic|mkfs.ext4}} man pages or use {{ic|tune2fs -l}} to see how much space is reserved for root applications).<br />
:When the aforementioned process has completed, you can remove the file {{ic|''fillfile''}} you created.<br />
<br />
* On Windows, there are two tools available:<br />
:*{{ic|sdelete}} from the [http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx Sysinternals Suite], type {{ic|sdelete -s -z ''c:''}}, where you need to reexecute the command for each drive you have in your virtual machine;<br />
:* or, if you love scripts, there is a [http://blog.whatsupduck.net/2012/03/powershell-alternative-to-sdelete.html PowerShell solution], but which still needs to be repeated for all drives.<br />
::{{bc|PS> ./Write-ZeroesToFreeSpace.ps1 -Root ''c:\'' -PercentFree 0}}<br />
::{{Note|This script must be run in a PowerShell environment with administrator privileges. By default, scripts cannot be run, ensure the execution policy is at least on {{ic|RemoteSigned}} and not on {{ic|Restricted}}. This can be checked with {{ic|Get-ExecutionPolicy}} and the required policy can be set with {{ic|Set-ExecutionPolicy RemoteSigned}}.}}<br />
<br />
Once the free disk space have been wiped, shut down your virtual machine.<br />
<br />
The next time you boot your virtual machine, it is recommended to do a filesystem check.<br />
* On UNIX-based systems, you can use {{ic|fsck}} manually;<br />
:* On GNU/Linux systems, and thus on Arch Linux, you can force a disk check at boot [[Fsck#Forcing the check|thanks to a kernel boot parameter]];<br />
* On Windows systems, you can use:<br />
:* either {{ic|chkdsk ''c:'' /F}} where {{ic|''c:''}} needs to be replaced by each disk you need to scan and fix errors;<br />
:* or {{ic|FsckDskAll}} [http://therightstuff.de/2009/02/14/ChkDskAll-ChkDsk-For-All-Drives.aspx from here] which is basically the same software as {{ic|chkdsk}}, but without the need to repeat the command for all drives;<br />
<br />
Now, remove the zeros from the {{ic|vdi}} file with [https://www.virtualbox.org/manual/ch08.html#vboxmanage-modifyvdi VBoxManage modifyhd]:<br />
$ VBoxManage modifyhd ''your_disk.vdi'' --compact<br />
<br />
{{Note|If your virtual machine has snapshots, you need to apply the above command on each {{ic|.vdi}} files you have.}}<br />
<br />
=== Increase virtual disks ===<br />
<br />
==== General procedure ====<br />
<br />
If you are running out of space due to the small hard drive size you selected when you created your virtual machine, the solution adviced by the VirtualBox manual is to use [https://www.virtualbox.org/manual/ch08.html#vboxmanage-modifyvdi VBoxManage modifyhd]. However this command only works for VDI and VHD disks and only for the dynamically allocated variants. If you want to resize a fixed size virtual disk disk too, read on this trick which works either for a Windows or UNIX-like virtual machine.<br />
<br />
First, create a new virtual disk next to the one you want to increase:<br />
$ VBoxManage createhd -filename ''new.vdi'' --size ''10000''<br />
<br />
where size is in MiB, in this example 10000MiB ~= 10GiB, and ''new.vdi'' is name of new hard drive to be created.<br />
<br />
Next, the old virtual disk needs to be cloned to the new one which this may take some time:<br />
$ VBoxManage clonehd ''old.vdi'' ''new.vdi'' --existing<br />
<br />
{{Note|By default, this command uses the ''Standard'' (corresponding to dynamic allocated) file format variant and thus will not use the same file format variant as your source virtual disk. If your ''old.vdi'' has a fixed size and you want to keep this variant, add the parameter {{ic|--variant Fixed}}.}}<br />
<br />
Detach the old hard drive and attach new one, replace all mandatory italic arguments by your own:<br />
$ VBoxManage storageattach ''VM_name'' --storagectl ''SATA'' --port ''0'' --medium none<br />
$ VBoxManage storageattach ''VM_name'' --storagectl ''SATA'' --port ''0'' --medium ''new.vdi'' --type hdd<br />
<br />
To get the storage controller name and the port number, you can use the command {{ic|VBoxManage showvminfo ''VM_name''}}. Among the output you will get such a result (what you are looking for is in italic):<br />
<br />
{{bc|<br />
[...]<br />
Storage Controller Name (0): IDE<br />
Storage Controller Type (0): PIIX4<br />
Storage Controller Instance Number (0): 0<br />
Storage Controller Max Port Count (0): 2<br />
Storage Controller Port Count (0): 2<br />
Storage Controller Bootable (0): on<br />
Storage Controller Name (1): SATA<br />
Storage Controller Type (1): IntelAhci<br />
Storage Controller Instance Number (1): 0<br />
Storage Controller Max Port Count (1): 30<br />
Storage Controller Port Count (1): 1<br />
Storage Controller Bootable (1): on<br />
IDE (1, 0): Empty<br />
''SATA'' (''0'', 0): /home/wget/IT/Virtual_machines/GNU_Linux_distributions/ArchLinux_x64_EFI/Snapshots/{6bb17af7-e8a2-4bbf-baac-fbba05ebd704}.vdi (UUID: 6bb17af7-e8a2-4bbf-baac-fbba05ebd704)<br />
[...]}}<br />
<br />
Download [http://gparted.org/download.php GParted live image] and mount it as a virtual CD/DVD disk file, boot your virtual machine, increase/move your partitions, umount GParted live and reboot.<br />
<br />
{{Note|On GPT disks, increasing the size of the disk will result in the backup GPT header not being at the end of the device. GParted will ask to fix this, click on ''Fix'' both times. On MBR disks, you do not have such a problem as this partition table as no trailer at the end of the disk.}}<br />
<br />
Finally, unregister the virtual disk from VirtualBox and remove the file:<br />
$ VBoxManage closemedium disk ''old.vdi''<br />
$ rm ''old.vdi''<br />
<br />
==== Increase size for VDI disks ====<br />
If your disk is a vdi one, simply run:<br />
<br />
$ VBoxManage modifyhd ''your_virtual_disk.vdi'' --resize ''the_new_size''<br />
<br />
Then jump back to the Gparted step, to increase the size of the partition on the virtual disk.<br />
<br />
=== Replace a virtual disk manually from the .vbox file ===<br />
<br />
If you think that editing a simple ''XML'' file is more convenient than playing with the GUI or with {{ic|VBoxManage}} and you want to replace (or add) a virtual disk to your virtual machine, in the ''.vbox'' configuration file corresponding to your virtual machine, simply replace the GUID, the file location and the format to your needs:<br />
<br />
{{hc|ArchLinux_vm.vbox|2=<br />
<HardDisk uuid="''{670157e5-8bd4-4f7b-8b96-9ee412a712b5}''" location="''ArchLinux_vm.vdi''" format="''VDI''" type="Normal"/><br />
}}<br />
<br />
then in the {{ic|<AttachedDevice>}} sub-tag of {{ic|<StorageController>}}, replace the GUID by the new one.<br />
<br />
{{hc|ArchLinux_vm.vbox|2=<br />
<AttachedDevice type="HardDisk" port="0" device="0"><br />
<Image uuid="''{670157e5-8bd4-4f7b-8b96-9ee412a712b5}''"/><br />
</AttachedDevice><br />
}}<br />
<br />
{{Note|If you do not know the GUID of the drive you want to add, you can use the {{ic|VBoxManage showhdinfo ''file''}}. If you previously used {{ic|VBoxManage clonehd}} to copy/convert your virtual disk, this command should have outputted the GUID just after the copy/conversion completed. Using a random GUID does not work, as each [http://www.virtualbox.org/manual/ch05.html#cloningvdis UUID is stored inside each disk image].}}<br />
<br />
==== Transfer between Linux host and other OS ====<br />
<br />
The information about path to harddisks and the snapshots is stored between {{ic|<HardDisks> .... </HardDisks>}} tags in the file with the ''.vbox'' extension. You can edit them manually or use this script where you will need change only the path or use defaults, assumed that ''.vbox'' is in the same directory with a virtual harddisk and the snapshots folder. It will print out new configuration to stdout.<br />
<br />
{{bc|1=<br />
#!/bin/bash<br />
NewPath="${PWD}/"<br />
Snapshots="Snapshots/"<br />
Filename="$1"<br />
<br />
awk -v SetPath="$NewPath" -v SnapPath="$Snapshots" '{if(index($0,"<HardDisk uuid=") != 0){A=$3;split(A,B,"=");<br />
L=B[2];<br />
gsub(/\"/,"",L);<br />
sub(/^.*\//,"",L);<br />
sub(/^.*\\/,"",L);<br />
if(index($3,"{") != 0){SnapS=SnapPath}else{SnapS=""};<br />
print $1" "$2" location="\"SetPath SnapS L"\" "$4" "$5}<br />
else print $0}' "$Filename"}}<br />
<br />
{{Note|<br />
* If you will prepare virtual machine for use in Windows host then in the path name end you should use backslash \ instead of / .<br />
* The script detects snapshots by looking for {{ic|{}} in the file name.<br />
* To make it run on a new host you will need to add it first to the register by clicking on '''Machine -> Add...''' or use hotkeys Ctrl+A and then browse to ''.vbox'' file that contains configuration or use command line {{ic|VBoxManage registervm ''filename''.vbox}}}}<br />
<br />
=== Clone a virtual disk and assigning a new UUID to it ===<br />
<br />
UUIDs are widely used by VirtualBox. Each virtual machines and each virtual disk of a virtual machine must have a different UUID. When you launch a virtual machine in VirtualBox, the latter will keep track of all UUID of your virtual machine instance. See the [http://www.virtualbox.org/manual/ch08.html#vboxmanage-list VBoxManage list] to list the items registered with VirtualBox.<br />
<br />
If you cloned a virtual disk manually by copying the virtual disk file, you will need to assign a new UUID to the cloned virtual drive if you want to use the disk in the same virtual machine or even in another (if that one has already been opened, and thus registered, with VirtualBox).<br />
<br />
You can use this command to assign a new UUID to your virtual disk: <br />
$ VBoxManage internalcommands sethduuid ''/path/to/disk.vdi''<br />
<br />
{{Tip|In the future, to avoid copying the virtual disk and assigning a new UUID to your file manually, use [http://www.virtualbox.org/manual/ch08.html#vboxmanage-clonevdi VBoxManage clonehd] instead.}}<br />
<br />
{{Note|The commands above supports [[#Formats supported by VirtualBox|all virtual disk formats supported by VirtualBox]].}}<br />
<br />
== Advanced configuration ==<br />
<br />
=== Virtual machine launch management ===<br />
<br />
==== Starting virtual machines with a service ====<br />
<br />
Find hereafter the implementation details of a systemd service that will be used to consider a virtual machine as a service.<br />
<br />
{{hc|/etc/systemd/system/vboxvmservice@.service|2=<br />
[Unit]<br />
Description=VBox Virtual Machine %i Service<br />
Requires=systemd-modules-load.service<br />
After=systemd-modules-load.service<br />
<br />
[Service]<br />
User=''username''<br />
Group=vboxusers<br />
ExecStart=/usr/bin/VBoxHeadless -s %i<br />
ExecStop=/usr/bin/VBoxManage controlvm %i savestate<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
{{Note|Replace {{ic|''username''}} with a user that is a member of the {{ic|vboxusers}} group. Make sure the user chosen is the same user that will create/import virtual machines, otherwise the user will not see the VM appliances.}}<br />
<br />
{{Note|If you have multiple virtual machines managed by Systemd and they are not stopping properly, try to add {{ic|RemainAfterExit&#61;true}} and {{ic|KillMode&#61;none}} at the end of {{ic|[Service]}} section.}}<br />
<br />
To enable the service that will launch the virtual machine at next boot, use:<br />
# systemctl enable vboxvmservice@''your_virtual_machine_name''<br />
<br />
To start the service that will launch directly the virtual machine, use:<br />
# systemctl start vboxvmservice@''your_virtual_machine_name''<br />
<br />
VirtualBox 4.2 introduces [http://lifeofageekadmin.com/how-to-set-your-virtualbox-vm-to-automatically-startup/ a new way] for UNIX-like systems to have virtual machines started automatically, other than using a systemd service.<br />
<br />
==== Starting virtual machines with a keyboard shortcut ====<br />
<br />
It can be useful to start virtual machines directly with a keyboard shortcut instead of using the VirtualBox interface (GUI or CLI). For that, you can simply define key bindings in {{ic|.xbindkeysrc}}. Please refer to [[Xbindkeys]] for more details.<br />
<br />
Example, using the {{ic|Fn}} key of a laptop with an unused battery key ({{ic|F3}} on the computer used in this example):<br />
"VBoxManage startvm 'Windows 7'"<br />
m:0x0 + c:244<br />
XF86Battery<br />
<br />
{{Note|If you have a space in the name of your virtual machine, then enclose it with single apostrophes like made in the example just above.}}<br />
<br />
=== Use specific device in the virtual machine ===<br />
<br />
==== Using USB webcam / microphone ====<br />
<br />
{{Note|You will need to have VirtualBox extension pack installed before following the steps below. See [[#Extension pack]] for details.}}<br />
<br />
# Make sure the virtual machine is not running and your webcam / microphone is not being used.<br />
# Bring up the main VirtualBox window and go to settings for Arch machine. Go to USB section.<br />
# Make sure "Enable USB Controller" is selected. Also make sure that "Enable USB 2.0 (EHCI) Controller" is selected too.<br />
# Click the "Add filter from device" button (the cable with the '+' icon).<br />
# Select your USB webcam/microphone device from the list.<br />
# Now click OK and start your VM.<br />
<br />
{{Note|If your Microphone does not show up in the "Add filter from device" menu, try the USB 3.0 and 1.1 options instead (In Step 3).}}<br />
<br />
==== Detecting web-cams and other USB devices ====<br />
<br />
{{Note|This will not do much if you are running a *NIX OS inside of your VM, as most do not have autodetection features.}}<br />
If the device that you are looking for does not show up on any of the menus in the section above and you have tried all three USB controller options,<br />
boot up your VM three seperate times. Once using the USB 1.1 controller, Once using the USB 2.0 controller, etc. Leave the VM running for <br />
at least 5 minutes after startup. Sometimes Windows will autodetect the device for you.<br />
Be sure you filter any devices that are not a keyboard or a mouse so they do not start up at boot. <br />
This insures that Windows will detect the device at start-up.<br />
<br />
=== Access a guest server ===<br />
<br />
To access [[Wikipedia:Apache_HTTP_Server|Apache server]] on a Virtual Machine from the host machine '''only''', simply execute the following lines on the host:<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/''pcnet''/0/LUN#0/Config/Apache/HostPort" ''8888''<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/''pcnet''/0/LUN#0/Config/Apache/GuestPort" ''80''<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/''pcnet''/0/LUN#0/Config/Apache/Protocol" TCP<br />
Where 8888 is the port the host should listen on and 80 is the port the VM will send Apache's signal on.<br />
<br />
To use a port lower than 1024 on the host machine, changes need to be made to the firewall on that host machine. This can also be set up to work with SSH or any other services by changing "Apache" to the corresponding service and ports. <br />
<br />
{{note|{{ic|pcnet}} refers to the network card of the VM. If you use an Intel card in your VM settings, change {{ic|pcnet}} to {{ic|e1000}}.}}<br />
<br />
To communicate between the VirtualBox guest and host using ssh, the server port must be forwarded under Settings > Network. When connecting from the client/host, connect to the IP address of the client/host machine, as opposed to the connection of the other machine. This is because the connection will be made over a virtual adapter.<br />
<br />
=== D3D acceleration in Windows guests ===<br />
<br />
Recent versions of Virtualbox have support for accelerating OpenGL inside guests. This can be enabled with a simple checkbox in the machine's settings, right below where video ram is set, and installing the Virtualbox guest additions. However, most Windows games use Direct3D (part of DirectX), not OpenGL, and are thus not helped by this method. However, it is possible to gain accelerated Direct3D in your Windows guests by borrowing the d3d libraries from Wine, which translate d3d calls into OpenGL, which is then accelerated. These libraries are now part of Virtualbox guest additions software. <br />
<br />
After enabling OpenGL acceleration as described above, reboot the guest into safe mode (press F8 before the Windows screen appears but after the Virtualbox screen disappears), and install Virtualbox guest additions, during install enable checkbox "Direct3D support". Reboot back to normal mode and you should have accelerated Direct3D. <br />
<br />
{{Note | This hack may or may not work for some games depending on what hardware checks they make and what parts of D3D they use.}}<br />
{{Note | This was tested on Windows XP, 7 and 8.1. If method does not work on your Windows version please add data here.}}<br />
<br />
=== VirtualBox on a USB key ===<br />
When using VirtualBox on a USB key, for example to start an installed machine with an ISO image, you will manually have to create VDMKs from the existing drives. However, once the new VMDKs are saved and you move on to another machine, you may experience problems launching an appropriate machine again. To get rid of this issue, you can use the following script to launch VirtualBox. This script will clean up and unregister old VMDK files and it will create new, proper VMDKs for you:<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
# Erase old VMDK entries<br />
rm ~/.VirtualBox/*.vmdk<br />
<br />
# Clean up VBox-Registry<br />
sed -i '/sd/d' ~/.VirtualBox/VirtualBox.xml<br />
<br />
# Remove old harddisks from existing machines<br />
find ~/.VirtualBox/Machines -name \*.xml | while read file; do<br />
line=`grep -e "type\=\"HardDisk\"" -n $file | cut -d ':' -f 1`<br />
if [ -n "$line" ]; then<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
fi<br />
sed -i "/rg/d" $file<br />
done<br />
<br />
# Delete prev-files created by VirtualBox<br />
find ~/.VirtualBox/Machines -name \*-prev -exec rm '{}' \;<br />
<br />
# Recreate VMDKs<br />
ls -l /dev/disk/by-uuid | cut -d ' ' -f 9,11 | while read ln; do<br />
if [ -n "$ln" ]; then<br />
uuid=`echo "$ln" | cut -d ' ' -f 1`<br />
device=`echo "$ln" | cut -d ' ' -f 2 | cut -d '/' -f 3 | cut -b 1-3`<br />
<br />
# determine whether drive is mounted already<br />
checkstr1=`mount | grep $uuid`<br />
checkstr2=`mount | grep $device`<br />
checkstr3=`ls ~/.VirtualBox/*.vmdk | grep $device`<br />
if [[ -z "$checkstr1" && -z "$checkstr2" && -z "$checkstr3" ]]; then<br />
VBoxManage internalcommands createrawvmdk -filename ~/.VirtualBox/$device.vmdk -rawdisk /dev/$device -register<br />
fi<br />
fi<br />
done<br />
<br />
# Start VirtualBox<br />
VirtualBox<br />
</nowiki>}}<br />
Note that your user has to be added to the "disk" group to create VMDKs out of existing drives.<br />
<br />
=== Run a native Arch Linux installation inside VirtualBox ===<br />
<br />
If you have a dual boot system between Arch Linux and another operating system, it can become rapidly tedious to switch back and forth if you need to work in both. Also, by using virtual machines, you just have a tiny fragment of your computer power, which can cause issues when working on projects requiring performance.<br />
<br />
This guide will let you reuse, in a virtual machine, your native Arch Linux installation when you are running your second operating system. This way, you keep the ability to run each operating system natively, but have the option to run your Arch Linux installation inside a virtual machine.<br />
<br />
==== Make sure you have a persistent naming scheme ====<br />
<br />
Depending on your hard drive setup, device files representing your hard drives may appear differently when you will run your Arch Linux installation natively or in virtual machine. This problem occurs when using [[RAID#Implementation|FakeRAID]] for example. The fake RAID device will be mapped in {{ic|/dev/mapper/}} when you run your GNU/Linux distribution natively, while the devices are still accessible separately. However, in your virtual machine, it can appear without any mapping in {{ic|/dev/sdaX}} for example, because the drivers controlling the fake RAID in your host operating system (e.g. Windows) are abstracting the fake RAID device.<br />
<br />
To circumvent this problem, we will need to use an addressing scheme that is persistent to both systems. This can be achieved using [[Fstab#UUIDs|UUIDs]] in your {{ic|/etc/fstab}} file. Make sure your [[fstab]] file is using UUIDs, otherwise fix this issue. Read [[fstab]] and [[Persistent block device naming]].<br />
<br />
{{ic|/etc/fstab}} is not the only location where UUIDs are used. Bootloaders and boot managers make use of them too. Now, make sure these are really using UUIDs.<br />
<br />
; [[GRUB Legacy]]<br />
If you are still using the old [[GRUB Legacy]], maybe is it [[GRUB Legacy#Upgrading to GRUB2|time to upgrade]], since this package is now dropped from the official Arch Linux repositories. If you want to keep it, edit {{ic|/boot/grub/menu.lst}} and replace the {{ic|1=root=/dev/sdXX}} statement in your Arch Linux boot entry by the Linux UUID mapping in {{ic|/dev/disk/by-uuid/}} corresponding to your root partition.<br />
<br />
title Arch Linux<br />
root<br />
kernel /vmlinuz-linux root=''/dev/disk/by-uuid/0a3407de-014b-458b-b5c1-848e92a327a3'' ro vga=773<br />
initrd /initramfs-linux-vbox.img<br />
<br />
Repeat the process here, for the fallback entry.<br />
<br />
; [[GRUB]]<br />
If you are running the most recent version of [[GRUB]]; you have nothing to do. Yet another reason to upgrade to GRUB 2.<br />
<br />
{{Warning|<br />
* Make sure your host partition is only accessible in read only from your Arch Linux virtual machine, this will avoid risk of corruptions if you were to corrupt that host partition by writing on it due to lack of attention.<br />
* You should NEVER allow VirtualBox to boot from the entry of your second operating system, which, as a reminder, is used as the host for this virtual machine! Take thus a special care especially if your default boot loader/boot manager entry is your other operating system. Give a more important timeout or put it below in the order of preferences.}}<br />
<br />
==== Make sure your mkinitcpio image is correct ====<br />
<br />
Make sure your [[Mkinitcpio|mkinitcpio]] configuration uses the [[Mkinitcpio#HOOKS|HOOK]] {{ic|block}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
[...]<br />
HOOKS="base udev autodetect modconf ''block'' filesystems keyboard fsck"<br />
[...]}}<br />
<br />
If it is not present, add it and [[Mkinitcpio#Image creation and activation|regenerate your initramfs]]:<br />
<br />
# mkinitcpio -p linux<br />
<br />
==== Create a VM configuration to boot from the physical drive ====<br />
<br />
===== Create a raw disk .vmdk image =====<br />
<br />
Now, we need to create a new virtual machine which will use a [https://www.virtualbox.org/manual/ch09.html#rawdisk RAW disk] as virtual drive, for that we will use a ~ 1Kio VMDK file which will be mapped to a physical disk. Unfortunately, VirtualBox does not have this option in the GUI, so we will have to use the console and use an internal command of {{ic|VBoxManage}}.<br />
<br />
Boot the host which will use the Arch Linux virtual machine. The command will need to be adapted according to the host you have.<br />
<br />
; On a GNU/Linux host:<br />
<br />
There is 3 ways to achieve this: login as root, changing the access right of the device with {{ic|chmod}}, adding your user to the {{ic|disk}} group. The latter way is the more elegant, let us proceed that way:<br />
<br />
# gpasswd -a ''your_user'' disk<br />
<br />
Apply the new group settings with:<br />
<br />
$ newgrp<br />
<br />
Now, you can use the command:<br />
<br />
$ VBoxManage internalcommands createrawvmdk -filename ''/path/to/file.vmdk'' -rawdisk ''/dev/sdb'' -register <br />
<br />
Adapt the above command to your need, especially the path and filename of the VMDK location and the raw disk location to map which contain your Arch Linux installation.<br />
<br />
; On a Windows host:<br />
<br />
Open a command prompt must be run as administrator. {{Tip|On Windows, open your start menu/start screen, type {{ic|cmd}}, and type {{ic|Ctrl+Shift+Enter}}, this is a shortcut to execute the selected program with admin rights.}}<br />
<br />
On Windows, as the disk filename convention is different from UNIX, use this command to determine what drives you have in your Windows system and their location:{{hc|# wmic diskdrive get name,size,model|<br />
Model Name Size<br />
WDC WD40EZRX-00SPEB0 ATA Device \\.\PHYSICALDRIVE1 4000783933440<br />
KINGSTON SVP100S296G ATA Device \\.\PHYSICALDRIVE0 96024821760<br />
Hitachi HDT721010SLA360 ATA Device \\.\PHYSICALDRIVE2 1000202273280<br />
Innostor Ext. HDD USB Device \\.\PHYSICALDRIVE3 1000202273280}}<br />
<br />
In this example, as the Windows convention is {{ic|\\.\PhysicalDriveX}} where X is a number from 0, {{ic|\\.\PHYSICALDRIVE1}} could be analogous to {{ic|/dev/sdb}} from the Linux disk terminology.<br />
<br />
To use the {{ic|VBoxManage}} command on Windows, you can either, change the current directory to your VirtualBox installation folder first with {{ic|cd C:\Program Files\Oracle\VirtualBox\}}<br />
<br />
# .\VBoxManage.exe internalcommands createrawvmdk -filename C:\file.vmdk -rawdisk \\.\PHYSICALDRIVE1<br />
<br />
or use the absolute path name: <br />
<br />
# "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" internalcommands createrawvmdk -filename C:\file.vmdk -rawdisk \\.\PHYSICALDRIVE1<br />
<br />
; On another OS host:<br />
<br />
There are other limitations regarding the aforementioned command when used in other operating systems like OS X, please thus [https://www.virtualbox.org/manual/ch09.html#rawdisk read carefully the manual page], if you are concerned.<br />
<br />
===== Create the VM configuration file =====<br />
<br />
{{Note|<br />
* To make use of the VBoxManage command on Windows, you need to change the current directory to your VirtualBox installation folder first: cd C:\Program Files\Oracle\VirtualBox\.<br />
* Windows makes use of backslashes instead of slashes, please replace all slashes / occurrences by backslashes \ in the commands that follow when you will use them.}}<br />
<br />
After, we need to create a new machine (replace the ''VM_name'' to your convenience) and register it with VirtualBox.<br />
<br />
$ VBoxManage createvm -name ''VM_name'' -register<br />
<br />
Then, the newly raw disk needs to be attached to the machine. This will depend if your computer or actually the root of your native Arch Linux installation is on an IDE or a SATA controller.<br />
<br />
If you need an IDE controller:<br />
<br />
$ VBoxManage storagectl ''VM_name'' --name "IDE Controller" --add ide<br />
$ VBoxManage storageattach ''VM_name'' --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /path/to/file.vmdk<br />
<br />
otherwise:<br />
<br />
$ VBoxManage storagectl ''VM_name'' --name "SATA Controller" --add sata<br />
$ VBoxManage storageattach ''VM_name'' --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium /path/to/file.vmdk<br />
<br />
While you continue using the CLI, it is recommended to use the VirtualBox GUI, to personalise the virtual machine configuration. Indeed, you must specify its hardware configuration as close as possible as your native machine: turning on the 3D acceleration, increasing video memory, setting the network interface, etc.<br />
<br />
==== Install the Guest Additions ====<br />
<br />
Finally, you may want to seamlessly integrate your Arch Linux with your host operating system and allow copy pasting between both OSes. Please refer to [[#Install the Guest Additions]] for that, since this Arch Linux virtual machine is basically an Arch Linux guest.<br />
<br />
{{Warning|For [[Xorg]] to work in natively and in the virtual machine, since obviously it will be using different drivers, it is best if there is no {{ic|/etc/X11/xorg.conf}}, so Xorg will pick up everything it needs on the fly. However, if you really do need your own Xorg configuration, maybe is it worth to set your default systemd target to {{ic|multi-user.target}} with {{ic|systemctl isolate graphical.target}} as root (more details at [[Systemd#Targets table]] and [[Systemd#Change current target]]). In that way, the graphical interface is disabled (i.e. Xorg is not launched) and after you logged in, you can {{ic|startx}}} manually with a custom {{ic|xorg.conf}}.}}<br />
<br />
=== Install a native Arch Linux system from VirtualBox ===<br />
<br />
In some cases it may be useful to install a native Arch Linux system while running another operating system: one way to accomplish this is to perform the installation through VirtualBox on a [http://www.virtualbox.org/manual/ch09.html#rawdisk raw disk]. If the existing operating system is Linux based, you may want to consider following [[Install from Existing Linux]] instead.<br />
<br />
This scenario is very similar to [[#Run a native Arch Linux installation inside VirtualBox]], but will follow those steps in a different order: start by [[#Create a raw disk .vmdk image]], then [[#Create the VM configuration file]].<br />
<br />
Now, you should have a working VM configuration whose virtual VMDK disk is tied to a real disk. The installation process is exactly the same as the steps described in [[#Installation steps for Arch Linux guests]], but [[#Make sure you have a persistent naming scheme]] and [[#Make sure your mkinitcpio image is correct]].<br />
<br />
{{Warning|<br />
*For BIOS systems and MBR disks, do not install a bootloader inside your virtual machine, this will not work since the MBR is not linked to the MBR of your real machine and your virtual disk is only mapped to a real partition without the MBR.<br />
*For UEFI systems without [[Wikipedia:Compatibility Support Module#CSM|CSM]] and GPT disks, the installation will not work at all since:<br />
:*the [[Wikipedia:EFI System partition|ESP]] partition is not mapped to your virtual disk and Arch Linux requires to have the Linux kernel on it to boot as an EFI application (see [[EFISTUB]] for details);<br />
:*and the efivars, if you are installing Arch Linux using the EFI mode brought by VirtualBox, are not the one of your real system: the bootmanager entries will hence not be registered.<br />
*This is why, it is recommended to create your partitions in a native installation first, otherwize the partitions will not be taken into consideration in your MBR/GPT partition table.}}<br />
<br />
After completing the installation, boot your computer natively with an GNU/Linux installation media (whether it be Arch Linux or not), [[Beginner's Guide#Chroot and configure the base system|chroot]] into your installed Arch Linux installation and [[Beginner's Guide#Install and configure a bootloader|#Install and configure a bootloader]].<br />
<br />
=== Move a native Windows installation to a virtual machine ===<br />
<br />
If you want to migrate an existing native Windows installation to a virtual machine which will be used with VirtualBox on GNU/Linux, this use case is for you. This section only covers native Windows installation using the MSDOS/Intel partition scheme. Your Windows installation must reside on the first MBR partition for this operation to success. Operation for other partitions are available but have been untested (see [[#Known limitations]] for details).<br />
<br />
{{Warning|If you are using an OEM version of Windows, this process is unauthorized by the end user license license. Indeed, the OEM license typically states the Windows install is tied with the hardware together. Transferring a Windows install to a virtual machine removes this link. Make thus sure you have a full Windows install or a volume license model before continuing. If you have a full Windows license but the latter is not coming in volume, nor as a special license for several PCs, this means you will have to remove the native installation after the transfer operation has been achieved.}}<br />
<br />
A couple of tasks are required to be done inside your native Windows installation first, then on your GNU/Linux host.<br />
<br />
==== Tasks on Windows ====<br />
<br />
The first three following points comes from [https://www.virtualbox.org/wiki/Migrate_Windows#HAL this outdated VirtualBox wiki page], but are updated here.<br />
<br />
* Remove IDE/ATA controllers checks (Windows XP only): Windows memorize the IDE/ATA drive controllers it has been installed on and will not boot if it detects these have changed. The solution proposed by Microsoft is to reuse the same controller or use one of the same serial, which is impossible to achieve since we are using a Virtual Machine. [https://www.virtualbox.org/wiki/Migrate_Windows#HardDiskSupport MergeIDE], a German tool, developped upon another other solution proposed by Microsoft can be used. That solution basically consists in taking all IDE/ATA controller drivers supported by Windows XP from the initial driver archive (the location is hard coded, or specify it as the first argument to the {{ic|.bat}} script), installing them and registering them with the regedit database.<br />
<br />
* Use the right type of Hardware Abstraction Layer (old 32 bits Windows versions): Microsoft ships 3 default versions: {{ic|Hal.dll}} (Standard PC), {{ic|Halacpi.dll}} (ACPI HAL) and {{ic|Halaacpi.dll}} (ACPI HAL with IO APIC). Your Windows install could come installed with the first or the second version. In that way, please [https://www.virtualbox.org/manual/ch08.html#idp56927888 disable the ''Enable IO/APIC'' VirtualBox extended feature].<br />
<br />
* Disable any AGP device driver (only outdated Windows versions): If you have the files {{ic|agp440.sys}} or {{ic|intelppm.sys}} inside the {{ic|C:\Windows\SYSTEM32\drivers\}} directory, remove it. As VirtualBox uses a PCI virtual graphic card, this can cause problems when this AGP driver is used.<br />
<br />
* Create a Windows recovery disk: In the following steps, if things turn bad, you will need to repair your Windows installation. Make sure you have an install media at hand, or create one with ''Create a recovery disk'' from Vista SP1, ''Create a system repair disc'' on Windows 7 or ''Create a recovery drive'' on Windows 8.x).<br />
<br />
==== Using Disk2vhd to clone Windows partition ====<br />
Boot into Windows, clean up the installation (with [http://www.piriform.com/ccleaner CCleaner] for example), use [https://technet.microsoft.com/en-us/library/ee656415.aspx disk2vhd] tool to create a VHD image. Include a reserved system partition (if present) and the actual Windows partition (usually disk C:). The size of Disk2vhd-created image will be the sum of the actual files on the partition (used space), not the size of a whole partition. If all goes well, the image should just boot in a VM and you won't have to go through the hassle with MBR and Windows bootloader, as in the case of cloning an entire partition.<br />
<br />
==== Tasks on GNU/Linux ====<br />
<br />
{{Tip|Skip the partition-related parts if you created VHD image with [[#Using Disk2vhd to clone Windows partition|Disk2vhd]].}}<br />
<br />
* Reduce the native Windows partition size to the size Windows actually needs with {{ic|ntfsresize}} available from {{Pkg|ntfs-3g}}. The size you will specify will be the same size of the VDI that will be created in the next step. If this size is too low, you may break your Windows install and the latter might not boot at all.<br />
<br />
:Use the {{ic|--no-action}} option first to run a test:<br />
:{{bc|# ntfsresize --no-action --size ''52Gi'' ''/dev/sda1''}}<br />
<br />
:If only the previous test succeeded, execute this command again, but this time without the aforementioned test flag.<br />
<br />
* Install VirtualBox on your GNU/Linux host (see [[#Installation steps for Arch Linux hosts]] if your host is Arch Linux).<br />
<br />
* Create the Windows disk image from the beginning of the drive to the end of the first partition where is located your Windows installation. Copying from the beginning of the disk is necessary because the MBR space at the beginning of the drive needs to be on the virtual drive along with the Windows partition. In this example two following partitions {{ic|sda2}} and {{ic|sda3}}will be later removed from the partition table and the MBR bootloader will be updated.<br />
<br />
:{{bc|<nowiki># sectnum=$(( $(cat /sys/block/''sda/sda1''/start) + $(cat /sys/block/''sda/sda1''/size) ))</nowiki>}}<br />
:Using {{ic|cat /sys/block/''sda/sda1''/size}} will output the number of total sectors of the first partition of the disk {{ic|sda}}. Adapt where necessary.<br />
<br />
:{{bc|<nowiki># dd if=''/dev/sda'' bs=512 count=$sectnum | VBoxManage convertfromraw stdin ''windows.vdi'' $(( $sectnum * 512 ))</nowiki>}}<br />
:We need to display the size in byte, {{ic|$(( $sectnum * 512 ))}} will convert the sector numbers to bytes.<br />
<br />
* Since you created your disk image as root, set the right ownership to the virtual disk image: {{bc|# chown ''your_user'':''your_group'' windows.vdi}}<br />
<br />
* Create your virtual machine configuration file and use the virtual disk created previously as the main virtual hard disk.<br />
<br />
* Try to boot your Windows VM, it may just work. First though remove and repair disks from the boot process as it may interfere (and likely will) booting into safe-mode.<br />
<br />
* Attempt to boot your Windows virtual machine in safe mode (press the F8 key before the Windows logo shows up)... if running into boot issues, read [[#Fix MBR and Microsoft bootloader]]. In safe-mode, drivers will be installed likely by the Windows plug-and-play detection mechanism [http://i.imgur.com/hh1RrSp.png view]. Additionally, install the VirtualBox Guest Additions via the menu ''Devices'' > ''Insert Guest Additions CD image...''. If a new disk dialog does not appear, navigate to the CD drive and start the installer manually.<br />
<br />
* You should finally have a working Windows virtual machine. Do not forget to read the [[#Known limitations]].<br />
<br />
* Performance tip: according to [http://www.virtualbox.org/manual/ch05.html#harddiskcontrollers VirtualBox manual], SATA controller has a better performance than IDE. If you can't boot Windows off virtual SATA controller right away, it is probably due to the lack of SATA drivers. Attach virtual disk to IDE controller, create an empty SATA controller and boot the VM - Windows should automatically install SATA drivers for the controller. You can then shutdown VM, detach virtual disk from IDE controller and attach it to SATA controller instead.<br />
<br />
==== Fix MBR and Microsoft bootloader ====<br />
<br />
If your Windows virtual machine refuses to boot, you may need to apply the following modifications to your virtual machine.<br />
<br />
*Boot a GNU/Live live distribution inside your virtual machine before Windows starts up.<br />
<br />
*Remove other partitions entries from the virtual disk MBR. Indeed, since we copied the MBR and only the Windows partition, the entries of the other partitions are still present in the MBR, but the partitions are not available anymore. Use {{ic|fdisk}} to achieve this for example.<br />
:{{bc|<nowiki>fdisk ''/dev/sda''<br />
Command (m for help): a<br />
Partition number (''1-3'', default ''3''): ''1''</nowiki>}}<br />
<br />
*Write the updated partition table to the disk (this will recreate the MBR) using the {{ic|m}} command inside {{ic|fdisk}}.<br />
<br />
*Use {{Pkg|testdisk}} (see [http://www.cgsecurity.org/index.html?testdisk.html here] for details) to add a generic MBR:<br />
:{{bc|# testdisk > ''Disk /dev/sda...''' > [Proceed] > [Intel] Intel/PC partition > [MBR Code] Write TestDisk MBR to first sector > Write a new copy of MBR code to first sector? (Y/n) > Y > Write a new copy of MBR code, confirm? (Y/N) > A new copy of MBR code has been written. You have to reboot for the change to take effect. > [OK]}}<br />
<br />
*With the new MBR and updated partition table, your Windows virtual machine should be able to boot. If you are still encountering issues, boot your Windows recovery disk from on of the previous step, and inside your Windows RE environment, execute the commands [http://support.microsoft.com/kb/927392 described here].<br />
<br />
==== Known limitations ====<br />
<br />
*Your virtual machine can sometimes hang and overrun your RAM, this can be caused by conflicting drivers still installed inside your Windows virtual machine. Good luck to find them!<br />
*Additional software expecting a given driver beneath may either not be disabled/uninstalled or needs to be uninstalled first as the drivers that are no longer available.<br />
*Your Windows installation must reside on the first partition for the above process to work. If this requirement is not met, the process might be achieved too, but this had not been tested. This will require either copying the MBR and editing in hexadecimal see [http://superuser.com/questions/237782/virtualbox-booting-cloned-disk/253417#253417 VirtualBox: booting cloned disk] or will require to fix the partition table [http://gparted.org/h2-fix-msdos-pt.php manually] or by repairing Windows with the recovery disk you created in a previous step. Let us consider our Windows installation on the second partition; we will copy the MBR, then the second partition where to the disk image. {{ic|VBoxManage convertfromraw}} needs the total number of bytes that will be written: calculated thanks to the size of the MBR (the start of the first partition) plus the size of the second (Windows) partition. {{ic|<nowiki>{ dd if=/dev/sda bs=512 count=$(cat /sys/block/sda/sda1/start) ; dd if=/dev/sda2 bs=512 count=$(cat /sys/block/sda/sda2/size) ; } | VBoxManage convertfromraw stdin windows.vdi $(( ($(cat /sys/block/sda/sda1/start) + $(cat /sys/block/sda/sda2/size)) * 512 ))</nowiki>}}.<br />
<br />
== Troubleshooting ==<br />
<br />
=== VERR_ACCESS_DENIED ===<br />
<br />
To access the raw vmdk image on a windows host, run the VirtualBox GUI as administrator.<br />
<br />
=== Keyboard and mouse are blocked in my virtual machine ===<br />
<br />
This means your virtual machine has captured the input of your keyboard and your mouse. Simply press the right {{ic|Ctrl}} key and your input should control your host again.<br />
<br />
To control transparently your virtual machine with your mouse going back and forth your host, without having to press any key, and thus have a seamless integration, install the guest additions inside the guest. Read from the [[#Install the Guest Additions]] step if you guest is Arch Linux, otherwise read the official VirtualBox help.<br />
<br />
=== Cannot send CTRL+ALT+Fn key to my virtual machine ===<br />
<br />
Your guest operating system is a GNU/Linux distribution and you want to open a new TTY shell by hitting {{ic|Ctrl+Alt+F2}} or exit your current X session with {{ic|Ctrl+Alt+Backspace}}. If you type these keyboard shortcuts without any adaptation, the guest will not receive any input and the host (if it is a GNU/Linux distribution too) will intercept these shortcut keys. To send {{ic|Ctrl+Alt+F2}} to the guest for example, simply hit your ''Host Key'' (usually the right {{ic|Ctrl}} key) and press {{ic|F2}} simultaneously.<br />
<br />
=== Fix ISO images problems ===<br />
<br />
While VirtualBox can mount ISO images without problem, there are some image formats which cannot reliably be converted to ISO. For instance, ccd2iso ignores .ccd and .sub files, which can give disk images with broken files. <br />
<br />
In this case, you will either have to use [[CDEmu]] for Linux inside VirtualBox or any other utility used to mount disk images.<br />
<br />
=== VirtualBox GUI does not match my GTK Theme ===<br />
<br />
See [[Uniform Look for Qt and GTK Applications]] for information about theming Qt based applications like Virtualbox.<br />
<br />
=== OpenBSD unusable when virtualisation instructions unavailable ===<br />
<br />
While OpenBSD is reported to work fine on other hypervisors without virtualisation instructions (VT-x AMD-V) enabled, an OpenBSD virtual machine running on VirtualBox without these instructions will be unusable, manifesting with a bunch of segmentation faults. Starting VirtualBox with the ''-norawr0'' argument [https://www.virtualbox.org/ticket/3947 may solve the problem]. You can do it like this:<br />
$ VBoxSDL -norawr0 -vm ''name_of_OpenBSD_VM''<br />
<br />
=== VBOX_E_INVALID_OBJECT_STATE (0x80BB0007) ===<br />
<br />
This can occur if a VM is exited ungracefully. The solution to unlock the VM is trivial:<br />
$ VBoxManage controlvm ''virtual_machine_name'' poweroff<br />
<br />
=== USB subsystem is not working on the host or guest ===<br />
<br />
Your user must be in the {{ic|vboxusers}} group, and you need to install the [[#Extension pack|extension pack]] if you want USB 2 support. Then you will be able to enable USB 2 in the VM settings and add one or several filters for the devices you want to access from the guest OS.<br />
<br />
If {{ic|VBoxManage list usbhost}} does not show any USB devices even if run as root, make sure that there is no old udev rules (from VirtualBox 4.x) in ''/etc/udev/rules.d/''. VirtualBox 5.0 installs udev rules to ''/usr/lib/udev/rules.d/''. You can use command like {{ic|pacman -Qo /usr/lib/udev/rules.d/60-vboxdrv.rules}} to determine if the udev rule file is outdated.<br />
<br />
Sometimes, on old Linux hosts, the USB subsystem is not auto-detected resulting in an error {{ic|Could not load the Host USB Proxy service: VERR_NOT_FOUND}} or in a not visible USB drive on the host, [https://bbs.archlinux.org/viewtopic.php?id=121377 even when the user is in the '''vboxusers''' group]. This problem is due to the fact that VirtualBox switched from ''usbfs'' to ''sysfs'' in version 3.0.8. If the host does not understand this change, you can revert to the old behaviour by defining the following environment variable in any file that is sourced by your shell (e.g. your {{ic|~/.bashrc}} if you are using ''bash''):<br />
<br />
{{hc|~/.bashrc|VBOX_USB<nowiki>=</nowiki>usbfs}}<br />
<br />
Then make sure, the environment has been made aware of this change (reconnect, source the file manually, launch a new shell instance or reboot).<br />
<br />
Also make sure that your user is a member of the {{ic|storage}} group.<br />
<br />
=== Failed to create the host-only network interface ===<br />
<br />
Make sure all required kernel modules are loaded. See [[#Load the VirtualBox kernel modules]].<br />
<br />
=== WinXP: Bit-depth cannot be greater than 16 ===<br />
<br />
If you are running at 16-bit color depth, then the icons may appear fuzzy/choppy. However, upon attempting to change the color depth to a higher level, the system may restrict you to a lower resolution or simply not enable you to change the depth at all. To fix this, run {{ic|regedit}} in Windows and add the following key to the Windows XP VM's registry:<br />
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]<br />
"ColorDepth"=dword:00000004<br />
<br />
Then update the color depth in the "desktop properties" window. If nothing happens, force the screen to redraw through some method (i.e. {{ic|Host+f}} to redraw/enter full screen).<br />
<br />
=== Use serial port in guest OS ===<br />
<br />
Check you permission for the serial port:<br />
$ /bin/ls -l /dev/ttyS*<br />
crw-rw---- 1 root uucp 4, 64 Feb 3 09:12 /dev/ttyS0<br />
crw-rw---- 1 root uucp 4, 65 Feb 3 09:12 /dev/ttyS1<br />
crw-rw---- 1 root uucp 4, 66 Feb 3 09:12 /dev/ttyS2<br />
crw-rw---- 1 root uucp 4, 67 Feb 3 09:12 /dev/ttyS3<br />
<br />
Add your user to the {{ic|uucp}} group.<br />
# gpasswd -a $USER uucp <br />
and log out and log in again.<br />
<br />
=== Windows 8.x Error Code 0x000000C4===<br />
<br />
If you get this error code while booting, even if you choose OS Type Win 8, try to enable the {{ic|CMPXCHG16B}} CPU instruction:<br />
<br />
$ vboxmanage setextradata ''virtual_machine_name'' VBoxInternal/CPUM/CMPXCHG16B 1<br />
<br />
=== Windows 8, 8.1 or 10 fails to install, boot or has error "ERR_DISK_FULL" ===<br />
Update the VM's settings by going to ''Settings > Storage > Controller:SATA'' and check "Use Host I/O Cache".<br />
<br />
=== Linux guests have slow/distorted audio ===<br />
<br />
The AC97 audio driver within the Linux kernel occasionally guesses the wrong clock settings when running inside Virtual Box, leading to audio that is either too slow or too fast. To fix this, create a file in {{ic|/etc/modprobe.d}} with the following line:<br />
<br />
options snd-intel8x0 ac97_clock=48000<br />
<br />
=== Guest freezes after starting Xorg ===<br />
<br />
Faulty or missing drivers may cause the guest to freeze after starting Xorg, see for example [https://bbs.archlinux.org/viewtopic.php?pid=1167838] and [https://bbs.archlinux.org/viewtopic.php?id=156079]. Try disabling 3D acceleration in ''Settings > Display'', and check if all [[Xorg]] drivers are installed.<br />
<br />
=== "NS_ERROR_FAILURE" and missing menu items ===<br />
<br />
If you encounter this message when first time starting the virtual machine:<br />
<br />
{{bc|Failed to open a session for the virtual machine debian.<br />
Could not open the medium '/home/.../VirtualBox VMs/debian/debian.qcow'.<br />
QCow: Reading the L1 table for image '/home/.../VirtualBox VMs/debian/debian.qcow' failed (VERR_EOF).<br />
VD: error VERR_EOF opening image file '/home/.../VirtualBox VMs/debian/debian.qcow' (VERR_EOF).<br />
<br />
Result Code: <br />
NS_ERROR_FAILURE (0x80004005)<br />
Component: <br />
Medium<br />
}}<br />
<br />
Exit VirtualBox, delete all files of the new machine and from virtualbox config file remove the last line in {{ic|MachineRegistry}} menu (or the offending machine you are creating):<br />
<br />
{{hc|~/.config/VirtualBox/VirtualBox.xml|2=<br />
...<br />
<MachineRegistry><br />
<MachineEntry uuid="{00000000-0000-0000-0000-000000000000}" src="/home/void/VirtualBox VMs/debian/debian.vbox"/><br />
<MachineEntry uuid="{00000000-0000-0000-0000-000000000000}" src="/home/void/VirtualBox VMs/ubuntu/ubuntu.vbox"/><br />
<strike><MachineEntry uuid="{00000000-0000-0000-0000-000000000000}" src="/home/void/VirtualBox VMs/lastvmcausingproblems/lastvmcausingproblems.qcow"/></strike><br />
</MachineRegistry><br />
...<br />
}}<br />
<br />
This happens sometimes when selecting ''QCOW''/''QCOW2''/''QED'' disk format when creating a new virutal disk.<br />
<br />
=== USB modem ===<br />
<br />
If you have a USB modem which is being used by the guest OS, killing the guest OS can cause the modem to become unusable by the host system. Killing and restarting {{ic|VBoxSVC}} should fix this problem.<br />
<br />
=== "The specified path does not exist. Check the path and then try again." error in Windows guests ===<br />
<br />
This error message often appears when running an .exe file which requires administrator priviliges from a shared folder in windows guests. See [https://www.virtualbox.org/ticket/5732 the bug report] for details.<br />
<br />
There are several workarounds:<br />
<br />
# Disable UAC from Control Panel -> Action Center -> "Change User Account Control settings" from left side pane -> set slider to "Never notify" -> OK and reboot<br />
# Copy the file from the shared folder to the guest and run from there<br />
# Control Panel -> Network and Internet -> Internet Options -> Security -> Trusted Sites -> Sites -> Add "VBOXSVR" as a website<br />
# Start -> type "gpedit.msc" and press Enter -> Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Size to Zone Assignment List -> Add "VBOXSVR" to "2" and reboot<br />
<br />
{{Accuracy|Haven't tested#3 and #4 workarounds myself. If someone can confirm that they are working as well, please delete this note/template.}}<br />
<br />
=== No 64-bit OS client options ===<br />
<br />
When launching a VM client, and no 64-bit options are available, make sure your CPU virtualization capabilities (usually named {{ic|VT-x}}) are enabled in the BIOS.<br />
<br />
=== Host OS freezes on Virtual Machine start ===<br />
<br />
{{Expansion|Needs a link to a bug report; vague expressions like "currently" and "at the moment of writing" are of no help.}}<br />
<br />
Possible causes/solutions :<br />
* SMAP<br />
This is a known incompatiblity with SMAP enabled kernels affecting (mostly) Intel Broadwell chipsets. The matter is currently being investigated, with a wide variety of WIP vboxhost module patches out in the wild that are meant to solve the issue. At the moment of writing though, the only 100% guaranteed solution to this problem is disabling SMAP support in your kernel by appending the "nosmap" option to your kernel boot command line.<br />
* Hardware Virtualisation<br />
Disabling hardware virtualisation (VT-x/AMD-V) may solve the problem.<br />
* Various Kernel bugs<br />
** Fuse mounted partitions (like ntfs) [https://bbs.archlinux.org/viewtopic.php?id=185841], [https://bugzilla.kernel.org/show_bug.cgi?id=82951#c12]<br />
<br />
Generally, such issues are observed after upgrading VirtualBox or linux kernel. Downgrading them to the previous versions of theirs might solve the problem.<br />
<br />
=== The virtual machine has terminated unexpectedly during startup with exit code 1 (0x1) ===<br />
<br />
When trying to launch a virtual machine, an error message like the following appears:<br />
<br />
{{bc|The virtual machine has terminated unexpectedly during startup with exit code 1 (0x1)<br />
NS_ERROR_FAILURE 0x80004005<br />
Component: MachineWrap<br />
Interface: IMachine}}<br />
<br />
This may occur after upgrading the {{Pkg|virtualbox}} or {{Pkg|virtualbox-host-modules}} package. Try reloading the {{ic|vboxdrv}} module:<br />
<br />
{{bc|# modprobe -r vboxdrv<br />
# modprobe vboxdrv<br />
}}<br />
<br />
=== Analog microphone not working in guest ===<br />
<br />
If the audio input from an analog microphone is working correctly on the host, but no sound seems to get through to the guest, despite the microphone device apparently being detected normally, installing a [[Sound system#Sound servers|sound server]] such as [[PulseAudio]] on the host might fix the problem.<br />
<br />
== See also ==<br />
<br />
* [https://www.virtualbox.org/manual/UserManual.html VirtualBox User Manual]<br />
* [[Wikipedia:VirtualBox]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=426004Talk:Dm-crypt2016-03-16T09:48:25Z<p>Carlduff: /* Restructuring */ That's that</p>
<hr />
<div>== New idea ==<br />
The philosophy behind the <s>current</s> old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to <s>rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in [[Dm-crypt with LUKS/draft]], so it's used</s> use the [[dm-crypt#Common scenarios]] section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:<br />
<br />
*[[dm-crypt/Encrypting a Non-Root File System]]<br />
**partition<br />
**loopback<br />
*[[dm-crypt/Encrypting an Entire System]]<br />
**plain dm-crypt (merge [[Plain dm-crypt without LUKS]], done)<br />
**dm-crypt + LUKS (no LVM)<br />
**LVM on LUKS (merge [[Encrypted LVM]], done)<br />
**LUKS on LVM (merge [[Encrypted LVM]], done)<br />
**(I think it would be really cool if we could also include an example with software RAID)<br />
<br />
Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of <s>[[Dm-crypt with LUKS]]</s> [[dm-crypt]], pointing out all the particular suggested adaptations that apply to that particular scenario.<br />
<br />
The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:08, 23 November 2013 (UTC)<br />
<br />
EDIT: since [[Plain dm-crypt without LUKS]] would be merged here, the main article should be just renamed to [[dm-crypt]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:09, 23 November 2013 (UTC)<br />
<br />
EDIT: updated for current structure. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:31, 8 December 2013 (UTC)<br />
===Scenario structure===<br />
:Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split [[dm-crypt/Encrypting an Entire System]] into a subpage for (e.g.) [[dm-crypt/Encrypting a single disk system]] and [[dm-crypt/Encrypting a system across multiple disks]] scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:11, 8 December 2013 (UTC)<br />
<br />
::Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for [[dm-crypt/Encrypting a System on Physical Devices]] and [[dm-crypt/Encrypting a System on Virtual Devices]], in fact you ''can'' use multiple physical disks in every case if you want. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:48, 9 December 2013 (UTC)<br />
::EDIT: Note that the history of [[dm-crypt/Encrypting an Entire System]] should be preserved by ''moving'' it to one of the two titles, and then (or before) splitting the other page. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 9 December 2013 (UTC)<br />
:::+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:16, 9 December 2013 (UTC)<br />
<br />
== Restructuring ==<br />
<br />
:''[Moved from [[User talk:Indigo#dm_crypt / LUKS encryption]] — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:29, 14 March 2016 (UTC)]''<br />
<br />
I'd like to propose creating a simplified "overview" article for LUKS encryption. The existing article is quite expansive and necessitates going to-and-fro a few other articles, which I personally found a bit intimidating and confusing when first learning about LUKS. Ironically, the basics are quite easy to understand once known. I am also hoping to promote the use of encryption as I am becoming ever-more security conscious (now that I know it, I can't see ever installing without LUKS).<br />
<br />
The idea is that the proposed article (e.g "LUKS Overview") would provide the instructions and information for (presumably) the most common scenarios (i.e. LUKS, LUKS on LVM, and LVM on LUKS), and will link to the more in-depth articles. I suspect there would be some repetition of information initially, but it shouldn't be a problem figuring out what articles should either provide that information or link to another that does. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 11:48, 13 March 2016 (UTC)<br />
<br />
:Hi, thanks for your sharing your idea. Well, yeah, we are aware the current [[dm-crypt]] structure is not ideal for newcomers. It arose from the need that the previous LUKS article grew out-of-proportion (Kynikos probably remembers wihout looking back, if it was even longer than the beginners' guide:) and multiple guides for different scenarios were created, which in turn outdated partly. <br />
:From what you write I am unsure though how much your idea differs from what we tried to achieve by merging the guides into the [[Dm-crypt/Encrypting an entire system]] scenario structure. Can you give an example (perhaps directly in [[Talk:Dm-crypt/Encrypting an entire system]], more visible for other users) what you would change? Perhaps we can work out something. Tnanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:06, 13 March 2016 (UTC)<br />
<br />
::I don't like the idea of another overview article, we already have [[Dm-crypt/Encrypting an entire system]], and a new article would necessarily duplicate/overlap with it, so really let's find another solution.<br />
::What I think we could do, and that's something that I'd been thinking recently already, is to further slim [[Dm-crypt/Encrypting an entire system]] down, ideally reducing each of its sections to a simple sequence of commands, with only short descriptions and mainly links to where the detailed information is. See [[#Draft]] for an example, but I'm sure it can be simplified even further.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:54, 14 March 2016 (UTC)<br />
<br />
::: I've added a rough draft to my [[User_talk:Carlduff|talk page]]. It covers all main LUKS/LVM scenarios, as well as encrypting an entire system or individual partitions. The idea is that this simple overview could act as a "hub" for more detailed articles (thus replacing [[Dm-crypt/Encrypting an entire system]]). I've not added the links as the draft is just to give an idea. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 21:37, 14 March 2016 (UTC) <br />
<br />
::::I see, but that's exactly what I was saying we can't accept: just like with the [[Beginners' guide]] (which is under [[Talk:Beginners' guide#Unification|unification]] right because of this), your draft is only an arbitrary selection (i.e. duplication) of the information found in the other [[dm-crypt]] subpages, which will mean that people will read that instead of the other articles, just because it's shorter, and they will start adding info to it instead of the other pages, so in the medium term we'll end up with a long, unorganized article and the other subpages with outdated content, and the need to merge everything together once again, and restart the cycle.<br />
::::I understand you've just read and understood the dm-crypt articles, and now want to write your own summary notes just like when studying some subject on a text book, but we can't do that here. If you want to keep a personal collection of the most important parts of dm-crypt configuration, you can create a subpage of your User page and write there what you feel is most important.<br />
::::The goal of [[Dm-crypt/Encrypting an entire system]], which you aim to replace, is very different: it uses some particular real-world scenarios to show how the information from the other subpages can be combined together and put into practice, without entering any more details than strictly necessary. Your draft instead tries to generalize and present a one-size-fits-all set of instructions, which is why I'm saying it duplicates the other subpages, which are the ones aimed at explaining the general information.<br />
::::By the way, in your draft there are also several inaccuracies, for example securely wiping a device before encrypting it is always strongly recommended; encrypted partitions ''can'' be seen by lsblk without "unlocking" them; setting up an encrypted boot partition with GRUB is ''not'' "problematic"; if you leave your unencrypted boot partition on the hdd, the consequences can be much worse than leaking "the name of an encrypted partition" (the initramfs or kernel can be tampered, for example). And this is only until the first paragraph of the second section, I don't want to spend too much time at reviewing a draft that's not going to be merged :)<br />
::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:07, 16 March 2016 (UTC)<br />
<br />
:::::Hm, how to sum it up from my side ;) In general I agree with Kynikos on your draft, Carlduff. Take aside some inaccuracies in its draft from, you have put a lot of effort to explain the topic in a simpler, easier to grasp way. And it works, but it does go much further than the [[Dm-crypt/Encrypting an entire system]] scenario article. The simplifications you make for that, some good some bad in my view, will lead to other editors trying to fix them, to get it more accurate. Just one example: <br />
:::::Your description of the LUKS on LVM scenario is half-baked. It makes absolutely no sense to add it like you do. You neither explain a reason why to use it, nor do you mention the special/difficult part about it - how does one handle any additional logical volumes? You only handle the lv-root - for that one does not need an lvm at all.<br />
:::::Overall your approach works well didactively, but i really think it is mostly due to simplifications. I am not convinced the majority of readers would find it easier to follow. For the sections you melt the scenarios together. Yes, it explains more that way why cryptdevice= this or that, but is that easier to follow if you want to install? In my view the table of scenario pros/cons at the beginning (readers decide which scenario best suits their case to base on), followed by a repetitive structure for each of the scenario's in the existing article is didactively better. <br />
:::::Kynikos' shot at reworking the scenario (below) shortens an existing to the more essential steps. So, your two drafts are not comparable anyhow. Still, comparing his to the existing scenario, most of the shortening appears to be elimination of subsection headers, plus a few sentences. Leaving sentences out like the last one "The <device-UUID> refers to the UUID of /dev/sdaX, see Persistent block device naming for details. " does not make it easier IMO. The suggestion to add partitioning steps would likely expand it to the same size we have, as well as duplicate partitioning info. So, I am not sure what we gain from it. I think it is more a case of personal preference whether a reader prefers a snappy, command-based scenario example or not. I'd say it requires more experience to transform the info from a shorter command-based summary form into the own real world use-case, than it does with a sentence/crosslink more here and there. <br />
:::::All that said, I have no better idea than both of you. It would be easier if we accept more duplication again, in the sense of the beginners' guide for dm-crypt, but that's no option really. ''Perhaps'' the different scenarios could be approached differently, i.e. the first (now the "simple") scenario even more step-by-step and linked into the beginners' guide, the other scenarios shorter. The problem I see with that is that the later scenarios are the more complicated anyhow. Maybe such would make more sense, if the [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] scenario is switched to the top. It is slightly more difficult to set-up, yet probably the scenario most users need (for its LVM flexibility). <br />
:::::Well, that's my thoughts on it in short form :D If one of you wants to have a go at re-working an existing scenario to see how it works out, all fine with me. Yet, from all options we consider until now, I'd personally prefer if we stick to the status quo and put efforts into eliminating missing gaps (expansion/acc templates, etc.) rather than re-shuffle the existing into a new construction area. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:10, 16 March 2016 (UTC)<br />
:::::: Well, it was just a draft, and would be a bit "half-baked" in places as it was essentially written in one go. Again, the intention was to provide a ''generalised'' hub that would link to existing - more detailed - articles. Anyway, it seems major revisions - especially for popular articles - should be left to the mods/maintainers.<br />
:::::: '''Kynikos''', I would consider myself lucky if I knew as much as you and the other mods/maintainers here had forgotten. You also make good points. However, rather than (perhaps unintentionally) coming across as belittling and brash, '''Indigo's''' approach of constructive criticism combined with encouragement will likely benefit Arch much more in the long run. Otherwise, if you believe the existing team can cope with the workload here and therefore aren't concerned with new - regular - contributors, then good luck to you :) [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 09:48, 16 March 2016 (UTC)<br />
<br />
=== Draft ===<br />
<br />
''' Simple partition layout with LUKS '''<br />
<br />
This example covers a full system encryption with ''dmcrypt'' + LUKS in a simple partition layout:<br />
<br />
+--------------------+--------------------------+--------------------------+<br />
|Boot partition |LUKS encrypted system |Optional free space |<br />
| |partition |for additional partitions |<br />
|/dev/sdaY |/dev/sdaX |or swap to be setup later |<br />
+--------------------+--------------------------+--------------------------+<br />
<br />
Follow [[Dm-crypt/Drive preparation]].<br />
<br />
Create the needed partitions, see [[Partitioning]].<br />
{{Comment|We could write the needed partitioning commands here.}}<br />
<br />
Create the encrypted root device and mount its file system, see [[Dm-crypt/Encrypting a non-root file system#Partition]] and optionally [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode]]:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdaX<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mkfs -t ext4 /dev/mapper/cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
Check the mapping works as intended:<br />
# umount /mnt<br />
# cryptsetup close cryptroot<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
Repeat for the other partitions, ''except'' for {{ic|/boot}}, see [[Dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
{{Comment|We could write the needed partitioning commands here.}}<br />
<br />
Use keyfiles to open the additional partitions at boot, see [[Dm-crypt/Device encryption#Using LUKS to Format Partitions with a Keyfile]].<br />
{{Comment|We could write the needed commands here.}}<br />
<br />
Setup is a non-encrypted {{ic|/boot}} partition. For a standard [[EFI|MBR/non-EFI]] {{ic|/boot}} partition, for example, execute:<br />
# mkfs -t ext4 /dev/sdaY<br />
# mkdir /mnt/boot<br />
# mount -t ext4 /dev/sdaY /mnt/boot<br />
<br />
At [[Installation guide#Mount the partitions]] mount the mapped devices, not the actual partitions. {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
At the mkinitcpio step, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]], see [[dm-crypt/System configuration#mkinitcpio]]:<br />
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' ... filesystems ..."}}<br />
<br />
At the boot loader step, pass the following kernel parameters, see [[Dm-crypt/System configuration#Boot loader]]:<br />
<br />
cryptdevice=UUID=''<device-UUID>'':cryptroot root=/dev/mapper/cryptroot</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425974User talk:Carlduff2016-03-16T08:34:55Z<p>Carlduff: Blanked the page</p>
<hr />
<div></div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425813User talk:Carlduff2016-03-14T22:34:19Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition or logical volume>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, {{ic|crypthome}} can be used for an encrypted {{ic|/home}}, and {{ic|cryptswap}} can be used for an encrypted swap space.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki></dev/partition name>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume name>:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425809User talk:Carlduff2016-03-14T22:01:42Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition or logical volume>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, {{ic|crypthome}} can be used for an encrypted {{ic|/home}}, and {{ic|cryptswap}} can be used for an encrypted swap space.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki></dev/partition name>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume name>:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425808User talk:Carlduff2016-03-14T22:01:25Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition or logical volume>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, {{ic|crypthome}} can be used for an encrypted {{ic|/home}}, and {{ic|cryptswap}} can be used for an encrypted swap space.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki></dev/partition name:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume name:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425807User talk:Carlduff2016-03-14T21:59:33Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition or logical volume>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, {{ic|crypthome}} can be used for an encrypted {{ic|/home}}, and {{ic|cryptswap}} can be used for an encrypted swap space.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki></dev/partition:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425805User talk:Carlduff2016-03-14T21:55:48Z<p>Carlduff: /* Opening an encrypted partition or logical volume */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition or logical volume>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, {{ic|crypthome}} can be used for an encrypted {{ic|/home}}, and {{ic|cryptswap}} can be used for an encrypted swap space.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425804User talk:Carlduff2016-03-14T21:53:53Z<p>Carlduff: /* Optionally setting the cipher and key size */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked and opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425803User talk:Carlduff2016-03-14T21:50:23Z<p>Carlduff: /* Partitioning */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended if encrypting root as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425802User talk:Carlduff2016-03-14T21:45:49Z<p>Carlduff: /* Encrypted Root */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425801User talk:Carlduff2016-03-14T21:38:59Z<p>Carlduff: /* Overview */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425800User talk:Carlduff2016-03-14T21:38:01Z<p>Carlduff: /* Overview */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=425799Talk:Dm-crypt2016-03-14T21:37:44Z<p>Carlduff: /* Restructuring */ Proposed new draft</p>
<hr />
<div>== New idea ==<br />
The philosophy behind the <s>current</s> old structure was to try to generalize the various steps for encrypting an entire system or a device and managing it, however we've noticed it's kind of hard. A new idea for reducing duplication of content while maintaining, if not improving, readability, would be to <s>rename the "/Examples" subpage to "/Common Scenarios" and move it to first place in [[Dm-crypt with LUKS/draft]], so it's used</s> use the [[dm-crypt#Common scenarios]] section as the starting point by the readers. It should contain the most common uses for encryption, which IMO are:<br />
<br />
*[[dm-crypt/Encrypting a Non-Root File System]]<br />
**partition<br />
**loopback<br />
*[[dm-crypt/Encrypting an Entire System]]<br />
**plain dm-crypt (merge [[Plain dm-crypt without LUKS]], done)<br />
**dm-crypt + LUKS (no LVM)<br />
**LVM on LUKS (merge [[Encrypted LVM]], done)<br />
**LUKS on LVM (merge [[Encrypted LVM]], done)<br />
**(I think it would be really cool if we could also include an example with software RAID)<br />
<br />
Each of those scenarios should be mostly a stripped sequence of commands with short descriptions that should link to generic sections in the other subpages of <s>[[Dm-crypt with LUKS]]</s> [[dm-crypt]], pointing out all the particular suggested adaptations that apply to that particular scenario.<br />
<br />
The idea is quite clear in my mind, I hope I've managed to explain it well enough, I'll try to put it into practice and see if it raises major problems.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:08, 23 November 2013 (UTC)<br />
<br />
EDIT: since [[Plain dm-crypt without LUKS]] would be merged here, the main article should be just renamed to [[dm-crypt]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:09, 23 November 2013 (UTC)<br />
<br />
EDIT: updated for current structure. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:31, 8 December 2013 (UTC)<br />
===Scenario structure===<br />
:Plenty of stuff to do, yet: Taking for granted we want an additional example with RAID sometime, it might be worth considering to split [[dm-crypt/Encrypting an Entire System]] into a subpage for (e.g.) [[dm-crypt/Encrypting a single disk system]] and [[dm-crypt/Encrypting a system across multiple disks]] scenarios. The latter covering "LUKS on LVM" and said RAID. Main reason: page length. If you agree, let's better do it now. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:11, 8 December 2013 (UTC)<br />
<br />
::Not a bad idea at all! However IMHO the proposed titles are a bit misleading: I would go for [[dm-crypt/Encrypting a System on Physical Devices]] and [[dm-crypt/Encrypting a System on Virtual Devices]], in fact you ''can'' use multiple physical disks in every case if you want. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:48, 9 December 2013 (UTC)<br />
::EDIT: Note that the history of [[dm-crypt/Encrypting an Entire System]] should be preserved by ''moving'' it to one of the two titles, and then (or before) splitting the other page. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 9 December 2013 (UTC)<br />
:::+1 to your edit, I learned that from watching. The one letdown of this whole fun exercise is that the wiki engine does not seem to support basic content splits and joins preserving history. Anyhow, we might as well just keep it in mind and consider splitting it later (when there is something about RAID). Funnily, I find the use of "physical" (all blockdevices are on one) and "virtual" (suggests a qcow device) as differentiator not totally clear too. Let's meditate over it again until someone has another snappy idea. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:16, 9 December 2013 (UTC)<br />
<br />
==<s> Backup/Restore LUKS headers </s>==<br />
If I were to put that somewhere, which specific page would you all suggest? I'm just talking about how to backup and restore a LUKS header, why that's important, etc. I find [https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/ this article] very helpful, and some of that info might be appropriate somewhere. Thoughts? [[User:Rdeckard|Rdeckard]] ([[User talk:Rdeckard|talk]]) 02:07, 14 February 2016 (UTC)<br />
<br />
:There's already [[Dm-crypt/Device_encryption#Backup_and_restore]], you can expand that if you want :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:33, 14 February 2016 (UTC)<br />
<br />
::Ah, I just couldn't find it. Thanks! [[User:Rdeckard|Rdeckard]] ([[User talk:Rdeckard|talk]]) 13:49, 14 February 2016 (UTC)<br />
<br />
== Restructuring ==<br />
<br />
:''[Moved from [[User talk:Indigo#dm_crypt / LUKS encryption]] — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:29, 14 March 2016 (UTC)]''<br />
<br />
I'd like to propose creating a simplified "overview" article for LUKS encryption. The existing article is quite expansive and necessitates going to-and-fro a few other articles, which I personally found a bit intimidating and confusing when first learning about LUKS. Ironically, the basics are quite easy to understand once known. I am also hoping to promote the use of encryption as I am becoming ever-more security conscious (now that I know it, I can't see ever installing without LUKS).<br />
<br />
The idea is that the proposed article (e.g "LUKS Overview") would provide the instructions and information for (presumably) the most common scenarios (i.e. LUKS, LUKS on LVM, and LVM on LUKS), and will link to the more in-depth articles. I suspect there would be some repetition of information initially, but it shouldn't be a problem figuring out what articles should either provide that information or link to another that does. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 11:48, 13 March 2016 (UTC)<br />
<br />
:Hi, thanks for your sharing your idea. Well, yeah, we are aware the current [[dm-crypt]] structure is not ideal for newcomers. It arose from the need that the previous LUKS article grew out-of-proportion (Kynikos probably remembers wihout looking back, if it was even longer than the beginners' guide:) and multiple guides for different scenarios were created, which in turn outdated partly. <br />
:From what you write I am unsure though how much your idea differs from what we tried to achieve by merging the guides into the [[Dm-crypt/Encrypting an entire system]] scenario structure. Can you give an example (perhaps directly in [[Talk:Dm-crypt/Encrypting an entire system]], more visible for other users) what you would change? Perhaps we can work out something. Tnanks. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:06, 13 March 2016 (UTC)<br />
<br />
::I don't like the idea of another overview article, we already have [[Dm-crypt/Encrypting an entire system]], and a new article would necessarily duplicate/overlap with it, so really let's find another solution.<br />
::What I think we could do, and that's something that I'd been thinking recently already, is to further slim [[Dm-crypt/Encrypting an entire system]] down, ideally reducing each of its sections to a simple sequence of commands, with only short descriptions and mainly links to where the detailed information is. See [[#Draft]] for an example, but I'm sure it can be simplified even further.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:54, 14 March 2016 (UTC)<br />
::: I've added a rough draft to my [[User_talk:Carlduff|talk page]]. It covers all main LUKS/LVM scenarios, as well as encrypting an entire system or individual partitions. The idea is that this simple overview could act as a "hub" for more detailed articles (thus replacing [[Dm-crypt/Encrypting an entire system]]). I've not added the links as the draft is just to give an idea. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 21:37, 14 March 2016 (UTC) <br />
<br />
<br />
=== Draft ===<br />
<br />
''' Simple partition layout with LUKS '''<br />
<br />
This example covers a full system encryption with ''dmcrypt'' + LUKS in a simple partition layout:<br />
<br />
+--------------------+--------------------------+--------------------------+<br />
|Boot partition |LUKS encrypted system |Optional free space |<br />
| |partition |for additional partitions |<br />
|/dev/sdaY |/dev/sdaX |or swap to be setup later |<br />
+--------------------+--------------------------+--------------------------+<br />
<br />
Follow [[Dm-crypt/Drive preparation]].<br />
<br />
Create the needed partitions, see [[Partitioning]].<br />
{{Comment|We could write the needed partitioning commands here.}}<br />
<br />
Create the encrypted root device and mount its file system, see [[Dm-crypt/Encrypting a non-root file system#Partition]] and optionally [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode]]:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdaX<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mkfs -t ext4 /dev/mapper/cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
Check the mapping works as intended:<br />
# umount /mnt<br />
# cryptsetup close cryptroot<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
Repeat for the other partitions, ''except'' for {{ic|/boot}}, see [[Dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
{{Comment|We could write the needed partitioning commands here.}}<br />
<br />
Use keyfiles to open the additional partitions at boot, see [[Dm-crypt/Device encryption#Using LUKS to Format Partitions with a Keyfile]].<br />
{{Comment|We could write the needed commands here.}}<br />
<br />
Setup is a non-encrypted {{ic|/boot}} partition. For a standard [[EFI|MBR/non-EFI]] {{ic|/boot}} partition, for example, execute:<br />
# mkfs -t ext4 /dev/sdaY<br />
# mkdir /mnt/boot<br />
# mount -t ext4 /dev/sdaY /mnt/boot<br />
<br />
At [[Installation guide#Mount the partitions]] mount the mapped devices, not the actual partitions. {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
At the mkinitcpio step, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]], see [[dm-crypt/System configuration#mkinitcpio]]:<br />
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' ... filesystems ..."}}<br />
<br />
At the boot loader step, pass the following kernel parameters, see [[Dm-crypt/System configuration#Boot loader]]:<br />
<br />
cryptdevice=UUID=''<device-UUID>'':cryptroot root=/dev/mapper/cryptroot</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425798User talk:Carlduff2016-03-14T21:33:02Z<p>Carlduff: </p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.<br />
<br />
== Other considerations ==<br />
For the security conscious, a wealth of other useful options are also available. See [[Security]]. These include:<br />
<br />
* The {{pkg|linux-grsec}} kernel<br />
* Using a [[Firewalls|firewall]]<br />
* Amending [[systemd]] to disable coredumps and [[Security#Restricting_access_to_kernel_logs|restrict access to kernel logs]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425797User talk:Carlduff2016-03-14T21:04:27Z<p>Carlduff: /* Overview */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
{{Tip| The hard disk to be encrypted may optionally be [[Securely_wipe_disk|securely wiped]] prior to encryption.}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425796User talk:Carlduff2016-03-14T20:58:32Z<p>Carlduff: /* mkinitcpio */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition. If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425795User talk:Carlduff2016-03-14T20:57:53Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using:<br />
<br />
* The partition name or label (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425794User talk:Carlduff2016-03-14T20:57:01Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using<br />
<br />
* The partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}), or <br />
* The persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}})<br />
<br />
will be fine. Using a UUID for the underlying partition is recommended. LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425793User talk:Carlduff2016-03-14T20:55:29Z<p>Carlduff: /* mkinitcpio */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mkinitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425792User talk:Carlduff2016-03-14T20:55:14Z<p>Carlduff: /* mkinitcpio */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[Mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425791User talk:Carlduff2016-03-14T20:54:06Z<p>Carlduff: /* Bootloader Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425790User talk:Carlduff2016-03-14T20:53:28Z<p>Carlduff: /* LVM on LUKS */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume {{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances, as the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425789User talk:Carlduff2016-03-14T20:52:33Z<p>Carlduff: /* System Configuration */</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume{{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances, as the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425788User talk:Carlduff2016-03-14T20:42:40Z<p>Carlduff: /* Opening an encrypted partition or logical volume */ add tip</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
{{tip| Using a clear naming convention will make life much easier when formatting and mounting.}}<br />
<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume{{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances, the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Carlduff&diff=425787User talk:Carlduff2016-03-14T20:41:06Z<p>Carlduff: draft for luks overview</p>
<hr />
<div>== Overview ==<br />
{{Warning|It is not recommended to use a keyfile to automatically unlock your encrypted system when booting. This is like using a safe to protect your valuables, only to set it up so that the door automatically unlocks and opens for anyone who approaches it!}}<br />
<br />
It is impossible to boot an encrypted system without the use of a password (or keyfile). Furthermore, encrypted partitions or logical volumes cannot even be seen (e.g. using the {{ic|lsblk}} command) or mounted without first being unlocked. Encryption is therefore ideal to prevent unauthorised access to your system and personal data, '''especially if using a laptop'''. A password-protected display manager is no substitute. This article concerns the standard and most-common [[LUKS]] (Linux Unified Key Setup) encryption method, which but also provides secure management of multiple user passwords.<br />
<br />
=== Partitioning ===<br />
A separate - unencrypted - {{ic|/boot}} partition is recommended as not all bootloaders support booting from an encrypted partition. [[GRUB#Boot_partition|Grub]] is an exception, although this can still be problematic to set up. Fortunately, the best an attacker could achieve from accessing {{ic|/boot}} is finding out the name of an encrypted partition (e.g. root), which will still be useless without a password.<br />
<br />
Although some users only encrypt a separate {{ic|/home}} partition to protect personal files, it is recommended to also encrypt the root. This is because sensitive information - including passwords - can still be gleaned from the root (e.g. via coredumps or unprotected systemd logs). However, the use of separate encrypted root and {{ic|/home}} partitions may be inconvenient as every encrypted partition requires its own password to unlock, even if the same password is used for them. In this instance, it will be necessary to enter two passwords every time when booting.<br />
<br />
Logical Volume Management (LVM) can however be used on a single encrypted partition (LVM on LUKS) to create separate Logical Volumes ("virtual partitions") for root, {{ic|/home}}, and optionally {{ic|swap}}.<br />
<br />
=== Encryption Scenarios ===<br />
There are three basic encryption scenarios: LUKS alone, LVM on LUKS, and LUKS on LVM.<br />
<br />
* '''LUKS alone''': The easiest and simplist option. The most basic setup is to use an unencypted partition for {{ic|/boot}} and an encrypted partition for root (protecting both system and personal files). A swap file (rather than a partition) can be optionally used, which will also be encrypted due to being located in the root partition.<br />
<br />
* '''LVM on LUKS''' The process of using LVM on an encrypted partition is virtually identical to using LVM on an unencrypted partition. All logical volumes on a single encrypted partition will themselves be encrypted - including swap - and will all be unlocked with the same password (which need be only entered once when booting). This scenario affords all the extra benefits of LVM, such as the ease of resizing logical volumes if necessary, compared to the difficulty of resizing separate encrypted partitions.<br />
<br />
* '''LUKS on LVM''' The process for this less common scenario is virtually identical to LUKS alone, except that one or more logical volumes are encrypted instead of one or more partitions. However, as explained below, the bootloader must be configured slighly differently than for LUKS alone or LVM on LUKS.<br />
<br />
== Encrypting a partition or logical volume ==<br />
{{Tip|When setting a password for encryption, it should not: <br />
* Be the same as the user and/or root account passwords<br />
* Be too obvious or easy to guess<br />
* Be easy to forget!}}<br />
<br />
The process of encryption is essentially identical whatever the scenario. The syntax of the command to use the default LUKS encryption settings is:<br />
<br />
# cryptsetup luksFormat <partition or logical volume> <br />
<br />
It will be necessary to set a password when prompted. For example, to encrypt a partition (in this instance {{ic|/dev/sda2}}) for LUKS alone or to prepare the partition for LVM on LUKS:<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
<br />
To encrypt a logical volume (in this instance {{ic|/dev/mapper/vg01-lvolroot}}) for LUKS on LVM:<br />
<br />
# cryptsetup luksFormat /dev/mapper/vg01-lvolroot<br />
<br />
=== Optionally setting the cipher and key size ===<br />
Optionally, the {{ic|cipher}} (what encryption algorithm to use) and the LUKS {{ic|key size}} (where the passwords are stored) may also be set. The syntax of the command to optionally set the cipher and key size is:<br />
<br />
# cryptsetup -s <key size> -c <encryption algorithm> luksFormat <partition or logical volume> <br />
<br />
For example, to use a keysize of {{ic|512}} and the {{ic|aes-xts-plain64}} algorithm on the partition {{ic|/dev/sda2}}:<br />
<br />
# cryptsetup luksFormat -s 512 -c aes-xts-plain64 /dev/sda2<br />
<br />
Once encrypted, the partition or logical volume must then be unlocked opened in order to use it. This includes where intending to subsequently format with a file system and then mount to install Arch.<br />
<br />
== Opening an encrypted partition or logical volume ==<br />
Where opening a partition or logical volume for the first time after encyption, this step will also set the '''encryption name''' for it. In principle, this is the same as setting a name for a logical volume. Although you are free to set whatever name you wish, it is recommended to use the {{ic|crypt<name of partition>}} convention. For example, {{ic|cryptroot}} can be used for an encrypted root, and/or {{ic|crypthome}} can be used for a separate encrypted {{ic|/home}} partition. '''This will make life much easier when formatting and mounting''', as shown below.<br />
<br />
The syntax of the command to open an encrypted partition is:<br />
<br />
# cryptsetup open <partition or logical volume> <encryption name><br />
<br />
It will be necessary to enter the password previously set when prompted. For example, where {{ic|/dev/sda2}} has been encrypted, to open it, set and subsequently use the encryption name {{ic|cryptroot}} for it:<br />
<br />
# cryptsetup open /dev/sda2 cryptroot<br />
<br />
This also applies where using LVM on LUKS (e.g. unlock the underlying partition to also unlock and access the logical volumes created on it). Otherwise, where encrypting a logical volume (LUKS on LVM), an example where the volume group is {{ic|vg01}} and the encrypted logical volume is {{ic|lvolroot}}:<br />
<br />
# cryptsetup open /dev/mapper/vg01-lvolroot cryptroot<br />
<br />
Once opened, the encrypted partition or logical volume may then used.<br />
<br />
== Using an encrypted partition or logical volume ==<br />
Using an unlocked encrypted partition or logical volume is essentially the same as using an unecrypted one. The difference is the name used when using LVM, formatting, and/or mounting. In essence, it is necessary to specify the "top" layer of an encrypted partition or logical volume for use (highlighted in bold), not anything underlying it.<br />
<br />
{{hc|LUKS alone|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LUKS on LVM|<br />
<br />
'''1. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})'''<br />
<br />
2. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
{{hc|LVM on LUKS|<br />
<br />
'''1. [LVM layer] (e.g. {{ic|/dev/mapper/vg01-lvolroot}})'''<br />
<br />
2. [encryption layer] (e.g. {{ic|/dev/mapper/cryptroot}})<br />
<br />
3. [partition] (e.g. {{ic|/dev/sda2}})}}<br />
<br />
=== LUKS alone and LUKS on LVM ===<br />
In both these instances, {{ic|/dev/mapper/<encryption name>}} must be used for formatting and mounting, not the underlying LVM layer and/or partition. For example, where a partition (e.g. {{ic|/dev/sda2}}) or logical volume (e.g. {{ic|/dev/mapper/vg01-lvolroot}}) has been encrypted as {{ic|cryptroot}}, the following commands will format either of them with the {{ic|ext4}} file system and mount as root:<br />
<br />
# mkfs.ext4 /dev/mapper/cryptroot<br />
# mount /dev/mapper/cryptroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
=== LVM on LUKS ===<br />
The process is virtually identical to using LVM on an unencrypted partition. The difference is that rather than using the actual encrypted partition name (e.g. {{ic|/dev/sda2}}) to create a volume group and logical volumes, {{ic|/dev/mapper/<encryption name>}} is used instead. For example, where {{ic|/dev/sda2}} has been encrypted as {{ic|cryptroot}}, the command to create the volume group {{ic|vg01}} on it would be:<br />
<br />
# vgcreate vg01 /dev/mapper/cryptroot<br />
<br />
The process of creating logical volumes, formatting, and mounting is otherwise identical to using LVM on an unencrypted partition (e.g. {{ic|/dev/mapper/<volumegroup>-<logical volume>}}). For example, to format and mount the logical volume{{ic|vg01-lvolroot}} in this instance:<br />
<br />
# mkfs.ext4 /dev/mapper/vg01-lvolroot<br />
# mount /dev/mapper/vg01-lvolroot /mnt<br />
<br />
The unencrypted partition for {{ic|/boot}} (in this instance {{ic|/dev/sda1}} for a BIOS system) would be formatted and mounted as standard:<br />
<br />
# mkfs.ext2 /dev/sda1<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
== System Configuration ==<br />
{{Warning|A failure to properly configure your system <u>will</u> result in an unbootable installation.}}<br />
<br />
It will be necessary to configure your chosen [[Boot_loaders|boot loader]] for LUKS. If using an encrypted root, [[mkinitcpio]] must be configured as well.<br />
<br />
=== Bootloader Configuration ===<br />
It will be necessity to add the {{ic|cryptdevice<nowiki>=</nowiki>}} declaration to your bootloader for each encrypted partition or logical volume. The syntax of this declaration is:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|cryptdevice<nowiki>=</nowiki><partition>:<encryption name>}}<br />
* LUKS on LVM: {{ic|cryptdevice<nowiki>=</nowiki></dev/mapper/logical volume:<encryption name>}}<br />
<br />
LUKS alone and LVM on LUKS use the same syntax as in both instances, the encryption layer sits directly on the underlying partition. For example, where the underlying partition is {{ic|/dev/sda2}} and the encryption name is {{ic|cryptroot}}, using the partition name (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/sda2:cryptroot}}) or the persistent partition UUID (e.g. {{ic|cryptdevice<nowiki>=</nowiki>UUID<nowiki>=</nowiki><UUID of /dev/sda2>:cryptroot}}) will be fine. Using a UUID for the underlying partition is recommended.<br />
<br />
LUKS on LVM requires a different syntax because the encryption layer sits on an underlying LVM layer, not the partition. As such, it is necessary to specify the relevant logical volume encrypted instead. For example, where the underlying logical volume is {{ic|vg01-lvolroot}} and the encryption name is {{ic|cryptroot}}, using the logical volume name is necessary (e.g. {{ic|cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot}}).<br />
<br />
==== Encrypted Root ====<br />
Bootloaders other than [[Grub]] such as [[Syslinux]] and [[systemd-boot]] need to be manually configured to declare the root partition or logical volume. The process is exactly the same as for non-encrypted partitions or logical volumes used as root. In other words, whatever was specified as root when mounting is specified in the {{ic|root<nowiki>=</nowiki>}} declaration for the bootloader.<br />
<br />
For example, where {{ic|/dev/mapper/<encryption name>}} was mounted as root (LUKS alone or LUKS on LVM), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<encryption name>}}. Where {{ic|/dev/mapper/<logical volume name>}} was mounted as root (LVM alone or LVM on LUKS), the declaration would be {{ic|root<nowiki>=</nowiki></dev/mapper/<logical volume name>}}. The examples below utilise the partition name, encryption name, and/or the logical volume name as given above:<br />
<br />
* LUKS alone or LVM on LUKS: {{ic|root<nowiki>=</nowiki>/dev/mapper/cryptroot cryptdevice<nowiki>=</nowiki>"/dev/sda2:cryptroot" rw}}<br />
* LUKS on LVM: {{ic|root<nowiki>=</nowiki>/dev/mapper/vg01-lvolroot cryptdevice<nowiki>=</nowiki>/dev/mapper/lvolroot:cryptroot rw}}<br />
<br />
=== mkinitcpio ===<br />
[[mknitcpio]] needs only to be configured if using an encrypted root partition.<br />
<br />
If using LUKs alone, the {{ic|encrypt}} hook must be added before the {{ic|filesystems}} hook in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt''' filesystems keyboard fsck"}}<br />
<br />
If using LVM on LUKS or LUKS on LVM, the {{ic|lvm2}} hook must also be added, again before the {{ic|filesystems}} hook:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
HOOKS<nowiki>=</nowiki>"base udev autodetect modconf block '''encrypt lvm2''' filesystems keyboard fsck"}}<br />
<br />
Then run mkinitcpio to regenerate your initramfs.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User_talk:Indigo&diff=425626User talk:Indigo2016-03-13T11:48:37Z<p>Carlduff: Couple of proposals</p>
<hr />
<div>Feel free to leave comments about my wiki edits or other points of interest. Please note I have changed preferences so that the account does not automatically watch articles I edit. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 23:31, 1 August 2015 (UTC)<br />
<br />
== Comments ==<br />
<br />
===<s> Samba automount</s> ===<br />
<br />
''Hi Francoism, I moved this to [[Talk:Samba#Samba_automount]] so that other users interested in the [[Samba]] article can participate.'' <br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:13, 2 March 2016 (UTC)<br />
<br />
=== <s>dd block size</s> ===<br />
<br />
Please see: https://wiki.archlinux.org/index.php/Talk:Dm-crypt/Drive_preparation [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 20:14, 11 December 2015 (UTC)<br />
<br />
:Hi, sorry for late replying, I see your item only now. Maybe the first bullet of the note is wrong or outdated. The template you put linked to the talk/bbs thread is just fine in my view. I will contribute there when I look into the subject again, though I only ever saw performance differences ~10% anyway myself. Thanks for the extra notice here! --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:41, 24 December 2015 (UTC)<br />
:In case you are watching this: I contributed to above accordingly. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:13, 12 January 2016 (UTC)<br />
<br />
=== dm_crypt / LUKS encryption ===<br />
Hi Indigo,<br />
<br />
Re: https://wiki.archlinux.org/index.php/Dm-crypt<br />
<br />
I'd like to propose creating a simplified "overview" article for LUKS encryption. The existing article is quite expansive and necessitates going to-and-fro a few other articles, which I personally found a bit intimidating and confusing when first learning about LUKS. Ironically, the basics are quite easy to understand once known. I am also hoping to promote the use of encryption as I am becoming ever-more security conscious (now that I know it, I can't see ever installing without LUKS).<br />
<br />
The idea is that the proposed article (e.g "LUKS Overview") would provide the instructions and information for (presumably) the most common scenarios (i.e. LUKS, LUKS on LVM, and LVM on LUKS), and will link to the more in-depth articles. I suspect there would be some repetition of information initially, but it shouldn't be a problem figuring out what articles should either provide that information or link to another that does. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 11:48, 13 March 2016 (UTC)<br />
<br />
=== Partitioning ===<br />
<br />
Not sure if this fits with the Arch wiki ethos, but I'd like to revise the [[Partitioning]] article to more clearly explain the principles behind it. I suspect the reason so many new users find this aspect so intimidating is because they don't understand what is really is or why it should be used. Another option is to create a separate "Partitioning Overview" article that the existing one can link to. I already have a lot of stuff written for a manual I'm putting together, but I think it would benefit more people on the Arch wiki. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 11:48, 13 March 2016 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Traditional_compilation&diff=425622Talk:Kernel/Traditional compilation2016-03-13T11:19:10Z<p>Carlduff: /* Keeping this article */ Response to Indigo</p>
<hr />
<div>== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)<br />
:Only if you don't invoke the default <code>make</code> target, or otherwise modified the makefile. See <code>make help</code>. Maybe we could note that this article infers "vanilla" sources, per instructions. If you want to add a section for patching, and how this may modify the instructions, go for it. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:44, 25 February 2014 (UTC)<br />
<br />
== Missing 'make bzImage' command ==<br />
This step is also required, otherwise there will be no bzImage to copy<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 06:05, 19 February 2014 (UTC)<br />
: Not if you follow instructions to the letter. See previous reply. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:46, 25 February 2014 (UTC)<br />
<br />
== Keeping this article ==<br />
Keeping the traditional method would be beneficial, as a) not being distro-specific it can be applied to any Linux distro, and b) It's another option and another string in a given user's bow. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 17:09, 12 March 2016 (UTC)<br />
<br />
:I also agree that it adds basic Linux know-how which many users will value, even if they are just reading it and use [[ABS]] anyway. Related: Merging content with [[Kernels/Arch Build System]] will make maintenance of both more difficult, if one really wants to cover (some) extra points from the "traditional" method. Simpler to keep both in that respect as well. It might be useful to move this article to [[Kernels/Traditional]] or (my preference) [[Kernels/Traditional compilation]] to get rid of its second-level subpage, i.e. I vote to change the merge to a move template. <br />
:As another optional idea to distinguish the two articles on compilation more: it may be very interesting for readers, if [[Kernels/Compilation/Traditional#Make initial RAM disk]] would be transformed into the "traditional" kernel method. I.e. don't use [[mkinitcpio]] but show how to create an initrd according to [https://www.kernel.org/doc/Documentation/initrd.txt kernel doc]. <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:01, 13 March 2016 (UTC)<br />
:: Sounds good to me. The proposed new structure also makes sense. This article also has a lot of potential for expansion, e.g. applying patches, AUFS, and perhaps at least an overview of key modules/configs for kernels, etc. If someone doesn't add this content first, I can do so after I've learned a bit more. I'll certainly look at the alternative to mkinitcpio. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 11:18, 13 March 2016 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425581Kernel/Traditional compilation2016-03-13T09:50:50Z<p>Carlduff: /* Download the kernel source */ link to what cgroups actually is</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?|Talk:Kernels/Compilation/Traditional#Keeping this article}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. It is, of course, more complicated than compiling according to [[Kernels/Arch Build System]]. Consider the [[Arch Build System]] tools are developed and maintained to make repeatable compilation tasks efficient and safe.<br />
<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified [[cgroups]] hierarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version in the {{ic| General Setup --->}} option using one of the user interfaces listed later. If you skip this, there is the risk of overwriting one of your existing kernels by mistake.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to {{ic|-march<nowiki>=</nowiki>native}} to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
{{Tip|If your system requires modules which are not distributed with the regular Linux kernel, you need to compile them for your custom kernel when it is finished. Such modules are typically those which you explicitly installed seperately for your running system. See [[NVIDIA#Alternate install: custom kernel]] for an example.}}<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified as a suffix to {{ic|/boot/vmlinuz-}} when copying the {{ic|bzImage}} (in this case, {{ic|linux318}}):<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note (again) that the {{ic|ALL_kver<nowiki>=</nowiki>}} parameter also matches the name of the custom kernel specified when copying the {{ic|bzImage}}:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your {{ic|/boot}} is on a filesystem which supports symlinks (i.e., not FAT32), copy {{ic|System.map}} to {{ic|/boot}}, appending your kernel's name to the destination file. Then create a symlink from {{ic|/boot/System.map}} to point to {{ic|/boot/System.map-YourKernelName}}:<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: {{ic|vmlinuz-YourKernelName}}<br />
* Initramfs: {{ic|Initramfs-YourKernelName.img}}<br />
* System Map: {{ic|System.map-YourKernelName}}<br />
* System Map kernel symlink<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425573Kernel/Traditional compilation2016-03-13T09:34:56Z<p>Carlduff: /* Compilation and installation */ proper code format</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. It is, of course, more complicated than compiling according to [[Kernels/Arch Build System]]. Consider the [[Arch Build System]] tools are developed and maintained to make repeatable compilation tasks efficient and safe.<br />
<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup hierarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version in the {{ic| General Setup --->}} option using one of the user interfaces listed later. If you skip this, there is the risk of overwriting one of your existing kernels by mistake.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to {{ic|-march<nowiki>=</nowiki>native}} to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
{{Tip|If your system requires modules which are not distributed with the regular Linux kernel, you need to compile them for your custom kernel when it is finished. Such modules are typically those which you explicitly installed seperately for your running system. See [[NVIDIA#Alternate install: custom kernel]] for an example.}}<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified as a suffix to {{ic|/boot/vmlinuz-}} when copying the {{ic|bzImage}} (in this case, {{ic|linux318}}):<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note (again) that the {{ic|ALL_kver<nowiki>=</nowiki>}} parameter also matches the name of the custom kernel specified when copying the {{ic|bzImage}}:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your {{ic|/boot}} is on a filesystem which supports symlinks (i.e., not FAT32), copy {{ic|System.map}} to {{ic|/boot}}, appending your kernel's name to the destination file. Then create a symlink from {{ic|/boot/System.map}} to point to {{ic|/boot/System.map-YourKernelName}}:<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: {{ic|vmlinuz-YourKernelName}}<br />
* Initramfs: {{ic|Initramfs-YourKernelName.img}}<br />
* System Map: {{ic|System.map-YourKernelName}}<br />
* System Map kernel symlink<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425571Kernel/Traditional compilation2016-03-13T09:28:18Z<p>Carlduff: /* Automated preset method */ less awkward and clearer expression</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. It is, of course, more complicated than compiling according to [[Kernels/Arch Build System]]. Consider the [[Arch Build System]] tools are developed and maintained to make repeatable compilation tasks efficient and safe.<br />
<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup hierarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version in the {{ic| General Setup --->}} option using one of the user interfaces listed later. If you skip this, there is the risk of overwriting one of your existing kernels by mistake.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
{{Tip|If your system requires modules which are not distributed with the regular Linux kernel, you need to compile them for your custom kernel when it is finished. Such modules are typically those which you explicitly installed seperately for your running system. See [[NVIDIA#Alternate install: custom kernel]] for an example.}}<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified as a suffix to {{ic|/boot/vmlinuz-}} when copying the {{ic|bzImage}} (in this case, {{ic|linux318}}):<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note (again) that the {{ic|ALL_kver<nowiki>=</nowiki>}} parameter also matches the name of the custom kernel specified when copying the {{ic|bzImage}}:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your {{ic|/boot}} is on a filesystem which supports symlinks (i.e., not FAT32), copy {{ic|System.map}} to {{ic|/boot}}, appending your kernel's name to the destination file. Then create a symlink from {{ic|/boot/System.map}} to point to {{ic|/boot/System.map-YourKernelName}}:<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: {{ic|vmlinuz-YourKernelName}}<br />
* Initramfs: {{ic|Initramfs-YourKernelName.img}}<br />
* System Map: {{ic|System.map-YourKernelName}}<br />
* System Map kernel symlink<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}</div>Carlduffhttps://wiki.archlinux.org/index.php?title=User:Carlduff&diff=425567User:Carlduff2016-03-13T09:20:34Z<p>Carlduff: /* Re-written Articles */</p>
<hr />
<div>==Contributions==<br />
<br />
This will only outline new articles created, intended, or at least old articles that have been completely re-written. Minor edits will not be listed.<br />
<br />
=== New articles created ===<br />
<br />
* [[Oblogout]]<br />
* [[File manager functionality]]<br />
* [[SpaceFM]]<br />
<br />
=== Re-written Articles ===<br />
<br />
* [[Openbox]]<br />
* [[Compton]]<br />
* [[Xdg user directories]]<br />
* [[PCManFM]]<br />
* [[Kernels/Compilation/Traditional]]</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425430Kernel/Traditional compilation2016-03-12T20:49:12Z<p>Carlduff: /* Automated preset method */ Better expresion</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note that the {{ic|ALL-kver<nowiki>=</nowiki>}} parameter also marches the name of the custom kernel specified when copying the {{ic|bzImage}} to {{ic|/boot/vmlinuz-<custom kernel name>}}:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425429Kernel/Traditional compilation2016-03-12T20:47:07Z<p>Carlduff: /* Automated preset method */ fix grammar</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note that the {{ic|ALL-kver<nowiki>=</nowiki>}} parameter also refers to and matches the name given to the {{ic|vmlinuz-<custom name>}} image copied earlier to the {{ic|/boot}} directory after compiling the kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425428Kernel/Traditional compilation2016-03-12T20:46:09Z<p>Carlduff: /* Automated preset method */ fix</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note that the {{ic|ALL-kver<nowiki>=</nowiki>}} parameter also refers and matches the name given to the {{ic|vmlinuz-<custom name>}} image copied earlier to the {{ic|/boot}} directory after compiling the kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425427Kernel/Traditional compilation2016-03-12T20:44:19Z<p>Carlduff: /* Automated preset method */ Add explanation</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel. Note that the {{ic|ALL-kver=}} parameter refers and matches the name given to the {{ic|vmlinuz-}} image copied earlier to the {{ic|/boot}} directory after compiling the kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425426Kernel/Traditional compilation2016-03-12T20:41:33Z<p>Carlduff: /* Automated preset method */ fix template break</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver<nowiki>=</nowiki>"/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425425Kernel/Traditional compilation2016-03-12T20:41:10Z<p>Carlduff: /* Automated preset method */ Add vmlinuz config line</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
ALL_kver="/boot/vmlinuz-linux318"<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425423Kernel/Traditional compilation2016-03-12T20:39:17Z<p>Carlduff: /* Make initial RAM disk */ move tip here as note</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Note|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425422Kernel/Traditional compilation2016-03-12T20:38:48Z<p>Carlduff: /* Automated preset method */ move to heading above</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425421Kernel/Traditional compilation2016-03-12T20:35:55Z<p>Carlduff: /* Make initial RAM disk */ Revised and expand. Dropped the -c flag from the mkinitcpio command as /etc/mkinitcpio.conf is default anyway.</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
{{Tip|If you are using the LILO bootloader and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.}}<br />
<br />
If you do not know what making an initial RAM disk is, see [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]]. <br />
<br />
==== Automated preset method ====<br />
{{tip|You are free to name the initramfs image file whatever you wish when generating it. However, it is recommended to use the {{ic|linux<major revision><minor revision>}} convention. For example, the name 'linux318' was given as '3' is the major revision and '18' is the minor revision of the 3.18 kernel. This convention will make it easier to maintain multiple kernels, regularly use mkinitcpio, and build third-party modules.}}<br />
<br />
An existing [[Mkinitcpio#Image_creation_and_activation|mkinitcpio preset]] can be copied and modified so that the custom kernel initramfs images can be generated in the same way as for an official kernel. This is useful where intending to recompile the kernel in time (e.g. where updated). In the example below, the preset file for the stock Arch kernel will be copied and modified for kernel 3.18, installed above.<br />
<br />
First, copy the existing preset file, renaming it to match the name of the custom kernel specified when copying the {{ic|bzImage}} to the {{ic|/boot}} directory:<br />
<br />
# cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux318.preset<br />
<br />
Second, edit the file and amend for the custom kernel:<br />
<br />
{{hc|/etc/mkinitcpio.d/linux318.preset|<br />
...<br />
default_image<nowiki>=</nowiki>"/boot/initramfs-linux318.img"<br />
...<br />
fallback_image<nowiki>=</nowiki>"/boot/initramfs-linux318-fallback.img"}}<br />
<br />
Finally, generate the initramfs images for the custom kernel in the same way as for an official kernel:<br />
<br />
# mkinitcpio -p linux318<br />
<br />
==== Manual method ====<br />
Rather than use a preset file, mkinitcpio can also be used to generate an initramfs file manually. The syntax of the command is:<br />
<br />
# mkinitcpio -k <kernelversion> -g /boot/initramfs-<file name>.img<br />
<br />
* {{ic|-k}} (--kernel <kernelversion>): Specifies the modules to use when generating the initramfs image. The {{ic|<kernelversion>}} name will be the same as the name of the custom kernel source directory (and the modules directory for it, located in {{ic|/usr/lib/modules/}}).<br />
* {{ic|-g}} (--generate <filename>): Specifies the name of the initramfs file to generate in the {{ic|/boot}} directory. Again, using the naming convention mentioned above is recommended.<br />
<br />
<br />
For example, the command for the 3.18 custom kernel installed above would be:<br />
<br />
# mkinitcpio -k linux-3.18.28 -g /boot/initramfs-linux318.img<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Traditional_compilation&diff=425412Talk:Kernel/Traditional compilation2016-03-12T17:10:28Z<p>Carlduff: /* Keeping this article */ fix grammatical error</p>
<hr />
<div>== Keeping this article ==<br />
Keeping the traditional method would be beneficial, as a) not being distro-specific it can be applied to any Linux distro, and b) It's another option and another string in a given user's bow. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 17:09, 12 March 2016 (UTC)<br />
<br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)<br />
:Only if you don't invoke the default <code>make</code> target, or otherwise modified the makefile. See <code>make help</code>. Maybe we could note that this article infers "vanilla" sources, per instructions. If you want to add a section for patching, and how this may modify the instructions, go for it. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:44, 25 February 2014 (UTC)<br />
<br />
== Missing 'make bzImage' command ==<br />
This step is also required, otherwise there will be no bzImage to copy<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 06:05, 19 February 2014 (UTC)<br />
: Not if you follow instructions to the letter. See previous reply. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:46, 25 February 2014 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Traditional_compilation&diff=425410Talk:Kernel/Traditional compilation2016-03-12T17:10:00Z<p>Carlduff: asking to keep this article</p>
<hr />
<div>== Keeping this article ==<br />
Keeping the traditional method would be beneficial, as a) not being distro-specific it can be applied for any Linux distro, and b) It's another option and another string in a given user's bow. [[User:Carlduff|Carlduff]] ([[User talk:Carlduff|talk]]) 17:09, 12 March 2016 (UTC)<br />
<br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)<br />
:Only if you don't invoke the default <code>make</code> target, or otherwise modified the makefile. See <code>make help</code>. Maybe we could note that this article infers "vanilla" sources, per instructions. If you want to add a section for patching, and how this may modify the instructions, go for it. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:44, 25 February 2014 (UTC)<br />
<br />
== Missing 'make bzImage' command ==<br />
This step is also required, otherwise there will be no bzImage to copy<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 06:05, 19 February 2014 (UTC)<br />
: Not if you follow instructions to the letter. See previous reply. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 06:46, 25 February 2014 (UTC)</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425407Kernel/Traditional compilation2016-03-12T16:35:32Z<p>Carlduff: /* Copy the kernel to /boot directory */ use "linux" nor "kernel" (convention)</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-linux318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux318<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation|here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425405Kernel/Traditional compilation2016-03-12T16:27:46Z<p>Carlduff: /* Copy the kernel to ic|/boot directory */ fix typo</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to /boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-kernel318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation|here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425399Kernel/Traditional compilation2016-03-12T16:10:34Z<p>Carlduff: /* Compilation and installation */ gcc optimisation for 64 as well as 32-bit systems</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} (i686) or {{ic|arch/x86_64/Makefile}} (86_64) within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to ic|/boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-kernel318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation|here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425398Kernel/Traditional compilation2016-03-12T16:06:53Z<p>Carlduff: /* Compile the modules */ all commands from here should be root</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|From this step onwards, commands must be either run as root or with root privileges. If not, they will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to ic|/boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-kernel318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation|here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduffhttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=425397Kernel/Traditional compilation2016-03-12T16:05:46Z<p>Carlduff: /* Copy the kernel to /boot directory */ clarify and expand</p>
<hr />
<div>[[Category:Kernel]]<br />
[[fr:Compiler un nouveau noyau]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:カーネル/コンパイル/伝統的な方法]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
{{Merge|Kernels/Arch Build System|Benefit over using a PKGBUILD, besides "tradition"?}}<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
== Preparation ==<br />
<br />
It is not necessary (or recommended) to use the root account or root privileges (i.e. via [[Sudo]]) for kernel preparation.<br />
<br />
=== Install the core packages ===<br />
<br />
Install the {{Grp|base-devel}} package group, which contains necessary packages such as {{Pkg|make}} and {{Pkg|gcc}}. It is also recommended to install the following packages, as listed in the default Arch kernel [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux PKGBUILD]: {{Pkg|xmlto}}, {{Pkg|docbook-xsl}}, {{Pkg|kmod}}, {{Pkg|inetutils}}, {{Pkg|bc}}<br />
<br />
=== Create a kernel compilation directory ===<br />
<br />
It is recommended to create a separate build directory for your kernel(s). In this example, the directory {{ic|kernelbuild}} will be created in the {{ic|home}} directory:<br />
<br />
$ mkdir ~/kernelbuild<br />
<br />
=== Download the kernel source ===<br />
{{Note|<nowiki></nowiki><br />
* It is a good idea to verify the signature for any downloaded tarball to ensure that it is legitimate. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature].<br />
* [[systemd]] requires kernel version 3.11 and above (4.2 and above for unified cgroup heirarchy support). See {{ic|/usr/share/systemd/README}} for more information.}}<br />
<br />
Download the kernel source from http://www.kernel.org. This should be the [https://en.wikipedia.org/wiki/Tar_%28computing%29| tarball] ({{ic|tar.xz}}) file for your chosen kernel. It can be downloaded by simply right-clicking the {{ic|tar.xz}} link in your browser and selecting {{ic|Save Link As...}}, or any other number of ways via alternative graphical or command-line tools that utilise HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]]. In the following command-line example, {{Pkg|wget}} has been installed and is used inside the {{ic|~/kernelbuild}} directory to obtain kernel 3.18:<br />
<br />
$ cd ~/kernelbuild<br />
$ wget https://cdn.kernel.org/pub/linux/kernel/v3.x/linux-3.18.28.tar.xz<br />
<br />
If {{ic|wget}} was not used inside the build directory, it will be necessary to move the tarball into it, e.g.<br />
<br />
$ mv /path/to/linux-3.18.28.tar.xz ~/kernelbuild/<br />
<br />
=== Unpack the kernel source ===<br />
<br />
Within the build directory, unpack the kernel tarball:<br />
<br />
$ tar -xvJf linux-3.18.28.tar.xz<br />
<br />
To finalise the preparation, ensure that the kernel tree is absolutely clean; do not rely on the source tree being clean after unpacking. To do so, first change into the new kernel source directory created, and then run the {{ic|make mrproper}} command:<br />
<br />
$ cd linux-3.18.28<br />
$ make mrproper<br />
<br />
== Configuration ==<br />
{{Warning|If you are compiling a kernel using your current {{ic|.config}} file, do not forget to rename your kernel version, or you may replace your existing one by mistake. You should be able to do this in the {{ic| General Setup --->}} option where using one of the interfaces discussed below.}}<br />
<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. Kernel configuration is set in its {{ic|.config}} file, which includes the use of the [[Kernel_modules]]. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently. Note that - again - it is not necessary to use the root account or root privileges for this stage.<br />
<br />
=== Simple configuration ===<br />
{{Note|The custom kernel(s) being configured may support different features than the official Arch kernels. In this instance, you will be prompted to manually configure them. The configuration options should be {{ic|y}} to enable, {{ic|n}} to disable, and {{ic|m}} to enable when necessary.}}<br />
<br />
Two options are available for ease and to save time:<br />
* Use the default Arch settings from an official kernel (recommended)<br />
* Generate a configuration file by the modules and settings in use by a running kernel ''at that time''.<br />
<br />
==== Default Arch settings ====<br />
This method will create a {{ic|.config}} file for the custom kernel using the default Arch kernel settings. Ensure that a stock Arch kernel is running and use the following command inside the custom kernel source directory:<br />
<br />
$ zcat /proc/config.gz > .config<br />
<br />
==== Generated configuration file ====<br />
{{tip|Plug in all devices that you expect to use on the system if using this method.}}<br />
<br />
Since kernel 2.6.32, the {{ic|localmodconfig}} command will create a {{ic|.config}} file for the custom kernel by disabling any and all options not currently in use by the running kernel ''at the time''. In other words, it will only enable the options currently being used.<br />
<br />
While this minimalist approach will result in a highly streamlined and efficient configuration tailored specifically for your system, there are drawbacks, such as the potential inability of the kernel to support new hardware, peripherals, or other features. Again, ensure that all devices you expect to use have been connected to (and detected by) your system before running the following command:<br />
<br />
$ make localmodconfig<br />
<br />
=== Advanced configuration ===<br />
{{Tip|Unless you want to see a lot of extra messages when booting and shutting down with the custom kernel, it is a good idea to deactivate the relevant debugging options.}}<br />
<br />
There are several interfaces available to fine-tune the kernel configuration, which provide an alternative to otherwise spending hours manually configuring each and every one of the options available during compilation. They are:<br />
<br />
* {{ic|make menuconfig}}: Old command-line ncurses interface superceded by {{ic|nconfig}}<br />
* {{ic|make nconfig}}: Newer ncurses interface for the command-line<br />
* {{ic|make xconfig}}: User-friendly graphical interface that requires {{Pkg|packagekit-qt4}} to be installed as a dependency. This is the recommended method - especially for less experienced users - as it is easier to navigate, and information about each option is also displayed.<br />
<br />
The chosen method should be run inside the kernel source directory, and all will either create a new {{ic|.config}} file, or overwrite an existing one where present. All optional configurations will be automatically enabled, although any newer configuration options (i.e. with an older kernel {{ic|.config}}) may not be automatically selected.<br />
<br />
Once the changes have been made save the {{ic|.config}} file. It is a good idea to make a backup copy outside the source directory since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compilations. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
== Compilation and installation ==<br />
{{Tip|If you want to have {{Pkg|gcc}} optimize for your processor's instruction sets, edit {{ic|arch/x86/Makefile}} within the kernel source directory:<br />
* Look for {{ic|CONFIG_MK8,CONFIG_MPSC,CONFIG_MCORE2,CONFIG_MATOM,CONFIG_GENERIC_CPU}} that you have chosen in {{ic|Processor type and features > Processor Family}}<br />
* Change the call cc-options flag to -march<nowiki>=</nowiki>native to the one that you have selected in Processor Family, e.g. {{ic|cflags-$(CONFIG_MK8) +<nowiki>=</nowiki> $(call cc-option,-march<nowiki>=</nowiki>native)}}. This is probably the best way to compile with {{ic|-march<nowiki>=</nowiki>native}} as it works.}}<br />
<br />
=== Compile the kernel ===<br />
Compilation time will vary from as little as fifteen minutes to over an hour, depending on your kernel configuration and processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details. Once the {{ic|.config}} file has been set for the custom kernel, within the source directory run the following command to compile:<br />
<br />
$ make<br />
<br />
=== Compile the modules ===<br />
{{warning|This command must either be run as root or with root privileges. If not, it will fail.}}<br />
<br />
Once the kernel has been compiled, the modules for it must follow. As root or with root privileges, run the following command to do so:<br />
<br />
# make modules_install<br />
<br />
This will copy the compiled modules into {{ic|/lib/modules/<kernel version>-<config local version>}}. For example, for kernel version 3.18 installed above, they would be copied to {{ic|/lib/modules/3.18.28-ARCH}}. This keeps the modules for individual kernels used separated.<br />
<br />
=== Copy the kernel to ic|/boot directory ===<br />
{{Note|Ensure that the {{ic|bzImage}} kernel file has been copied from the appropriate directory for your system architecture. See below.}}<br />
<br />
The kernel compilation process will generate a compressed {{ic|bzImage}} (big zImage) of that kernel, which must be copied to the {{ic|/boot}} directory and renamed in the process. Provided the name is prefixed with {{ic|vmlinuz-}}, you may name the kernel as you wish. In the examples below, the installed and compiled 3.18 kernel has been copied over and renamed to {{ic|vmlinuz-kernel318}}:<br />
<br />
* 32-bit (i686) kernel:<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
* 64-bit (x86_64) kernel:<br />
# cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-kernel318<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd|Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation|here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
{{Tip| UEFI partitions are formatted using FAT32, which does not support symlinks.}}<br />
<br />
If your /boot is on a filesystem which supports symlinks (i.e., not FAT32), copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]], [[Syslinux]], [[Gummiboot]] or [[REFInd]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Carlduff