From ArchWiki
(Redirected from Talk:Gummiboot)
Jump to: navigation, search

About reboot into firmware configuration interface

If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? Moviuro (talk) 12:41, 15 March 2015 (UTC)

AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected efiboomgr entry 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) 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 already found several real machines, which will either show none of these entries, or just one of them. Only a VM shows all entries. --Cschlote (talk) 12:32, 23 March 2015 (UTC)
Well, this picture was taken on my Dell Latitude (E6430). Moviuro (talk) 15:28, 23 March 2015 (UTC)

$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)

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)

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.


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

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.

Fix this. I tried, but it got removed saying the tone was incorrect. Murphy (talk) 22:58, 27 August 2016 (UTC)

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)
There definitely needs to be a notice somewhere in the header that just installing the coreboot doesn't give you what you need. If one inspects the directory, you'll see a default, the directories, etc. It's not obvious, and if you miss the step, then it's really not going to be obvious at all what's broken. If the warning isn't in the header, it should be somewhere in the installation section, stating that a standard installation doesn't use one of the X set of tools and manual intervention will be required unless you're positive it doesn't. I maintain my position that the notes section is disorganized and it doesn't give the impression that there's a possible required step just to get the computer to boot. Murphy (talk) 17:59, 28 August 2016 (UTC)
Edh added this to the Installation section, which you say suffices. We don't need to make the last point a big red warning as the previous points would have to be red as well, which would completely defeat the purpose. -- Lahwaacz (talk) 18:30, 28 August 2016 (UTC)
Perfect. That makes a lot of sense. Thanks for listening to my whining! Murphy (talk) 20:47, 28 August 2016 (UTC)