About reboot into firmware configuration interface
- AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected
efiboomgrentry which appears when Windows is installed and the entries I defined manually. -- wget (talk) 13:08, 15 March 2015 (UTC)
- I spent some time googleing about this issue. Without success. So it would save time and pain to add some working example. It's a useful feature. --Cschlote (talk) 00:26, 16 March 2015 (UTC)
- http://wstaw.org/w/3gSV/ And I don't have a Reboot into device firmware entry, nor the EFI default loader Moviuro (talk) 22:35, 21 March 2015 (UTC)
I'd suggest replacing
$esp that's prominent in the article with the standard
/boot, i.e. replace
$espis used to denote the mountpoint in this article.
- In this article,
/bootis used as the mountpoint.
$esp instances accordingly. Changing the mountpoint is immediate to anyone who wants to do so, so another pseudo-var isn't required.
- 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 . — Kynikos (talk) 07:12, 9 January 2016 (UTC)
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)
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.
manual configuration summary
Add a note in the title that manual configuration is required for the system to start. It is totally unclear from the introduction and even halfway into the configuration that any manual intervention is required other than installing the bootloader.
Mentioning that it's required is in a supporting clause halfway down the page, when it should be right up front indicating to the user that they're going to have to do some work to install.
- Done with this edit. Your notice did not belong in the introduction plus it is common for software to only function with prior configuration and the Systemd-boot#Configuration section covers the need completely. Though I admit the importance should be emphasized in this case since it is an essential part for the system to start. -- Edh (talk) 23:15, 27 August 2016 (UTC)