- 1 About reboot into firmware configuration interface
- 2 $esp pseudo-var
- 3 Keys inside the boot menu, clarification
- 4 The section about Windows 8+ overriding boot settings is incorrect
- 5 splash
- 6 loader.conf: timeout 0?
- 7 boot into windows once?
- 8 objcopy use with intel-ucode.img
- 9 arch.conf explanation could use some clearing up
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)
objcopy use with intel-ucode.img
- Well, this was a kind of obvious solution. Thank you for sharing! Taifleh (talk) 09:58, 7 March 2018 (UTC)
I'm still having problems with this. Since we incorporate the ucode and initramfs within the binary EFI file, how do we reference it in the kernel-command-line.txt? What is the expected syntax for that file? Is it the same as /proc/cmdline contains? What about escaping the backslash character? I feel like this should be explained somewhere. When I try this, the kernel commandline is not being processed. Boot fails for my root partition cannot be mounted to /new_root. So initramfs is being loaded, and ucode is loaded as well. So it seems, it's not neccessary to mention initrd parameters in the kernel-command-line.txt. So how do I add my parameters (root=UUID=someuuid)... ? Taifleh (talk) 15:32, 7 March 2018 (UTC)
All you need to do is to concatenate the ucode file and your initrd with the ucode file being first. Then you use that combined file as I initrd. No need to for kernel command line arguments or anything. Hunger
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)