Difference between revisions of "Talk:Systemd-boot"

From ArchWiki
Jump to: navigation, search
m (splash)
 
(49 intermediate revisions by 18 users not shown)
Line 1: Line 1:
The link to documentation on freedesktop is currently giving a 503 and providing "guru meditation". Does anybody happen to be a guru and available to meditate on XID: 890648862? --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 03:22, 24 March 2013 (UTC)
+
== 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? [[User:Moviuro|Moviuro]] ([[User talk: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 {{ic|efiboomgr}} entry which appears when Windows is installed and the entries I defined manually. -- [[User:wget|wget]] ([[User talk: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. --[[User:Cschlote|Cschlote]] ([[User talk: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 [[User:Moviuro|Moviuro]] ([[User talk: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. --[[User:Cschlote|Cschlote]] ([[User talk:Cschlote|talk]]) 12:32, 23 March 2015 (UTC)
 +
:::: Well, this picture was taken on my Dell Latitude (E6430). [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 15:28, 23 March 2015 (UTC)
 +
 
 +
== $esp pseudo-var ==
 +
 
 +
I'd suggest replacing {{ic|$esp}} that's prominent in the article with the standard {{ic|/boot}}, i.e. replace
 +
:{{ic|$esp}} is used to denote the mountpoint in this article.
 +
with
 +
:In this article, {{ic|/boot}} is used as the mountpoint.
 +
And replace {{ic|$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 {{ic|/boot}} mountpoint. -- [[User:Alad|Alad]] ([[User talk: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 [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=414434&oldid=414433]. — [[User:Kynikos|Kynikos]] ([[User talk: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?  --[[User:NTia89|nTia89]] ([[User talk: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.
 +
 
 +
== splash ==
 +
 
 +
add a section which talks about splash feature.  --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:40, 9 July 2016 (UTC)

Latest revision as of 09:40, 9 July 2016

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

with

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.

splash

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