From ArchWiki

$esp pseudo-var

I'd suggest replacing $esp that's prominent in the article with the standard /boot, i.e. replace

$esp is used to denote the mountpoint in this article.


In this article, /boot is used as the mountpoint.

And replace $esp instances accordingly. Changing the mountpoint is immediate to anyone who wants to do so, so another pseudo-var isn't required.

In addition, it's confusing to those who wish to go with the recommended /boot mountpoint. -- Alad (talk) 10:33, 5 January 2016 (UTC)

While that could make sense, we'd create an inconsistency with all the other boot loader articles, which do use $esp as well: GRUB, Syslinux, EFISTUB and rEFInd. Personally, I don't think that using a variable like that is creating confusion, especially after [1]. — Kynikos (talk) 07:12, 9 January 2016 (UTC)
This would be potentially confusing to a user with $esp mounted at /efi (one of the three standard locations for $esp). Such a user would have both /boot and /efi. If they read the Wiki with your modifications, every time they read /boot they would have to translate it to /efi. The only problem is there's a few places where the Wiki really does mean /boot. How would they know not to do the translation there? PBS (talk) 12:11, 11 November 2021 (UTC)

Keys inside the boot menu, clarification

once you use keys to change timeout (-,T,+,t), this setting is saved in a non-volatile EFI variable; in this way `loader.conf` setting is overridden; a) how to clear the non-volatile EFI variable? b) how to show values of non-volatile EFI variables? --nTia89 (talk) 14:22, 27 May 2016 (UTC)
a) maybe reflashing the bios ^^ or efivar -w (be carefully you can brick your motherboard) b) also with efivar --name var -p
—This unsigned comment is by Fallback (talk) 21:13, 31 August 2017‎. Please sign your posts with ~~~~!

The section about Windows 8+ overriding boot settings is incorrect

I have a dual boot with Windows 10 and it does not override your boot settings or make Windows the default at each boot as explained in the wiki (it might during a major upgrade that work more or less as a new install, like Windows 8 -> Windows 10).

