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)
- 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.
Move section "Non-root drives are not decrypted by sd-lvm2 mkinitcpio hook"
I've added it here after experiencing the issue when switching
mkinitcpio to use
systemd hooks instead of "regular" ones. I'm not sure how I got the idea that it's a necessary step when using
systemd-boot. It's not: the systemd-boot page mostly assumes "regular"
mkinitcpio hooks. This section is indeed misplaced.
- Or perhaps some other page's sub-section on
mkinitcpio?.. -- Veox (talk) 15:42, 27 October 2017 (UTC)
- To be honest, I'm not even sure if this isn't a bug with
sd-encrypthook. Sorry for the noise. :( -- Veox (talk) 15:54, 27 October 2017 (UTC)
loader.conf: timeout 0?
Missing (for me) is what happens when "timeout 0" is set in loader.conf