https://wiki.archlinux.org/api.php?action=feedcontributions&user=Grische&feedformat=atomArchWiki - User contributions [en]2024-03-28T09:05:56ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=573616Solid state drive2019-05-21T10:45:19Z<p>Grische: /* Continuous TRIM */ fixing Wikipedia link</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid state drive]]<br />
[[ja:ソリッドステートドライブ]]<br />
[[ru:Solid state drive]]<br />
[[zh-hans:Solid state drive]]<br />
[[zh-hant:Solid state drive]]<br />
{{Related articles start}}<br />
{{Related|Solid state drive/NVMe}}<br />
{{Related|Solid state drive/Memory cell clearing}}<br />
{{Related|Benchmarking/Data storage devices}}<br />
{{Related|Improving performance#Storage devices}}<br />
{{Related|Flashcache}}<br />
{{Related articles end}}<br />
This article covers special topics for operating [[Wikipedia:Solid-state drive|solid state drives]] (SSDs) and other flash-memory based storage devices. If you want to partition an SSD for a specific purpose, it may be useful to consider the [[Wikipedia:List of file systems#File systems optimized for flash memory, solid state media|List of file systems optimized for flash memory]]. For general usage, you should simply choose your preferred [[filesystem]].<br />
<br />
== Usage ==<br />
<br />
=== TRIM ===<br />
<br />
Most SSDs support the [[wikipedia:TRIM|ATA_TRIM command]] for sustained long-term performance and wear-leveling. A [https://www.techspot.com/review/737-ocz-vector-150-ssd/page9.html techspot article] shows performance benchmark examples of before and after filling an SSD with data.<br />
<br />
As of Linux kernel version 3.8 onwards, support for TRIM was continually added for the different [[filesystems]]. See the following table for an indicative overview:<br />
<br />
{| class="wikitable"<br />
! File system !! Continuous TRIM <br> ({{ic|discard}} option) !! Periodic TRIM <br> (''fstrim'') !! References<br> and notes<br />
|-<br />
| [[Ext3]] || {{No}} || {{META Table cell|?}} || <br />
|-<br />
| [[Ext4]] || {{Yes}} || {{Yes}} || [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/ext4.txt?id=5012284700775a4e6e3fbe7eac4c543c4874b559#n342]<br />
|-<br />
| [[Btrfs]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[JFS]] || {{Yes}} || {{Yes}} || [https://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY]<br />
|-<br />
| [[XFS]] || {{Yes}} || {{Yes}} || [http://xfs.org/index.php/FITRIM/discard]<br />
|-<br />
| [[F2FS]] || {{Yes}} || {{Yes}} ||<br />
|-<br />
| [[VFAT]] || {{Yes}} || {{Yes}} || ''fstrim'' is supported since kernel 4.19<br />
|-<br />
| [[NTFS-3G]] || {{No}} || {{Yes}} || since version 2015.3.14, [http://permalink.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/1101]<br />
|}<br />
<br />
{{Warning|Users need to be certain that their SSD supports TRIM before attempting to use it. Data loss can occur otherwise!}}<br />
<br />
To verify TRIM support, run:<br />
<br />
$ lsblk --discard<br />
<br />
And check the values of DISC-GRAN (discard granularity) and DISC-MAX (discard max bytes) columns. Non-zero values indicate TRIM support.<br />
<br />
Alternatively, [[install]] {{Pkg|hdparm}} package and run:<br />
<br />
{{hc|# hdparm -I /dev/sda {{!}} grep TRIM|<br />
* Data Set Management TRIM supported (limit 1 block)<br />
}}<br />
<br />
{{Note|There are different types of TRIM support defined by the specification. Hence, the output may differ depending what the drive supports. See [[Wikipedia:TRIM#ATA]] for more information.}}<br />
<br />
==== Periodic TRIM ====<br />
<br />
The {{Pkg|util-linux}} package provides {{ic|fstrim.service}} and {{ic|fstrim.timer}} [[systemd]] unit files. [[Enabling]] the timer will activate the service weekly. The service executes {{man|8|fstrim}} on all mounted filesystems on devices that support the ''discard'' operation.<br />
<br />
The timer relies on the timestamp of {{ic|/var/lib/systemd/timers/stamp-fstrim.timer}} (which it will create upon first invocation) to know whether a week has elapsed since it last ran. Therefore there is no need to worry about too frequent invocations, in an ''anacron''-like fashion.<br />
<br />
To query the units activity and status, see [[journalctl]]. To change the periodicity of the timer or the command run, [[edit]] the provided unit files.<br />
<br />
==== Continuous TRIM ====<br />
<br />
{{Note|There is no need to enable continuous TRIM if you run {{ic|fstrim}} periodically. If you want to use TRIM, use either periodic TRIM or continuous TRIM.}}<br />
<br />
Instead of issuing TRIM commands once in a while (by default once a week if using {{ic|fstrim.timer}}), it is also possible to issue TRIM commands each time files are deleted instead. The latter is known as the continuous TRIM.<br />
<br />
{{Warning|Before [[Wikipedia:Serial ATA#SATA revision 3.1|SATA 3.1]] all TRIM commands were non-queued, so continuous trimming would produce frequent system freezes. In this case, applying [[#Periodic TRIM]] less often is better alternative. Similar issue holds also for a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4522 number of devices], for which queued TRIM command execution was blacklisted due to [https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ serious data corruption]. In such case, depending on the device, the system may be forced to send non-queued TRIM commands the SSD instead of queued TRIM. See [[Wikipedia:Trim_(computing)#Disadvantages]] for details.}}<br />
<br />
{{Note|Continuous TRIM is not the most preferred way to issue TRIM commands among the Linux community. For example, Ubuntu enables periodic TRIM by default [https://askubuntu.com/questions/1034169/is-trim-enabled-on-my-ubuntu-18-04-installation], Debian does not recommend using continuous TRIM [https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems] and Red Hat recommends using periodic TRIM over using continuous TRIM if feasible. [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch02s04.html]}}<br />
<br />
Using the {{ic|discard}} option for a mount in {{ic|/etc/fstab}} enables continuous TRIM in device operations:<br />
<br />
/dev/sda1 / ext4 defaults,'''discard''' 0 1<br />
<br />
{{Note|1=Specifying the discard mount option in {{ic|/etc/fstab}} does not work with an XFS {{ic|/}} partition. According to [https://bbs.archlinux.org/viewtopic.php?id=143254 this thread], it has to be set using the {{ic|1=rootflags=discard}} [[kernel parameter]].}}<br />
<br />
On the ext4 filesystem, the {{ic|discard}} flag can also be set as a [[Access_Control_Lists#Enabling_ACL|default mount option]] using ''tune2fs'':<br />
<br />
# tune2fs -o discard /dev/sd'''XY'''<br />
<br />
Using the default mount options instead of an entry in {{ic|/etc/fstab}} is particularly useful for external drives, because such partition will be mounted with the default options also on other machines. This way, there is no need to edit {{ic|/etc/fstab}} on every machine.<br />
<br />
{{Note|The default mount options are not listed in {{ic|/proc/mounts}}.}}<br />
<br />
==== Trim an entire device ====<br />
<br />
If you want to trim your entire SSD at once, e.g. for a new install, or you want to sell your SSD, you can use the blkdiscard command, which will instantly discard all blocks on a device. <br />
<br />
{{Warning|all data on the device will be lost!}}<br />
<br />
# blkdiscard /dev/sd''X''<br />
<br />
==== LVM ====<br />
<br />
Change the value of {{ic|issue_discards}} option from 0 to 1 in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
{{Note|Enabling this option will "issue discards to a logical volumes's underlying physical volume(s) when the logical volume is no longer using the physical volumes' space (e.g. ''lvremove'', ''lvreduce'', etc)" (see {{man|5|lvm.conf}} and/or inline comments in {{ic|/etc/lvm/lvm.conf}}). As such it does not seem to be required for "regular" TRIM requests (file deletions inside a filesystem) to be functional.}}<br />
<br />
==== dm-crypt ====<br />
<br />
{{Warning|The discard option allows discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.}}<br />
<br />
For non-root filesystems, configure {{ic|/etc/crypttab}} to include {{ic|discard}} in the list of options for encrypted block devices located on an SSD (see [[dm-crypt/System configuration#crypttab]]).<br />
<br />
For the root filesystem, follow the instructions from [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] to add the right kernel parameter to the bootloader configuration.<br />
<br />
=== Maximizing performance ===<br />
<br />
Follow the tips in [[Improving performance#Storage devices]] to maximize the performance of your drives.<br />
<br />
=== Security ===<br />
<br />
==== Hdparm shows "frozen" state ====<br />
<br />
Some motherboard BIOS' issue a "security freeze" command to attached storage devices on initialization. Likewise some SSD (and HDD) BIOS' are set to "security freeze" in the factory already. Both result in the device's password security settings to be set to '''frozen''', as shown in below output: <br />
<br />
{{hc|head=# hdparm -I /dev/sda |output=<br />
Security: <br />
Master password revision code = 65534<br />
supported<br />
not enabled<br />
'''not locked'''<br />
'''frozen'''<br />
not expired: security count<br />
supported: enhanced erase<br />
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.<br />
}}<br />
<br />
Operations like formatting the device or installing operating systems are not affected by the "security freeze". <br />
<br />
The above output shows the device is '''not locked''' by a HDD-password on boot and the '''frozen''' state safeguards the device against malwares which may try to lock it by setting a password to it at runtime. <br />
<br />
If you intend to set a password to a "frozen" device yourself, a motherboard BIOS with support for it is required. A lot of notebooks have support, because it is required for [[Wikipedia:Hardware-based_full_disk_encryption|hardware encryption]], but support may not be trivial for a desktop/server board. For the Intel DH67CL/BL motherboard, for example, the motherboard has to be set to "maintenance mode" by a physical jumper to access the settings (see [https://sstahlman.blogspot.in/2014/07/hardware-fde-with-intel-ssd-330-on.html?showComment=1411193181867#c4579383928221016762], [https://communities.intel.com/message/251978#251978]). <br />
<br />
{{Warning|Do not try to change the above '''lock''' security settings with {{ic|hdparm}} unless you know exactly what you are doing.}}<br />
<br />
If you intend to erase the SSD, see [[Securely wipe disk#hdparm]] and [[#SSD memory cell clearing]] below.<br />
<br />
==== SSD memory cell clearing ====<br />
<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [https://www.anandtech.com/show/2738/8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD memory cell clearing]] wiki article. If the reason for the reset is to wipe data, you may not want to rely on the SSD bios to perform it securely. See [[Securely wipe disk#Flash memory]] for further information and examples to perform a wipe.<br />
<br />
==== Hardware encryption ====<br />
<br />
As noted in [[#Hdparm shows "frozen" state]] setting a password for a storage device (SSD/HDD) in the BIOS may also initialize the hardware encryption of devices supporting it. If the device also conforms to the OPAL standard, this may also be achieved without a respective BIOS feature to set the passphrase, see [[Self-Encrypting Drives]].<br />
<br />
== Troubleshooting ==<br />
<br />
It is possible that the issue you are encountering is a firmware bug which is not Linux specific, so before trying to troubleshoot an issue affecting the SSD device, you should first check if updates are available for:<br />
<br />
* The [[#Firmware|SSD's firmware]]<br />
* The [[Flashing_BIOS_from_Linux|motherboard's BIOS/UEFI firmware]]<br />
<br />
Even if it is a firmware bug it might be possible to avoid it, so if there are no updates to the firmware or you hesitant on updating firmware then the following might help.<br />
<br />
=== Resolving NCQ errors ===<br />
<br />
Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:<br />
<br />
[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen<br />
[ 9.115550] ata9.00: failed command: READ FPDMA QUEUED<br />
[ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in<br />
[ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)<br />
<br />
To disable NCQ on boot, add {{ic|1=libata.force=noncq}} to the kernel command line in the [[bootloader]] configuration. To disable NCQ only for disk 0 on port 9 use: {{ic|1=libata.force=9.00:noncq}}<br />
<br />
Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:<br />
<br />
# echo 1 > /sys/block/sdX/device/queue_depth<br />
<br />
If this (and also updating the firmware) does not resolves the problem or cause other issues, then [[Reporting bug guidelines|file a bug report]].<br />
<br />
=== Resolving SATA power management related errors ===<br />
<br />
Some SSDs (e.g. Transcend MTS400) are failing when SATA Active Link Power Management, [[wikipedia:Aggressive Link Power Management|ALPM]], is enabled.<br />
ALPM is disabled by default and enabled by a power saving daemon (e.g. [[TLP]], [[Laptop Mode Tools]]).<br />
<br />
If you are starting to encounter SATA related errors when using such a daemon, you should try to disable ALPM by setting its state to {{ic|max_performance}} for both battery and AC powered profiles.<br />
<br />
== Firmware ==<br />
<br />
=== ADATA ===<br />
<br />
ADATA has a utility available for Linux (i686) on their [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en support page]. The link to latest firmware will appear after selecting the model. The latest Linux update utility is packed with firmware and needs to be run as root. One may need to set correct permissions for binary file first.<br />
<br />
=== Crucial ===<br />
<br />
Crucial provides an option for updating the firmware with an ISO image. These images can be found after selecting the product on their [http://www.crucial.com/usa/en/support-ssd SSD support page] and downloading the "Manual Boot File." <br />
<br />
{{Note|ISO images provided by Crucial do not seem to be hybrid. If you will use just the {{ic|dd}} command to copy the image to some device, the [[MBR]] will not be present, making such device unbootable.}}<br />
<br />
Owners of an M4 Crucial model, may check if a firmware upgrade is needed with {{ic|smartctl}}.<br />
<br />
{{hc|$ smartctl --all /dev/sd'''X'''|<br />
==> WARNING: This drive may hang after 5184 hours of power-on time:<br />
http://www.tomshardware.com/news/Crucial-m4-Firmware-BSOD,14544.html<br />
See the following web pages for firmware updates:<br />
http://www.crucial.com/support/firmware.aspx<br />
http://www.micron.com/products/solid-state-storage/client-ssd#software<br />
}}<br />
<br />
Users seeing this warning are advised to backup all sensible data and '''consider upgrading immediately'''. Check [http://www.rojtberg.net/1008/updating-crucial-mx100-firmware-with-ubuntu/ this instructions] to update Crucial MX100 firmware by using the ISO image and Grub.<br />
<br />
=== Intel ===<br />
<br />
Intel has a Linux live system based [https://downloadcenter.intel.com/download/18363 Firmware Update Tool] for operating systems that are not compatible with its [https://downloadcenter.intel.com/download/18455 Intel® Solid-State Drive Toolbox] software.<br />
<br />
=== Kingston ===<br />
<br />
KFU tool is available on the AUR for the Sandforce based drives, {{AUR|kingston_fw_updater}}.<br />
<br />
=== Mushkin ===<br />
<br />
The lesser known Mushkin brand solid state drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
<br />
OCZ has a [https://www.ocz.com/us/download/clout Command Line Online Update Tool (CLOUT)] available for Linux. The AUR provides {{AUR|ocz-ssd-utility}}, {{AUR|ocztoolbox}} and {{AUR|oczclout}}.<br />
<br />
=== Samsung ===<br />
<br />
Samsung notes that update methods other than using their Magician Software are "not supported," but it is possible. The Magician Software can be used to make a USB drive bootable with the firmware update. Samsung provides pre-made [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html bootable ISO images] that can be used to update the firmware. Another option is to use Samsung's {{AUR|samsung_magician-consumer-ssd}}, which is available in the AUR. Magician only supports Samsung-branded SSDs; those manufactured by Samsung for OEMs (e.g., Lenovo) are not supported.<br />
<br />
{{Note|Samsung does not make it obvious at all that they actually provide these. They seem to have 4 different firmware update pages, and each references different ways of doing things.}}<br />
<br />
Users preferring to run the firmware update from a live USB created under Linux (without using Samsung's "Magician" software under Microsoft Windows) can refer to [http://fomori.org/blog/?p=933 this post] for reference.<br />
<br />
==== Native upgrade ====<br />
<br />
{{Style|Assumes use of [[udisks]]; loop mounts can be done directly via [[mount]]}}<br />
<br />
Alternatively, the firmware can be upgraded natively, without making a bootable USB stick, as shown below.<br />
<br />
First visit the [https://www.samsung.com/semiconductor/minisite/ssd/download/tools.html Samsung downloads page] and download the latest firmware for Windows, which is available as a disk image. In the following, {{ic|Samsung_SSD_840_EVO_EXT0DB6Q.iso}} is used as an example file name, adjust it accordingly.<br />
<br />
Setup the disk image:<br />
<br />
$ udisksctl loop-setup -r -f Samsung_SSD_840_EVO_EXT0DB6Q.iso<br />
<br />
This will make the ISO available as a loop device, and display the device path. Assuming it was {{ic|/dev/loop0}}:<br />
<br />
$ udisksctl mount -b /dev/loop0<br />
<br />
Get the contents of the disk:<br />
<br />
$ mkdir Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cp -r /run/media/$USER/CDROM/isolinux/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
<br />
Unmount the iso:<br />
<br />
$ udisksctl unmount -b /dev/loop0<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/isolinux<br />
<br />
There is a FreeDOS image here that contains the firmware. Mount the image as before:<br />
<br />
$ udisksctl loop-setup -r -f btdsk.img<br />
$ udisksctl mount -b /dev/loop1<br />
$ cp -r /run/media/$USER/C04D-1342/ Samsung_SSD_840_EVO_EXT0DB6Q<br />
$ cd Samsung_SSD_840_EVO_EXT0DB6Q/C04D-1342/samsung<br />
<br />
Get the disk number from magician:<br />
<br />
# magician -L<br />
<br />
Assuming it was 0:<br />
<br />
# magician --disk 0 -F -p DSRD<br />
<br />
Verify that the latest firmware has been installed:<br />
<br />
# magician -L<br />
<br />
Finally reboot.<br />
<br />
=== SanDisk ===<br />
<br />
SanDisk makes ISO firmware images to allow SSD firmware update on operating systems that are unsupported by their SanDisk SSD Toolkit.<br />
<br />
One must choose the firmware for the correct ''SSD model'', '''and''' the correct ''capacity'' that it has (e.g. 60GB, '''or''' 256GB). After burning the ISO firmware image, simply restart the PC to boot with the newly created CD/DVD boot disk (may work from a USB stick).<br />
<br />
The iso images just contain a linux kernel and an initrd. Extract them to {{ic|/boot}} partition and boot them with [[GRUB]] or [[Syslinux]] to update the firmware.<br />
<br />
See also:<br />
<br />
SanDisk Extreme SSD [https://kb.sandisk.com/app/answers/detail/a_id/10127 Firmware Release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10476 Manual Firmware update version R211] <br />
<br />
SanDisk Ultra SSD [https://kb.sandisk.com/app/answers/detail/a_id/10192 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/10477 Manual Firmware update version 365A13F0]<br />
<br />
SanDisk Ultra+ SSD [https://kb.sandisk.com/app/answers/detail/a_id/12763 Firmware release notes] and [https://kb.sandisk.com/app/answers/detail/a_id/12762 Manual Firmware update version X2316RL] - use {{ic|smartctl -a /dev/sdX}} to determine if a "H2" or "HP" model is used.<br />
<br />
== See also ==<br />
<br />
* [https://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* [http://permalink.gmane.org/gmane.comp.file-systems.btrfs/19446 Re: Varying Leafsize and Nodesize in Btrfs]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/19650/focus=19667 Re: SSD alignment and Btrfs sector size]<br />
* [https://forums.anandtech.com/threads/erase-block-alignment-misinformation.2266113/ Erase Block (Alignment) Misinformation?]<br />
* [https://superuser.com/questions/492084/is-alignment-to-erase-block-size-needed-for-modern-ssds Is alignment to erase block size needed for modern SSD's?]<br />
* [http://thread.gmane.org/gmane.comp.file-systems.btrfs/15646 Btrfs support for efficient SSD operation (data blocks alignment)]<br />
* [https://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment SSD, Erase Block Size & LVM: PV on raw device, Alignment]</div>Grischehttps://wiki.archlinux.org/index.php?title=EFI_system_partition&diff=570469EFI system partition2019-04-04T11:22:28Z<p>Grische: /* ESP on RAID */ adding a link to a guide on how to use it</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:EFI system partition]]<br />
[[fr:ESP]]<br />
[[ja:EFI システムパーティション]]<br />
[[ru:EFI system partition]]<br />
[[zh-hans:EFI system partition]]<br />
{{Related articles start}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|Boot loader}}<br />
{{Related articles end}}<br />
The [[Wikipedia:EFI system partition|EFI system partition]] (also called ESP) is an OS independent partition that acts as the storage place for the EFI bootloaders, applications and drivers to be launched by the UEFI firmware. It is mandatory for UEFI boot. <br />
<br />
{{Move|#Format the partition|ESP file system support is only relevant when creating the file system.|section=Size of EFI partition}}<br />
<br />
{{Move|Unified Extensible Firmware Interface#UEFI drivers|Drivers for non-FAT file systems are out of scope of this article.}}<br />
<br />
The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see [https://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G17.1019485 UEFI specification version 2.7, section 13.3.1.1]), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple [[Mac]]s supports the HFS+ file system.<br />
<br />
== Check for an existing partition ==<br />
<br />
If you are installing Arch Linux on an UEFI-capable computer with an installed operating system, like [[Dual boot with Windows|Windows]] 10 for example, it is very likely that you already have an EFI system partition.<br />
<br />
To find out the disk partition scheme and the system partition, use [[fdisk]] as root on the disk you want to boot from:<br />
<br />
# fdisk -l /dev/sd''x''<br />
<br />
The command returns:<br />
<br />
* The disk's partition table: it indicates {{ic|Disklabel type: gpt}} if the partition table is [[GPT]] or {{ic|Disklabel type: dos}} if it is [[MBR]].<br />
* The list of partitions on the disk: Look for the EFI system partition in the list, it is a small (usually about 100–550 MiB) partition with a type {{ic|EFI System}} or {{ic|EFI (FAT-12/16/32)}}. To confirm this is the ESP, [[mount]] it and check whether it contains a directory named {{ic|EFI}}, if it does this is definitely the ESP.<br />
<br />
{{Tip|To find out whether it is a FAT12, FAT16 or FAT32 file system, use {{ic|minfo}} from {{Pkg|mtools}}.<br />
<br />
# minfo -i /dev/sd''xY'' :: {{!}} grep 'disk type'<br />
<br />
}}<br />
<br />
{{Warning|When dual-booting, avoid reformatting the ESP, as it may contain files required to boot other operating systems.}}<br />
<br />
If you found an existing EFI system partition, simply proceed to [[#Mount the partition]]. If you did not find one, you will need to create it, proceed to [[#Create the partition]].<br />
<br />
== Create the partition ==<br />
<br />
{{Accuracy|550 MiB is not a requirement but a "trick" when not using {{ic|-F32}} as {{man|8|mkfs.fat}} argument.|section=Wording in example layout table and size of EFI partition}}<br />
<br />
{{Style|The section mentions 100 MiB as a "microsoft note", but without the implications if the ESP is used as /boot partition. For example, as of 2019-03-13, the {{Pkg|linux-lts}} package has an installed size of 126.4 MB.|section=Wording in example layout table and size of EFI partition}}<br />
<br />
The following two sections show how to create an EFI system partition (ESP).<br />
{{Warning|The EFI system partition must be a physical partition in the main partition table of the disk, not under LVM or software RAID etc.}}<br />
<br />
{{Note|It is recommended to use [[GPT]] for UEFI boot, because some UEFI firmwares do not allow UEFI/MBR boot.}}<br />
<br />
To avoid potential problems with some UEFI implementations, the ESP should be formatted with FAT32 and the size should be at least 512 MiB. 550 MiB is recommended to avoid MiB/MB confusion and accidentally creating FAT16 [https://www.rodsbooks.com/efi-bootloaders/principles.html], although larger sizes are fine.<br />
<br />
According to a Microsoft note[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules], the minimum size for the EFI system partition (ESP) would be 100 MiB, though this is not stated in the UEFI Specification. Note that for [[Advanced Format]] 4K Native drives (4-KiB-per-sector) drives, the size is at least 256 MiB, because it is the minimum partition size of FAT32 drives (calculated as sector size (4KiB) x 65527 &#61; 256 MiB), due to a limitation of the FAT32 file format.<br />
<br />
=== GPT partitioned disks ===<br />
<br />
EFI system partition on a [[GUID Partition Table]] is identified by the [[Wikipedia:GUID Partition Table#Partition type GUIDs|partition type GUID]] {{ic|C12A7328-F81F-11D2-BA4B-00A0C93EC93B}}.<br />
<br />
'''Choose one''' of the following methods to create an ESP for a GPT partitioned disk:<br />
<br />
* [[fdisk]]: Create a partition with partition type {{ic|EFI System}}.<br />
* [[gdisk]]: Create a partition with partition type {{ic|EF00}}.<br />
* [[GNU Parted]]: Create a partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.<br />
<br />
Proceed to [[#Format the partition]] section below.<br />
<br />
=== MBR partitioned disks ===<br />
<br />
EFI system partition on a [[Master Boot Record]] partition table is identified by the [[Wikipedia:Partition type|partition type ID]] {{ic|EF}}.<br />
<br />
'''Choose one''' of the following methods to create an ESP for a MBR partitioned disk:<br />
<br />
* [[fdisk]]: Create a primary partition with partition type {{ic|EFI (FAT-12/16/32)}}.<br />
* [[GNU Parted]]: Create a primary partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.<br />
<br />
Proceed to [[#Format the partition]] section below.<br />
<br />
== Format the partition ==<br />
<br />
After creating the ESP, you '''must''' [[format]] it as [[FAT32]]. To use the {{ic|mkfs.fat}} utility, [[install]] {{Pkg|dosfstools}}.<br />
<br />
# mkfs.fat -F32 /dev/sd''xY''<br />
<br />
If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}; otherwise the partition may be unreadable by UEFI. See {{man|8|mkfs.fat}} for supported cluster sizes.<br />
<br />
== Mount the partition ==<br />
<br />
The kernels, initramfs files, and, in most cases, the processor's [[microcode]], need to be accessible by the [[boot loader]] or UEFI itself to successfully boot the system. Thus if you want to keep the setup simple, your boot loader choice limits the available mount points for EFI system partition.<br />
<br />
The simplest scenarios for mounting EFI system partition are:<br />
<br />
* [[mount]] ESP to {{ic|/efi}} and use a [[boot loader]] which has a driver for your root file system (eg. [[GRUB]], [[rEFInd]]).<br />
* [[mount]] ESP to {{ic|/boot}}. This is the preferred method when directly booting a [[EFISTUB]] kernel from UEFI.<br />
<br />
{{Note|The ESP will usually contain a directory called {{ic|EFI}} at the root of it, thus when mounting ESP to {{ic|/boot}} you may encounter a directory path such as {{ic|/boot/EFI}}. Do not confuse this path with the previously popular (and possibly still used by other Linux distributions) ESP mountpoint {{ic|/boot/efi}}.}}<br />
<br />
=== Alternative mount points ===<br />
<br />
If you do not use one of the simple methods from [[#Mount the partition]], you will need to copy your boot files to ESP (referred to hereafter as {{ic|''esp''}}).<br />
<br />
# mkdir -p ''esp''/EFI/arch<br />
# cp -a /boot/vmlinuz-linux ''esp''/EFI/arch/<br />
# cp -a /boot/initramfs-linux.img ''esp''/EFI/arch/<br />
# cp -a /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/<br />
<br />
{{Note|You may also need to copy the [[Microcode]] to the boot-entry location.}}<br />
<br />
Furthermore, you will need to keep the files on the ESP up-to-date with later kernel updates. Failure to do so could result in an unbootable system. The following sections discuss several mechanisms for automating it.<br />
<br />
{{Note|If ESP is not mounted to {{ic|/boot}}, make sure to not rely on the [[fstab#Automount with systemd|systemd automount mechanism]] (including that of {{man|8|systemd-gpt-auto-generator}}). Always have it mounted manually prior to the any system or kernel update, otherwise you may not be able to mount it after the update, locking you in the currently running kernel with no ability to update the copy of kernel on ESP.<br />
<br />
Alternatively [[Kernel module#Automatic module loading with systemd|preload the required kernel modules on boot]], e.g.:<br />
<br />
{{hc|/etc/modules-load.d/vfat.conf|<br />
vfat<br />
nls_cp437<br />
nls_iso8859-1<br />
}}<br />
<br />
}}<br />
<br />
==== Using bind mount ====<br />
<br />
Instead of mounting the ESP itself to {{ic|/boot}}, you can mount a directory of the ESP to {{ic|/boot}} using a bind [[mount]] (see {{man|8|mount}}). This allows [[pacman]] to update the kernel directly while keeping the ESP organized to your liking.<br />
<br />
{{Note|<br />
* This requires a [[FAT#Kernel configuration|kernel]] and [[bootloader]] compatible with FAT32. This is not an issue for a regular Arch install, but could be problematic for other distributions (namely those that require symlinks in {{ic|/boot/}}). See the forum post [https://bbs.archlinux.org/viewtopic.php?pid&#61;1331867#p1331867 here].<br />
* You ''must'' use the {{ic|1=root=}} [[Kernel parameters#Parameter list|kernel parameter]] in order to boot using this method.<br />
}}<br />
<br />
Just like in [[#Alternative mount points]], copy all boot files to a directory on your ESP, but mount the ESP '''outside''' {{ic|/boot}}. Then bind mount the directory:<br />
<br />
# mount --bind ''esp''/EFI/arch /boot<br />
<br />
After verifying success, edit your [[Fstab]] to make the changes persistent:<br />
<br />
{{hc|/etc/fstab|<br />
''esp''/EFI/arch /boot none defaults,bind 0 0<br />
}}<br />
<br />
==== Using systemd ====<br />
<br />
[[Systemd]] features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in {{ic|/boot/}}. The file watched for changes is {{ic|initramfs-linux-fallback.img}} since this is the last file built by mkinitcpio, to make sure all files have been built before starting the copy. The ''systemd'' path and service files to be created are:<br />
<br />
{{hc|/etc/systemd/system/efistub-update.path|2=<br />
[Unit]<br />
Description=Copy EFISTUB Kernel to EFI system partition<br />
<br />
[Path]<br />
PathChanged=/boot/initramfs-linux-fallback.img<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
WantedBy=system-update.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/efistub-update.service|2=<br />
[Unit]<br />
Description=Copy EFISTUB Kernel to EFI system partition<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux ''esp''/EFI/arch/<br />
ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img ''esp''/EFI/arch/<br />
ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/<br />
}}<br />
<br />
Then [[enable]] and [[start]] {{ic|efistub-update.path}}.<br />
<br />
{{Tip|For [[Secure Boot]] with your own keys, you can set up the service to also sign the image using {{Pkg|sbsigntools}}:<br />
<br />
{{bc|1=ExecStart=/usr/bin/sbsign --key ''/path/to/db.key'' --cert ''/path/to/db.crt'' --output ''esp''/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux}}<br />
<br />
}}<br />
<br />
==== Using filesystem events ====<br />
<br />
[[Autostarting#On filesystem events|Filesystem events]] can be used to run a script syncing the EFISTUB Kernel after kernel updates. An example with [[incron]] follows.<br />
<br />
{{hc|/usr/local/bin/efistub-update|<br />
#!/bin/sh<br />
cp -af /boot/vmlinuz-linux ''esp''/EFI/arch/<br />
cp -af /boot/initramfs-linux.img ''esp''/EFI/arch/<br />
cp -af /boot/initramfs-linux-fallback.img ''esp''/EFI/arch/<br />
}}<br />
<br />
{{Note|The first parameter {{ic|/boot/initramfs-linux-fallback.img}} is the file to watch. The second parameter {{ic|IN_CLOSE_WRITE}} is the action to watch for. The third parameter {{ic|/usr/local/bin/efistub-update}} is the script to execute.}}<br />
<br />
{{hc|/etc/incron.d/efistub-update.conf|<br />
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update<br />
}}<br />
<br />
In order to use this method, [[enable]] the {{ic|incrond.service}}.<br />
<br />
==== Using mkinitcpio hook ====<br />
<br />
Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of {{ic|vmlinuz}}, {{ic|initramfs-linux.img}}, and {{ic|initramfs-linux-fallback.img}} before copying the files.<br />
<br />
Add {{ic|efistub-update}} to the list of hooks in {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
{{hc|/etc/initcpio/install/efistub-update|<nowiki><br />
#!/usr/bin/env bash<br />
build() {<br />
/usr/local/bin/efistub-copy $$ &<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
{{hc|/usr/local/bin/efistub-copy|<br />
#!/usr/bin/env bash<br />
<br />
<nowiki>if [[ $1 -gt 0 ]]</nowiki><br />
then<br />
while [ -e /proc/$1 ]<br />
do<br />
sleep .5<br />
done<br />
fi<br />
<br />
rsync -a /boot/ ''esp''/<br />
<br />
echo "Synced /boot with ESP"<br />
}}<br />
<br />
==== Using mkinitcpio hook (2) ====<br />
<br />
Another '''alternative''' to the above solutions, that is potentially cleaner because there are less copies and does not need a system level daemon to function. The logic is reversed, the initramfs is directly stored in the EFI partition, not copied in {{ic|/boot/}}. Then the kernel and any other additional files are copied to the ESP partition, thanks to a mkinitcpio hook.<br />
<br />
Edit the file {{ic|/etc/mkinitcpio.d/linux.preset}} :<br />
<br />
{{hc|/etc/mkinitcpio.d/linux.preset|2=<br />
# mkinitcpio preset file for the 'linux' package<br />
<br />
# Directory to copy the kernel, the initramfs...<br />
ESP_DIR="''esp''/EFI/arch"<br />
<br />
ALL_config="/etc/mkinitcpio.conf"<br />
ALL_kver="/boot/vmlinuz-linux"<br />
<br />
PRESETS=('default' 'fallback')<br />
<br />
#default_config="/etc/mkinitcpio.conf"<br />
default_image="${ESP_DIR}/initramfs-linux.img"<br />
default_options="-A esp-update-linux"<br />
<br />
#fallback_config="/etc/mkinitcpio.conf"<br />
fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"<br />
fallback_options="-S autodetect"<br />
}}<br />
<br />
Then create the file {{ic|/etc/initcpio/install/esp-update-linux}} which need to be executable :<br />
<br />
{{hc|/etc/initcpio/install/esp-update-linux|<nowiki><br />
# Directory to copy the kernel, the initramfs...<br />
ESP_DIR="</nowiki>''esp''<nowiki>/EFI/arch"<br />
<br />
build() {<br />
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"<br />
[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"<br />
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook copies the kernel to the ESP partition<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
To test that, just run:<br />
<br />
# rm /boot/initramfs-linux-fallback.img<br />
# rm /boot/initramfs-linux.img<br />
# mkinitcpio -p linux<br />
<br />
==== Using mkinitcpio preset ====<br />
<br />
As the presets in {{ic|/etc/mkinitcpio.d/}} support shell scripting, the kernel and initramfs can be copied by just editing the presets.<br />
<br />
{{hc|/etc/mkinitcpio.d/0.preset|2=<br />
ESP_DIR="''esp''/EFI/arch"<br />
cp -af "/boot/vmlinuz-linux${suffix}" "$ESP_DIR/"<br />
ALL_config="/etc/mkinitcpio.conf"<br />
ALL_kver="$ESP_DIR/vmlinuz-linux${suffix}"<br />
PRESETS=('default')<br />
default_config="/etc/mkinitcpio.conf"<br />
default_image="$ESP_DIR/initramfs-linux${suffix}.img"<br />
}}<br />
<br />
{{hc|/etc/mkinitcpio.d/linux.preset|<br />
source /etc/mkinitcpio.d/0.preset<br />
}}<br />
<br />
{{hc|/etc/mkinitcpio.d/linux-zen.preset|2=<br />
suffix='-zen'<br />
source /etc/mkinitcpio.d/0.preset<br />
}}<br />
<br />
==== Using pacman hook ====<br />
<br />
A last option relies on the [[pacman hooks]] that are run at the end of the transaction.<br />
<br />
The first file is a hook that monitors the relevant files, and it is run if they were modified in the former transaction.<br />
<br />
{{hc|/etc/pacman.d/hooks/999-kernel-efi-copy.hook|<nowiki><br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Target = boot/vmlinuz*<br />
Target = usr/lib/initcpio/*<br />
Target = boot/*-ucode.img<br />
<br />
[Action]<br />
Description = Copying linux and initramfs to EFI directory...<br />
When = PostTransaction<br />
Exec = /usr/local/bin/kernel-efi-copy.sh<br />
</nowiki>}}<br />
<br />
The second file is the script itself. Create the file and make it [[executable]]:<br />
<br />
{{hc|/usr/local/bin/kernel-efi-copy.sh|<nowiki><br />
#!/usr/bin/env bash<br />
#<br />
# Copy kernel and initramfs images to EFI directory<br />
#<br />
<br />
ESP_DIR="</nowiki>''esp''<nowiki>/EFI/arch"<br />
<br />
for file in /boot/vmlinuz*<br />
do<br />
cp -af "$file" "$ESP_DIR/$(basename "$file").efi"<br />
[[ $? -ne 0 ]] && exit 1<br />
done<br />
<br />
for file in /boot/initramfs*<br />
do<br />
cp -af "$file" "$ESP_DIR/"<br />
[[ $? -ne 0 ]] && exit 1<br />
done<br />
<br />
[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "$ESP_DIR/"<br />
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "$ESP_DIR/"<br />
<br />
exit 0<br />
</nowiki>}}<br />
<br />
== Known issues ==<br />
<br />
=== ESP on RAID ===<br />
<br />
It is possible to make the ESP part of a RAID1 array, but doing so brings the risk of data corruption, and further considerations need to be taken when creating the ESP.<br />
See [https://bbs.archlinux.org/viewtopic.php?pid=1398710#p1398710] and [https://bbs.archlinux.org/viewtopic.php?pid=1390741#p1390741] for details.<br />
<br />
<br />
A more in-depth guide on how to use a RAID1, can be found here:<br />
https://outflux.net/blog/archives/2018/04/19/uefi-booting-and-raid1/<br />
<br />
The key part in the above article is to use {{ic|--metadata 1.0}} in order to keep the RAID metadata at the end of the partition (see link above for details):<br />
# mdadm --create /dev/md0 --level mirror --raid-disks 2 --metadata 1.0 /dev/sdaX /dev/sdbY<br />
<br />
== See also ==<br />
<br />
* [https://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/ The EFI system partition and the default boot behavior]</div>Grische