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.
loader.conf: timeout 0?
Missing (for me) is what happens when "timeout 0" is set in loader.conf
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?
- 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)