The fact is that, Windows normally manage the default boot efi file $esp\boot\efi\bootx64.efi and keep it identical to $esp/EFI/Microsoft/Boot/bootmgfw.efi . This file is often updated (I don't know if it is at every boot, but very often). The default installation of systemd-boot put also a copy of itself at the default $esp\boot\efi\bootx64.efi and this can gives a conflict because it will be overwritten by Windows. If we manage to correctly put a default boot entry in the firmware that is not $esp\boot\efi\bootx64.efi, there will be no problems. If we have a motherboard that can only boot $esp\boot\efi\bootx64.efi then and only then we are in trouble and the work around described in the wiki can make sense. It would be safer not touching $esp\boot\efi\bootx64.efi, I think Windows expect we do not touch this file.

—This unsigned comment is by Olive (talk) 21:28, 1 July 2016‎ (UTC). Please sign your posts with ~~~~!


add a section which talks about splash feature. --nTia89 (talk) 09:40, 9 July 2016 (UTC)

loader.conf: timeout 0?

Missing (for me) is what happens when "timeout 0" is set in loader.conf

—This unsigned comment is by Probackup-nl (talk) 11:09, 22 November 2017‎. Please sign your posts with ~~~~!

boot into windows once?

Does anyone know whether there is a way to reboot into windows once from linux using a command line. I.e. instead of "reboot", but "reboot-windows", which will boot into windows without me choosing anything at the boot menu. And on next reboot reboot into linux as the default sets?

—This unsigned comment is by Minxu (talk) 21:06, 28 January 2018‎. Please sign your posts with ~~~~!

run efibootmgr, note the number of the entry you want to boot next, run efibootmgr -n $number, that sets the boot entry as BootNext.Taifleh (talk) 11:20, 7 March 2018 (UTC)
You can use systemctl reboot --boot-loader-entry=<entry name> to directly boot a specific entry. However, this does not work with the auto-detected Windows Boot Loader, you have to create a boot entry. To list available options, run systemctl reboot --boot-loader-entry=help. The advantage is that you don't need efibootmgr installed. Might be worth to include in Systemd-boot#Choosing next boot? --help as mentioned there did not work for me. Qw3ry (talk) 08:58, 31 January 2020 (UTC)
Here, and at the time of this writing, bootctl is installed by systemd. With it, a regular user, and root, can record the id of the windows entry from the output of bootctl list. Suppose it is auto-windows. Then, as root, bootctl set-oneshot auto-windows will boot into windows once. Regid (talk) 18:37, 18 November 2021 (UTC)

arch.conf explanation could use some clearing up

Wouldn't it make a lot more sense to have the example options as `options root=/dev/sdxY rw` as opposed to some label? Also, in the explanation above it says `initrd=efipath` is a required option but I have never used this and booting into Arch works fine. Tonij (talk) 10:12, 5 December 2018 (UTC)

That's usually not a good idea, see Persistent_block_device_naming. -- Lahwaacz (talk) 23:03, 5 December 2018 (UTC)

System Rescue CD on ESP

Just like the already here "GRML on ESP" i tried to do the same with System Rescue CD (version 5.3.2). And unexpectedly it works! I followed the steps in the GRML section [2]:

- copied these files to


- added an entry

title   SRCD
linux   /srcd/rescue64
initrd  /srcd/initram.igz
options docache setkmap=it isoloop=srcd/systemrescuecd-x86-5.3.2.iso

Before promoting to the main page, I'd like to have some feedback, thank you.

nTia89 (talk) 08:02, 23 September 2019 (UTC)

Let's not do this. As you have (unconsciously? why would you expect it not to work?) noticed yourself, the GRML section serves as an example that can be generalized easily enough. Robg (talk) 15:14, 23 September 2019 (UTC)
It was unexpected to me because I have just used that instructions for SRCD but I do not know neither what those files do nor have a theoretical base... It could have been easily a fluke! That's the reason why I wrote here. If you know it is logic and generic to every other distro, I'd like to add it to the section: I do not want to add a section for SRCD, a section for another distro, etc. but rework the section making it generic and keep GRML as example, because currently the section does not talk about it is a generic procedure! nTia89 (talk) 15:38, 23 September 2019 (UTC)
It is not generic, but you can easily find out yourself what are the proper file names for the kernel image and initial ramdisk, as well as what are the required kernel options. This page certainly won't become what we had before on the Multiboot USB drive page, one example is more than enough. -- Lahwaacz (talk) 20:59, 23 September 2019 (UTC)
I absolutely agree with you Lahwaacz, a notice box is enough but needed as well. nTia89 (talk) 21:08, 23 September 2019 (UTC)
I can live with a notice. Why don't you add one, NTia89, and me or Lahwaacz will adjust it if necessary. A single sentence of the kind "the below example can be generalized to..." should do. Robg (talk) 12:40, 24 September 2019 (UTC)
Done nTia89 (talk) 12:51, 24 September 2019 (UTC)

Installation update XBOOTLDR

The current wiki page states the installation section is out of date

--path is no longer referenced inside of the bootctl man pages.

There are 2 new arguments to use instead (from the man pages of bootclt):

Path to the EFI System Partition (ESP). If not specified, /efi/, /boot/, and /boot/efi/ are checked in turn. It is recommended to mount the ESP to /efi/, if possible.
Path to the Extended Boot Loader partition, as defined in the Boot Loader Specification. If not specified, /boot/ is checked. It is recommended to mount the Extended Boot Loader partition to /boot/, if possible.

the Extended boot loader is labeled guid bc13c2ff-59e6-4262-a352-b275fd6f7172 or Linux Extended Boot

This --boot-path allows for a new partition to be created and systemd-boot can read from that as well as from the ESP

This Linux Extended Boot partition should still be formatted to vfat, though it should be able to read other file systems as well.

This means kernels are no longer required to be installed on the esp and can instead be held on the new /boot partition which systemd-boot is able to read

You can now mount the ESP to /efi then mount the new Linux Extened Boot Partion to /boot and create a loader entry in /boot/loader/entries/arch.conf and systemd-boot will be able to read and boot it.

Longer write ups written by me can be found on reddit and on the fourms

Info about XBOOTLDR can be found here

Thegreatzach (talk) 19:40, 6 April 2020 (UTC)


The systemd gpt auto generator will only mount partitions that are on the same physical device.

Meaning that the Extended Boot Loader partition must be on the same disk as the ESP


Thegreatzach (talk) 13:30, 29 May 2020 (UTC)

A reference to formatting the XBOOTLDR as FAT would be helpful. I couldn't find reference to making it FAT on any other Wiki page. Callmejoe (talk) 05:46, 13 April 2021 (UTC) Scimmia (talk) 11:41, 13 April 2021 (UTC)
nothing on that page that refers to linux extended boot partitions and how they should be formatted related to systemd-boot Callmejoe (talk) 13:25, 13 April 2021 (UTC)
You said nothing told you how to make a FAT partition. That page does. And stop marking your edits as 'minor'. Scimmia (talk) 05:31, 14 April 2021 (UTC)
Why would anyone check the filesystems page if you want to create a XBOOTLDR partition? I also searched for my issue, until I found a thread in the forum, which links to here. - Thus I agree with Callmejoe, add a note that the filesystem for XBOOTLDR must be FAT. Loader009 (talk) 15:34, 30 March 2022 (UTC)
The file system on XBOOTLDR is not limited to the ones that UEFI has builtin drivers for (i.e. FAT). Since systemd 250, systemd-boot supports loading UEFI drivers from the ESP. E.g. to use ext4 on XBOOTLDR, you just need to install efifs and copy /usr/lib/efifs-x64/ext2_x64.efi to esp/EFI/systemd/drivers/. -- nl6720 (talk) 10:32, 31 March 2022 (UTC)

add link to aur:kernel-install-hook

see kernel-install(8)

tldr - kernel-install runs scripts in /usr/lib/kernel/install.d or /etc/kernel/install.d. It automatically installs kernel and initramfs in $BOOT/<MACHINE-ID>/<KERNEL-VERSION>/kernel and $BOOT/<MACHINE-ID>/<KERNEL-VERSION>/initrd respectively. It also installs boot entry to $BOOT/loader/entries/<MACHINE-ID>-<KERNEL-VERSION>.conf.

The kernel-install-hookAUR automatically runs kernel-install when needed.

This works well for me for with both dracut and mkinitcpio for initramfs.

Also make sure you only have one initramfs generator installed, otherwise it might generate two initramfs.

ENV25 (talk) 16:00, 21 March 2021 (UTC)

I wrote a newer pacman hook. AUR: pacman-hook-kernel-installAUR
ENV25 (talk) 12:56, 20 July 2021 (UTC)

Update systemd-boot#Configuration to use automatic tools bundled with systemd

Systemd bundles the kernel-install tool (as noted by ENV25 above) which makes it very easy to manage multiple kernels among different installs on a single ESP. I propose we rewrite the current configuration section to include this as an automatic method in a subsection, and move the current contents to a subsection as a manual method. The automatic section would include topics like how to mask the default mkinitcpio pacman hook to stop the kernels installing to /boot/vmlinuz and /boot/initramfs.img, making/installing1 pacman hooks to move new kernels on install, and how to make an initramfs (since mkinitcpio -P will no longer work) and patch other scripts that may use mkinitcpio -P.

1My current intent is to use kernel-install-hookAUR for the automation part because it includes kernel-reconfigure which makes new initramfs for all kernels on the currently booted install, so users have a drop-in replacement for mkinitcpio -P

If there's any support for or objection to writing this section and moving the current content into a subsection I'd like to hear it.

Lsdaniel (talk) 01:49, 20 July 2021 (UTC)

So you want to add a section on how to disable defaults, install unsupported packages, and edit scripts, all to make things *easier*? Doesn't make a lot of sense to me.
Scimmia (talk) 02:30, 20 July 2021 (UTC)
If all you're going to do is rant, just keep it to yourself. -- Alad (talk) 09:42, 20 July 2021 (UTC)
Is kernel-install the officially suggested tool (by upstream) for kernel management with systemd-boot? If so, I suppose we can make it the main subsection under "Configuration". In any case, how about we include Lsdaniel's proposed explanations in a subsection following "Adding loaders"? We can always decide on making it the main subsection later on and for now focus on the content. Also, many thanks to Lsdaniel for the kind editorial offer! -- Robg (talk) 12:51, 20 July 2021 (UTC)
The AUR package is only pacman hook to automatically run kernel-install every kernel upgrade. It can be installed without the package.
"Editing scripts" is only needed to disable the mkinitcpio pacman hooks that genereate /boot/initramfs-linux.img. You do the same when you install dracut.
ENV25 (talk) 13:20, 20 July 2021 (UTC)

Potential removal of "Loader configuration" section

Just my two cents, but I don't see why the Loader configuration section would be removed from this page. This information is useful and immediately pertinent, and perhaps more to the point, the way it is set up appears to track the style guide's example for avoiding duplicated article content. Specifically, the style guide references the "Kernel parameters" page, and if we look at the "Parameter list" section, they've done the exact same thing as in this article. There is a somewhat shorter summary of important information, followed by a link to the man pages for more information if needed. Retnuh66 (talk) 20:34, 9 September 2021 (UTC)

I wouldn't say that it's "more to the point", it's almost a full duplication of the man page. I would perhaps understand if it listed the most important/common options, but it actually lists everything. Can anyone honestly claim they care about the random-seed-mode option? -- nl6720 (talk) 10:11, 14 October 2021 (UTC)
The fact that something on wiki is duplication of the man page is not a very good criteria for removal. A lot of useful things are in man pages. If man pages were that good at communicating information we wouldn't need wikis. I think this section is in the right place and when I was transitioning to systemd-boot it made a lot of sense to me. Unless there is a truly better way to describe the configuration, this section is in the right place with the right amount of information. It makes sense. (EDIT: I agree with your comment on random-seed-mode, but that is the only extra thing there. Could be left for completion sake as an exception that confirms the rule.) Romstor (talk) 15:27, 16 October 2021 (UTC)
Wikis are there to supplement man pages instead, not copy-paste them. Manuals are living documents, copying them here will only lead to outdated information and offers nothing new either. -- Alad (talk) 15:36, 16 October 2021 (UTC)

I do not think the section should be removed either. Linking to the Systemd documentation for further information is fine, but it is useful to have a sample config of the 'minimum requirements'. If a new user was installing systemd-boot just linking them to all off the different options in the config file seems overwhelming. It's nice to have a short, simple, and will get my Arch install booting config on this wiki page. Lot's of information on this page can be found in the corresponding systemd documentation as well, is that going to be removed as well? Take the section just above this one is that going to removed as well because "It can be found on this Systemd documentation page"? Thegreatzach (talk) 07:12, 12 December 2021 (UTC)

To clarify, no one is proposing to remove the whole section. I have nothing against the examples. The only thing that IMHO should be removed is the needless duplication of upstream docs. For systemd-boot#Loader configuration that was done in Special:Diff/699503. Now only systemd-boot#Adding loaders remains to be fixed. -- nl6720 (talk) 11:32, 14 December 2021 (UTC)

I also didn't understand why there were instructions on random-seed-mode. But it appears that this was removed within the past day or so.

Also, I'd like to propose that something be said about the need for adding loaders, perhaps at the end of the loader configuration section. When I first read this page, it wasn't at all clear to me that I had to add a loader in addition to configuring a loader. Configuring a loader entails already having a loader. How can we configure something that doesn't exist? Sure, the next section describes how to add a loader. But it isn't explicitly stated that this needs to be done. And it may very sensibly be thought that to add a loader is to add an additional loader. But this is not the correct interpretation, so we should take care to avoid such a one. Pound Hash (talk) 22:40, 24 December 2021 (UTC)

Initial ESP setup description is confusing

The first section has the following: "esp will be used throughout this page to denote the ESP mountpoint, e.g. /boot or /efi"

But the important bit about ESPs is only present after systemd-boot is installed and boot entry cofigured: "Note that entries in esp can only use files (e.g. kernels, initramfs, images, etc.) in esp. Similarly, entries in boot can only use files in boot."

I think this note should be a much more prominent _and_ earlier warning, as one could currently easily get the impression that a lone /efi mountpoint is possible without additional configuration, like is the case with GRUB and possibly other bootloaders.

C0rn3j (talk) 12:40, 1 November 2021 (UTC)

Confusing note

Under Updating the EFI Boot Manager section, we have:

Note: The boot manager is a standalone EFI executable and any version can be used to boot the system (partial updates do not apply, since pacman only installs the systemd-boot installer, not systemd-boot itself). However, new versions may add new features or fix bugs, so it is probably a good idea to update it anyway.

But what are we saying however to? The parenthesis? Or, any version booting the system? Do we have any cause to say it to either?

Pound Hash (talk) 05:41, 22 December 2021 (UTC)

This should all be removed soon, systemd v250 which should be out very soon has a new dedicated service to update the bootloader, which should be enabled by default.
--Cvlc (talk) 09:31, 22 December 2021 (UTC)
Why do you think systemd-boot-update.service will be enabled by default? -- nl6720 (talk) 16:12, 22 December 2021 (UTC)
Because upstream wrote so in the link above, but true I don't know what arch will do. Anyway default or not I'm just saying the paragraph will probably need changing. -- Cvlc (talk) 21:16, 22 December 2021 (UTC)

The loader.conf file only has one line

Specifically, under the loader configuration section, the last tip says,

A basic loader configuration file is located at /usr/share/systemd/bootctl/loader.conf

But on my fresh install, this file only contains the word Arch. It seems to barren in that file. Perhaps Arch would like some company? Perhaps Arch would like to have a purpose.

Pound Hash (talk) 05:59, 22 December 2021 (UTC)

/usr/share/systemd/bootctl/loader.conf actually has two words: default arch. Which means it will use arch.conf, the example of which is in /usr/share/systemd/bootctl/arch.conf. -- nl6720 (talk) 16:15, 22 December 2021 (UTC)