[erledigt] UEFI-Installation: "grub-install dummy" hängt

[smutbert]

[…]
Wenn der Boot-Eintrag wirklich automatisch erstellt wird, woher weiß das UEFI dann, dass er "Linux" heißt? (Könnte natürlich ein Feature von Secure-Boot sein, das ich nicht kenne). Und wenn der Boot-Eintrag automatisch erstellt wird, warum wird er nicht erstellt, wenn Debian bootet? (Ich gehe davon aus, dass die Endless HDD dabei weiterhin am USB-Port hing)

hikaru, wie bootest du überhaupt das Endless OS, wenn F2 nicht geht?

Ich bin im Gegenteil davon ausgegangen, dass zumindest beim Booten von Debian die externe HDD nicht angeschlossen war...

Wie der Eintrag automatisch erstellt wird, weiß ich auch nicht, aber das automatische Erstellen schließe ich schlicht aus dem Auftauchen und Verschwinden des Eintrags. (und ich kenne ähnliches auch von anderen uefi-Systemen, dass sie zumindest das ursprünglich vorinstallierte System erkennen und einen Booteintrag dafür anlegen. In dem Fall ist es vielleicht sogar relativ einfach, weil shim.efi ja signiert sein muss und im BIOS/UEFI beliebige Metainformationen zum zwangsweise hinterlegten zugehörigen öffentlichen Schlüssel vorhanden sein könnten?)


Mir scheint es langsam so wäre die Behauptung aus dem Thread im Ubuntuforum, den ich in der ersten Antwort verlinkt habe, dass Secure Boot aktiviert sein muss richtig sein könnte (da habe ich zwar nur als Lösung für das Hängenbleiben bei der grub-Installation verstanden, aber es wäre kein Wunder, wenn das auch das F2-Problem lösen würde).
Allerdings selbst wenn es stimmt, weiß ich nicht wie man unter Debian mit dieser Information umgeht. Sich den kompletten grub samt secure boot shim von endless OS (oder auch Ubuntu?) ausborgen, klingt mir nicht sehr verlockend und eigentlich weiß ich auch gar nicht wie sich die Kombination von signiertem Bootloader und unsigniertem Kernel überhaupt verhält (sonst wäre ja vielleicht auch eine refind-Installation auf der SSD ein möglicher Workaround).

[NAB]

smutbert, kurzfristig ging ja alles, nämlich hier:
viewtopic.php?f=12&t=169061#p1168614
Das ist der Punkt, den ich momentan interessant finde. Über Alternativen kann man natürlich auch nachdenken ... da würd ich mir erst Refind angucken und dann Secure Boot (und die Pakete eher von Ubuntu klauen). Einen BIOS Boot von GPT könnte man auch noch testen.

Endless:

Code: Alles auswählen

Boot0001* Linux	HD(1,800,1f000,7e4d7ae3-0837-41bb-8f04-4c61291b261e)File(\EFI\endless\shim.efi)RC

Diesen Eintrag finde ich immer noch interessant. Im Gegensatz zu smutbert habe ich Zweifel, dass der automatisch vom UEFI erzeugt wird. Ich würd mich ja freuen, wenn das UEFI mir beliebige Bootloader auf der ESP Partition automatisch zusammensucht, aber leider tun sie das bei mir nie. Und warum er sich ausgerechtnet den \endless\shim.efi rauspicken sollte, ist mir auch nicht klar. Mag natürlich sein, dass das ein besonderer Service von Secure Boot ist, das ist aber eigentlich ausgeschaltet.

hikaru, wie ist das jetzt eigentlich genau? Wenn du Endless OS bootest (mit der Debian SDD angeschlossen), dann ist dieser Eintrag da. Wenn du Debian bootest, ohne Endless HDD, dann ist dieser Eintrag nicht da. Und wenn du Debian bootest, mit angeschlossener Endless HDD, was passiert dann?

Was ich nicht verstehe ist, dass doch genau das aber gestern den größten Teil des Abends funktioniert haben muss. Ich habe mich da noch nicht für die Inhalte von /boot/efi interessiert, aber die müssen doch auch von Debians grub-install gestammt haben und da ging sowohl UEFI als auch Booten.

Deinen Aufzeichnungen nach hat Xubuntu das UEFI kaputt gemacht (oder eventuell Endless). Fragt sich, was ein Live System am UEFI rumzufummeln hat, aber irgendwas muss es verändert haben.

Ich habe die dünne Theorie, dass es im UEFI eventuell unsichtbare Einträge gibt. Dass der Endless Eintrag zum Beispiel dauerhaft gespeichert ist, aber nur angezeigt wird, wenn die Endless HDD vorhanden ist. Ebenso könnte Xubuntu so einen Eintrag hinterlassen haben und dieser stört nun irgendwie, auch wenn man ihn nicht sehen kann. Ein Live System würde hier übrigens den removable media path /EFI/BOOT/BOOTX64.EFI benutzen - genau den, der jetzt plötzlich Ärger macht.

Was würde das bedeuten? Weiß nicht so genau. Es würde zumindest bedeuten, dass man doch (irgendwie) feste Einträge im UEFI speichern kann. Eventuell kann man sie dann auch wieder löschen. (Apropos, gibt es ein "Reset to defaults" im UEFI? Oder ein "Reset NVRAM"?). Eventuell kann man dann auch seinen eigenen konfliktfreien Eintrag hinzufügen, zum Beispiel /EFI/debian/grubx64.efi und dafür könnte man das störende /EFI/BOOT/BOOTX64.EFI löschen.

Aber wer entwickelt einen Standard in dem sowas überhaupt möglich ist und traut sich dann auch noch, den zu veröffentlichen?

Deswegen heißt es Extensible Firmware Interface. Du darfst die Erweiterung einbauen, dass es mittendrin irreparabel abschmiert. Man sollte solche Extra-Featues nur groß auf die Verpackung schreiben.

[hikaru]

Mir scheint es langsam so wäre die Behauptung aus dem Thread im Ubuntuforum, den ich in der ersten Antwort verlinkt habe, dass Secure Boot aktiviert sein muss richtig sein könnte (da habe ich zwar nur als Lösung für das Hängenbleiben bei der grub-Installation verstanden, aber es wäre kein Wunder, wenn das auch das F2-Problem lösen würde).

Das habe ich vorhin mal probiert. Nachdem ich /boot/efi/EFI/BOOT/BOOTX64.EFI in Debian entfernt hatte, kam ich ja wieder in's UEFI. Da habe ich dann im UEFI /Boot/Secure Boot [Enabled|Disabled] aktiviert. Daraufhin kam ich sowohl mit als auch ohne BOOTX64.EFI in's UEFI, aber Debian bootete von der SSD in keinem Fall, sondern nur via rEFInd.
Nach dem Aktivieren von Secure Boot werden im UEFI folgende Optionen aktiv geschaltet:

Code: Alles auswählen

/Security/Secure Boot Mode/Erase all Secure Boot Settings: [Enter] -> [Yes|No]
/Security/Secure Boot Mode/Select an UEFI file as trusted for executing: [Enter] -> [Minimaler Dateibrowser der wohl alle gefundenen EFI-Partitionen nach *.efi-Dateien durchsucht]
/Security/Secure Boot Mode/Restore Secure Boot to Factory Default: [Enter] -> [Yes|No]

Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert. Nach einem Reboot zeigte sich wieder die Acer-Grub-Shell und teilte noch vor dem Prompt mit, dass das Laden dieses Eintrags nicht erlaubt sei. Ich habe dann das Gleiche mit dem Removable-Eintrag probiert, aber weil ich dafür unkreativerweise den selben Namen verwenden wollte wurde mir das verweigert.
Da ich weder über die erste noch die dritte Option aus dem Code-Block den Debianeintrag wieder deregistrieren konnte, wollte ich da nicht weiter rumspielen, denn ich habe dunkel in Erinnerung, das so ein UEFI-Eintragsspeicher recht schnell voll sein kann.
Eine Eintrag für Endless taucht hier nicht auf.

Allerdings selbst wenn es stimmt, weiß ich nicht wie man unter Debian mit dieser Information umgeht. Sich den kompletten grub samt secure boot shim von endless OS (oder auch Ubuntu?) ausborgen, klingt mir nicht sehr verlockend und eigentlich weiß ich auch gar nicht wie sich die Kombination von signiertem Bootloader und unsigniertem Kernel überhaupt verhält (sonst wäre ja vielleicht auch eine refind-Installation auf der SSD ein möglicher Workaround).

Sowas Ähnliches habe ich möglicherweise zwischendurch probiert. Ich hatte mal sämtliche Inhalte der Endless-EFI-Partition auf die Debian-Partition kopiert. Das wurde als Bootoption erkannt, bootete aber nicht. Danach habe ich das BOOTX64.EFI von Debian wiederhergestellt, den Rest von Endless aber belassen. Auch das bootete nicht. An die genauen Fehlermeldungen erinnere ich mich nicht. Erst als ich wieder alle Endless-Inhalte gelöscht hatte, bootete Debian wieder.

Auch ohne Secure Boot scheint /EFI/debian/grubx64.efi übrigens wirkungslos zu sein. Es geht nur mit dem Removable-Eintrag. grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.

smutbert, kurzfristig ging ja alles, nämlich hier:
viewtopic.php?f=12&t=169061#p1168614
Das ist der Punkt, den ich momentan interessant finde.

Genau das ist es, was mich momentan umtreibt. Ich weiß, DASS UEFI-Zugang UND Debian-Boot irgendwie gehen muss, denn ich habe es gesehen.
An sich ist der aktuelle Zustand kein Beinbruch, denn eigentlich muss ich ja nicht in's UEFI , und falls doch mal, weiß ich wie ich da hinkomme (BOOTX64.EFI löschen) und hinterher einfach wieder ein bootfähiges Debian kriege (BOOTX64.EFI-Backup wieder zurückspielen). Mich macht nur diese dreckige Lösung wuschig.

Und wenn du Debian bootest, mit angeschlossener Endless HDD, was passiert dann?

Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!
efibootmgr sagt in dem Fall das:

Code: Alles auswählen

# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G	PciRoot(0x0)/Pci(0x12,0x0)/Sata(0,0,0)/HD(1,GPT,f72ce1d4-210b-4267-9d64-34e991a61ef7,0x800,0xf3800)RC
Boot0001* Linux	HD(1,GPT,7e4d7ae3-0837-41bb-8f04-4c61291b261e,0x800,0x1f000)/File(\EFI\endless\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

Ich habe die dünne Theorie, dass es im UEFI eventuell unsichtbare Einträge gibt. Dass der Endless Eintrag zum Beispiel dauerhaft gespeichert ist, aber nur angezeigt wird, wenn die Endless HDD vorhanden ist. Ebenso könnte Xubuntu so einen Eintrag hinterlassen haben und dieser stört nun irgendwie, auch wenn man ihn nicht sehen kann. Ein Live System würde hier übrigens den removable media path /EFI/BOOT/BOOTX64.EFI benutzen - genau den, der jetzt plötzlich Ärger macht.

Was würde das bedeuten? Weiß nicht so genau. Es würde zumindest bedeuten, dass man doch (irgendwie) feste Einträge im UEFI speichern kann. Eventuell kann man sie dann auch wieder löschen. (Apropos, gibt es ein "Reset to defaults" im UEFI?

Wie gesagt, die Optionen die im UEFI nach Löschen von Einträgen aussehen, haben offenbar keinen Effekt und das mit dem Hinzufügen war auch nicht wirklich zielführend.


Info am Rande:
Acer bietet als neueste UEFI-Version 1.03 zum Download an. Auf meinem System läuft die gleiche Version.

[NAB]

Da habe ich dann im UEFI /Boot/Secure Boot [Enabled|Disabled] aktiviert. Daraufhin kam ich sowohl mit als auch ohne BOOTX64.EFI in's UEFI, aber Debian bootete von der SSD in keinem Fall, sondern nur via rEFInd.

Also Refind lässt dich mit Secure Boot booten? (wobei F2 funktioniert). Das ist ja interessant. Refind sollte man im Hinterkopf behalten, das gibt's auch als Debian Paket in den Repos. Ich habe nur keine Ahnung, wie man es installiert und konfiguriert.

Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert.

Ist dieser Eintrag "persistent"? Also ist er immer noch da? (obwohl er nicht funktioniert, da nicht signiert)

Falls er noch da ist ... und du mit aktiviertem Secure Boot Endless OS bootest (das geht doch, oder?) - zeigt der efibootmgr diesen Eintrag an? Kannst du ihn mit efibootmgr löschen?

Da ich weder über die erste noch die dritte Option aus dem Code-Block den Debianeintrag wieder deregistrieren konnte,

*hmpf* ... das wäre so die erste leicht nachvollziehbare Fehlfunktion, die man als Bug an Acer melden könnte ...

Nach einem Reboot zeigte sich wieder die Acer-Grub-Shell und teilte noch vor dem Prompt mit, dass das Laden dieses Eintrags nicht erlaubt sei.

Ach ja ... ist dieser komische Grub nun wirklich von Acer? Als du die Efi-Partition gelöscht hattest und er somit gar nichts zum Booten gefunden hat, erschien dieser Grub da auch?

Danach habe ich das BOOTX64.EFI von Debian wiederhergestellt, den Rest von Endless aber belassen. Auch das bootete nicht. An die genauen Fehlermeldungen erinnere ich mich nicht. Erst als ich wieder alle Endless-Inhalte gelöscht hatte, bootete Debian wieder.

Das wird ja immer kurioser. Das klingt, als ob er wirklich den Inhalt der Efi-Partition scannt (smutberts Theorie) und den Boot verweigert, wenn er etwas findet, was ihm nicht passt. Eventuell wäre es interessant, die Endless-Dateien (und Verzeichnisse) sukzessiv zu löschen, dann wüsste man, welche Datei ihn stört - und damit auch, auf welche Datei er achtet.

grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.

Der grubx64.efi könnte unfertig sein. Ich hab grad mal auf zwei Systemen verglichen, bei beiden ist der grubx64.efi unterschiedlich groß. Das eine System fährt / auf Raid, das andere nicht (so als Erklärungsversuch). Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?

Hängt grub-install auch mit "--no-nvram"?

Zunächst mal ist dann auch das UEFI zugänglich, wenn die Endless-HDD angeschlossen ist - warum auch immer. Danke für den Vorschlag!

Es wird wirklich immer kurioser ...

Code: Alles auswählen

Boot0001* Linux	HD(1,GPT,7e4d7ae3-0837-41bb-8f04-4c61291b261e,0x800,0x1f000)/File(\EFI\endless\shim.efi)RC

Aus meiner Sicht besteht immer noch die Frage, ob das UEFI diesen Pfad irgendwo fest gespeichert hat und nur einblendet, wenn er existiert, oder ob dieser Pfad jedes mal dynamisch neu erzeugt wird. Wenn er wirklich dynamisch neu erzeugt wird, dann frage ich mich, warum er ausgerechnet \endless\shim.efi nimmt und nicht BOOT\BOOTX64.EFI. Wenn er hingegen fest gespeichert ist, dann wäre auch die UUID (7e4d7ae3- ...) fest gespeichert. Das würde erklären, warum das UEFI zufrieden ist, wenn es \endless\shim.efi auf der richtigen UUID entdeckt und sich sperrt, wenn \endless\shim.efi auf der falschen UUID liegt.

Dabei fällt mir das Xubuntu wieder ein und die Frage, was es angerichtet haben könnte. Kannst du das mal anstöpseln, dann Debian booten und den efibootmgr befragen? Wenn du dabei einen Pfad entdeckst, der nicht der removable media path ist, dann versuche den mal mit dem efibootmgr zu löschen.

[hikaru]

Also Refind lässt dich mit Secure Boot booten? (wobei F2 funktioniert).

Das habe ich gerade probiert:
rEFInd-Stick dran und versucht in's EFI zu kommen, um Secure Boot einzuschalten. Das klappte nicht.
Also rEFInd-Stick und Endless-HDD angestöpselt und ich komme in's UEFI. Dann habe ich Secureboot aktiviert und ohne Eingriff in den Bootprozess mit rEFInd-Stick aber ohne Endless-HDD gebootet und es kam der Debian-Grub hoch, nicht der von Acer und auch nicht rEFInd.
Langsam habe ich das Gefühl, dass die Secure-Boot-Option im UEFI zwar irgendwas hin- und herschaltet, das teilweise das Verhalten beim Boot beeinflusst, dass aber Secure Boot an sich nicht für den Unterschied verantwortlich ist.

Über die zweite Option habe ich dann /EFI/debian/grubx64.efi aus dem Debian-EFI registriert.

Ist dieser Eintrag "persistent"? Also ist er immer noch da? (obwohl er nicht funktioniert, da nicht signiert)

Jetzt ist er weg.
Vielleicht brauchte es den Poweroff über Nacht oder so. Es kann sein, dass ich gestern Abend beim Testen nur Reboots gemacht habe.

Ach ja ... ist dieser komische Grub nun wirklich von Acer? Als du die Efi-Partition gelöscht hattest und er somit gar nichts zum Booten gefunden hat, erschien dieser Grub da auch?

Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer. Erst kommt das Acer-Logo wie man es schon aus Legacy-Zeiten zum Verstecken des POST kennt, dann wird über das Acer-Logo die Grub-Shell eingeblendet. Das Acer-Logo ist hier also das Hintergrundbild von Grub. Und es lässt sich grafisch kein Übergang zwischen POST und Grub ausmachen.

Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?

Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.

Hängt grub-install auch mit "--no-nvram"?

Nein. Aber das ändert auch nichts am Bootverhalten.

Dabei fällt mir das Xubuntu wieder ein und die Frage, was es angerichtet haben könnte. Kannst du das mal anstöpseln, dann Debian booten und den efibootmgr befragen?

Code: Alles auswählen

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,2001,2002,2003
Boot0000* HDD: SanDisk SDSSDHP128G      PciRoot(0x0)/Pci(0x12,0x0)/Sata(0,0,0)/HD(1,GPT,f72ce1d4-210b-4267-9d64-34e991a61ef7,0x800,0xf3800)RC
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Interessanterweise wird seit dem eben durchgeführten Secure-Boot-Experiment der Ubuntu-Stick nicht mehr als Bootoption erkannt, selbst wenn ich Secure Boot wieder ausschalte.

Das habe ich ganz zum Schluss gemacht:

Das klingt, als ob er wirklich den Inhalt der Efi-Partition scannt (smutberts Theorie) und den Boot verweigert, wenn er etwas findet, was ihm nicht passt. Eventuell wäre es interessant, die Endless-Dateien (und Verzeichnisse) sukzessiv zu löschen, dann wüsste man, welche Datei ihn stört - und damit auch, auf welche Datei er achtet.

Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709

Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*
Dann habe ich Endless von der HDD gebootet und auf der Debian-SSD das EFI/endless/bootx64.efi gegen EFI/debian/bootx64.efi ersetzt. Damit klappt sowohl der Debian-Boot als auch der UEFI-Zugriff beim Booten.
Als nächstes habe ich aus dem endless-Verzeichnis alle Dateien außer bootx64.efi gelöscht. Damit konnte ich booten, aber nicht in's UEFI.
Dann habe ich shim.efi wiederhergestellt und es ging wieder Beides. Die gleiche Konstellation in BOOT/ oder debian/ statt endless/ führte zwar zu funktionierendem UEFI, aber es war kein Booten mehr möglich.

Aktuell habe ich nur EFI/endless/grubx64.efi (von Debian) und EFI/endless/shim.efi (von Endless), kein BOOT/ oder debian/ und alles funktioniert soweit.
Ich vermute momentan, dass das UEFI die Datei EFI/endless/shim.efi an eben dieser Stelle haben möchte um zugreifbar zu sein, falls auch ein bootx64.efi auf der selben Partition gefunden wird. Das Booten läuft dann über bootx64.efi, dessen Position im EFI-Pfad eigentlich nebensächlich ist, wobei die Suche aber nach dem Finden von EFI/endless/shim.efi nicht neu initialisiert wird, weshalb letztendlich doch beide Dateien im endless-Verzeichnis stehen müssen.
So richtig traue ich dem Frieden aber noch nicht. Dafür ist mir das Verhalten noch viel zu undurchsichtig. Gibt es sowas wie einen Decompiler für *.efi-Dateien um mal zu schauen, was in dem shim.efi drin steht?


*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/

[NAB]

rEFInd-Stick dran und versucht in's EFI zu kommen, um Secure Boot einzuschalten. Das klappte nicht.
Also rEFInd-Stick und Endless-HDD angestöpselt und ich komme in's UEFI. Dann habe ich Secureboot aktiviert und ohne Eingriff in den Bootprozess mit rEFInd-Stick aber ohne Endless-HDD gebootet und es kam der Debian-Grub hoch, nicht der von Acer und auch nicht rEFInd.

Hmm ... dann scheint "dein" Refind Secure Boot tauglich zu sein. Ich weiß nicht, wie es mit dem von Debian steht, aber eventuell kann man sich mit dem eine "nur Debian"-Lösung basteln.

Langsam habe ich das Gefühl, dass die Secure-Boot-Option im UEFI zwar irgendwas hin- und herschaltet, das teilweise das Verhalten beim Boot beeinflusst, dass aber Secure Boot an sich nicht für den Unterschied verantwortlich ist.

Ich habe eher den Eindruck, dass Secure Boot nach dem Ausschalten nicht wirklich komplett ausgeschaltet ist. Er scheint weiterhin nach einem (signierten?) Secure-Boot-Bootloader zu suchen (ohne den geht F2 nicht). Es fragt sich weiterhin, ob das ein bestimmter im UEFI hinterlegter Bootloader ist, oder ob er sich selbstständig "irgendeinen" auf der Platte sucht.

Nach deinem folgenden Kommentar fragt sich aber auch, ob man das so sicher sagen kann, ohne jeweils einen Kaltstart ausgeführt zu haben. Eigentlich müsste man sämtliche Experimente mit einem "Power-Off" dazwischen wiederholen.

Bei Desktop-UEFIs beobachte ich übrigens oft folgendes Verhalten: Bei manchen (nicht allen) Änderungen am UEFI wird mir erst eine Liste aller von mir getätigten Änderungen angezeigt, dann führt das Gerät einen Reboot durch, und an der Stelle, an der der Bootloader gestartet werden sollte, folgt ein weiterer Reboot, der dann "normal" verläuft. Das sieht für mich so aus, als ob bei Änderungen am UEFI ein neuer Boot-Eintrag mit "Änderungsaufträgen" und einem "Reboot" am Ende erzeugt wird. Ich schließe daraus, dass Änderungen im UEFI eine sehr komplizierte Sache sind.

Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer.

Das ist aus zwei Gründen interessant:
1) Warum ist der da? Wofür mag der gut sein? Kann man den selber irgendwie nutzen? (Nein, ich habe keine Antworten)
2) Wie war das noch mit der GPL? Müsste Acer dann nicht den Quellcode dazu anbieten?

Ist dein grubx64.efi identisch zu deinem BOOT/BOOTX64.EFI?

Ja. Die Dateigrößen stimmen überein. Ich habe einmal sogar die Datei zwischen BOOT/ und debian/ hin- und herkopiert.

Hängt grub-install auch mit "--no-nvram"?

Nein. Aber das ändert auch nichts am Bootverhalten.

Das meinte ich nicht.
Das ist aus zwei Gründen interessant:
1) Grub schreibt bei der Installation vor dem Aufhängen einen kompletten Bootloader, hängt sich also erst danach auf (du erinnerst dich, damit fing der Thread an). Das "danach" hat dann höchstwahrscheinlich mit dem Schreiben ins NVRAM zu tun.
2) Das Blacklisten der efivar-Module nach smutberts Anleitung führt entweder nicht zum gewünschten Ergebnis oder wurde von dir falsch durchgeführt oder "grub-install" lädt diese Module dann trotzdem "hintenrum".

Nebenbei fällt mir gerade noch ein, dass du auf Seite 1 von Kernel-Panics berichtet hast. Wenn man die (ohne "--no-nvram") reproduzieren kann, reicht's vielleicht für einen qualifizierten Kernel Bug.

Interessanterweise wird seit dem eben durchgeführten Secure-Boot-Experiment der Ubuntu-Stick nicht mehr als Bootoption erkannt, selbst wenn ich Secure Boot wieder ausschalte.

Huch? Es wird wirklich immer kurioser. Eventuell hilft ein Power-Off dagegen?

Ob der Ubuntu-Stick sich selbst beschädigt hat, kannst du mangels weiterer UEFI-Maschine nicht testen, oder? Aber einen Blick auf die Efi-Partition und den removable media path müsstest du werfen können. Findest du dort die gleich erwähnte PARTUUID?

Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709

Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*

*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/

Uff ... ich weiß jetzt wesentlich mehr über EFI Binaries als ich jemals wissen wollte. Aber ich denke, du bist auf dem Holzweg. Stimmt, EFI nutzt UUIDs als Funktionsreferenz. Aber auch in gewöhnlicher Weise um Partitionen zu identifizieren. Die Meldung oben sieht mir viel zu sehr nach einem gewöhnlichen Grub-Fehler aus, der seine Partition nicht finden kann.

Auf einem funktionierenden UEFI wirst du feststellen, dass die UUIDs in den Booteinträgen von "efibootmgr -v" identisch sind zu den PARTUUIDs, die blkid anzeigt. Die PARTUUIDs stehen in der GPT, sind also von der Partitionstabelle abhängig und nicht vom Dateisystem.

Ich bin mir ziemlich sicher, dass Grub hier eine PARTUUID sucht. Die PARTUUID lässt sich ändern:
https://bbs.archlinux.org/viewtopic.php?id=215541
man könnte ihm also geben, wonach er sucht. Interessanter wäre aber mMn, wo diese "4f68-bce3-e8cd-4db1-96e7fbcaf984b709" steht. Hardcodiert im Acer-Grub? Versteckt und änderbar im NVRAM? Oder in einem der Bootloader von Endless oder Debian (woher auch immer). Du könntest auf der Platte und im Acer-BIOS-Update danach suchen.

Dann habe ich Endless von der HDD gebootet und auf der Debian-SSD das EFI/endless/bootx64.efi gegen EFI/debian/bootx64.efi ersetzt. Damit klappt sowohl der Debian-Boot als auch der UEFI-Zugriff beim Booten.
Als nächstes habe ich aus dem endless-Verzeichnis alle Dateien außer bootx64.efi gelöscht. Damit konnte ich booten, aber nicht in's UEFI.
Dann habe ich shim.efi wiederhergestellt und es ging wieder Beides. Die gleiche Konstellation in BOOT/ oder debian/ statt endless/ führte zwar zu funktionierendem UEFI, aber es war kein Booten mehr möglich.

Aktuell habe ich nur EFI/endless/grubx64.efi (von Debian) und EFI/endless/shim.efi (von Endless), kein BOOT/ oder debian/ und alles funktioniert soweit.

Hmm .. so als grobe Hypothese: Entweder
1) sucht das UEFI trotz ausgeschaltetem Secure Boot einen signierten Bootloader (smutberts Theorie), findet den unter /endless/shim.efi (sonst geht F2 nicht) und /endless/shim.efi will dann einen hardcodierten Pfad laden *a).
oder
2) der Pfad /endless/shim.efi ist irgendwo gespeichert (wo?!?) (meine Theorie), wird geladen wenn er gefunden wird und /endless/shim.efi will dann wieder einen hardcodierten Pfad laden *a).

*a) Welchen hardcodierten Pfad? Aus der Beschreibung von Shim (siehe unten) ergeben sich zwei Möglichkeiten.
a1) Shim sucht in <aktuelles Verzeichnis>/grubx64.efi (oder sucht generell eine Datei grubx64.efi in der Efi Partition, das halte ich für unwahrscheinlich).
a2) Acer benutzt einen manipulierten Shim, der nach /endless/grubx64.efi sucht.

Soweit ich das Chaos hier überblicke: wenn man shim.efi und Debians grubx64.efi in ein anderes Verzeichnis packt, dann funktioniert es nicht. Das schließt eine Kombination von 1) und a1) eigentlich aus. Den Rest kann man herausbekommen.

Gibt es sowas wie einen Decompiler für *.efi-Dateien um mal zu schauen, was in dem shim.efi drin steht?

Die Frage ist, wie lange sowas dauert und was es bringt. Reverse Engineering ist ziemlich aufwändig, wie dein Artikel eindrucksvoll zeigt. Wenn du erst nach Buster fertig bist, kannst du genau so gut auch den bis dahin hoffentlich funktionierenden Secure Boot Support von Buster nutzen.

Der Punkt an Shim ist, dass es von Microsoft signiert und somit binär unveränderbar ist, und das meineswissens seit 2012:
http://www.codon.org.uk/~mjg59/shim-signed/
Das Readme führt dich hierhin:
https://mjg59.dreamwidth.org/20303.html
wenn man das wörtlich nimmt, dann muss Shim in /EFI/BOOT liegen ... das scheint zumindest hier nicht so ganz zu stimmen - zumindest nicht für den Fall "Secure Boot ausgeschaltet".

Du könntest dir erst mal irgendein anderes shim.efi besorgen und das mit deinem von Endless OS vergleichen. Wenn beide binär identisch sind, dann hat Acer hier zumindest nichts eigenes gebacken und du kannst den öffentlichen Quellcode von Shim sichten.

Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi

Falls das klappt, hätten wir EFI/endless/shim.efi durch den anscheinend priorisierten removable media path umgangen, aber immer noch nicht geklärt, warum das UEFI den Pfad EFI/endless/shim.efi so gerne mag.

Falls es sich um einen manipulierten Shim handelt, würde ich erst mal bei Endless OS gucken, ob der von denen stammt (ich weiß über Endless OS so gut wie nichts). Die dürften den Quellcode vorrätig halten. Sonst wären wir wieder bei der Frage mit der GPL ...

"shim" gibt es übrigens auch als Debian Paket. Ich hab nur keine Ahnung, in welchem Zustand es sich befindet und wie man es konfiguriert. Aber nach meinem Verständnis kann sich da seit 2012 eigentlich nichts geändert haben und zu konfigurieren dürfte es da auch nichts geben.

[hikaru]

Ich habe eher den Eindruck, dass Secure Boot nach dem Ausschalten nicht wirklich komplett ausgeschaltet ist. Er scheint weiterhin nach einem (signierten?) Secure-Boot-Bootloader zu suchen (ohne den geht F2 nicht). Es fragt sich weiterhin, ob das ein bestimmter im UEFI hinterlegter Bootloader ist, oder ob er sich selbstständig "irgendeinen" auf der Platte sucht.

bootx64.efi aus shim (oder auch aus dem Ubuntu-18.04-Paket) funktionioert ebenfalls, vorausgesetzt, man legt die Datei als EFI/endless/shim.efi ab.
Keine zwei der drei Dateien sind identisch.

Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi

Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.

Falls es sich um einen manipulierten Shim handelt, würde ich erst mal bei Endless OS gucken, ob der von denen stammt (ich weiß über Endless OS so gut wie nichts). Die dürften den Quellcode vorrätig halten. Sonst wären wir wieder bei der Frage mit der GPL ...

shim steht unter BSDL (2-Clause). [1] Eine Verpflichtung zur Veröffentlichung von Quellcode besteht daher für Acer/Endless nicht.
Unabhängig davon gibt es unter [2] eine sources.list zu Endless, und in diesem Repo gibt es shim-Quellen [3], neben denen ein bootx64.efi liegt, das binär identisch mit meinem endless/shim.efi ist. Die Datei führt aber wie gesagt unter dem Namen bootx64.efi nicht zu einem erfolgreichen UEFI-Zugriff. Laut debian/rules aus dem Archiv wird bootx64.efi nach shim.efi kopiert.

In der sources.list auf meiner Endless-HDD steht übrigens ein anderer Server, der aber nicht (mehr?) online zu sein scheint. Laut dieser sources.list ist auf der HDD Endless 3.1 installiert.

Nach deinem folgenden Kommentar fragt sich aber auch, ob man das so sicher sagen kann, ohne jeweils einen Kaltstart ausgeführt zu haben. Eigentlich müsste man sämtliche Experimente mit einem "Power-Off" dazwischen wiederholen.

Nachdem ich den Verdacht hatte, dass Reboots möglicherweise nicht ausreichen, habe ich alle weiteren Aktionen grundsätzlich mit Kaltstarts gemacht.

Bei Desktop-UEFIs beobachte ich übrigens oft folgendes Verhalten: Bei manchen (nicht allen) Änderungen am UEFI wird mir erst eine Liste aller von mir getätigten Änderungen angezeigt, dann führt das Gerät einen Reboot durch, und an der Stelle, an der der Bootloader gestartet werden sollte, folgt ein weiterer Reboot, der dann "normal" verläuft. Das sieht für mich so aus, als ob bei Änderungen am UEFI ein neuer Boot-Eintrag mit "Änderungsaufträgen" und einem "Reboot" am Ende erzeugt wird. Ich schließe daraus, dass Änderungen im UEFI eine sehr komplizierte Sache sind.

Hier sieht es anders aus. Nachdem irgendwelche Schreibaktionen nach /boot/efi/EFI ducrhgeführt wurden, dauert der Shutdown (egal ob kalt oder warm) jeweils 1-3 Minuten länger als üblich. Ich vermute, dabei werden Änderungen geschrieben (die aber möglicherweise beim nächsten Boot noch irgendwie initialisiert werden müssen, was vieleicht nur beim Kaltstart geht).

Kombiniert man das mit der langen Shutdown-Prozedur eines fetten Live-Xubuntu von einem zugegeben nicht blitzschnellen USB-2.0-Stick, dann kann möglicherweise der Eindruck entstehen, das System habe sich beim Shutdown aufgehangen. Ich glaube genau das ist neulich passiert und ich war nicht geduldig genug. Nachdem ich die Systematik mit endless/shim.efi und endless/grubx64.efi herausgefunden habe funktioniert übrigens auch der Boot vom Xubuntu-Stick wieder. Warum es nun wieder geht, weiß ich allerdings nicht. Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.

Soweit ich das beurteilen kann, kommt diese Grub-Shell immer dann hoch, wenn sonst nichts zum Booten gefunden wird.
Und ja, ich glaube die ist wirklich von Acer.

Das ist aus zwei Gründen interessant:
1) Warum ist der da? Wofür mag der gut sein? Kann man den selber irgendwie nutzen? (Nein, ich habe keine Antworten)
2) Wie war das noch mit der GPL? Müsste Acer dann nicht den Quellcode dazu anbieten?

Im Endless-Repo gibt es auch Grub2-Quellen. [4] Ob die zu diesem "Acer-Grub" passen weiß ich nicht und ich sehe bisher auch keinen Weg, diesen Grub auszutauschen.

2) Das Blacklisten der efivar-Module nach smutberts Anleitung führt entweder nicht zum gewünschten Ergebnis oder wurde von dir falsch durchgeführt oder "grub-install" lädt diese Module dann trotzdem "hintenrum".

Ich habe mich an smutberts Anleitung gehalten und die Module (efivars, efivarfs) werden dann laut lsmod auch nicht geladen, selbst nach einem grub-install ohne --no-nvram nicht.

Nebenbei fällt mir gerade noch ein, dass du auf Seite 1 von Kernel-Panics berichtet hast. Wenn man die (ohne "--no-nvram") reproduzieren kann, reicht's vielleicht für einen qualifizierten Kernel Bug.

Diese Kernel-Panics hatte ich jetzt lang nicht mehr, egal ob mit oder ohne geladenem efivars/efivarfs und mit oder ohne --no-nvram.

Ich habe zuerst das gesamte EFI/endless-Verzeichnis auf die Debian-SSD kopiert und dann versucht ohne Endless-HDD zu booten. Dabei kam nach dem Acer-Logo ein schwarzer Bildschirm (Acer-Grub?) auf dem ständig und ohne Ende diese Zeile fast unleserlich flackerte:

Code: Alles auswählen

error: no such device: 4f68-bce3-e8cd-4db1-96e7fbcaf984b709

Das sieht aus wie eine UUID. Diese passt aber zu keiner Partition und zu keinem Dateisystem auf der Endless-HDD oder auf der Debian-SSD.*

*) Edit: Diese Kennung nennt sich im UEFI-Kontext wohl "Protokoll":
https://jbeekman.nl/blog/2015/03/revers ... -firmware/

Uff ... ich weiß jetzt wesentlich mehr über EFI Binaries als ich jemals wissen wollte. Aber ich denke, du bist auf dem Holzweg. Stimmt, EFI nutzt UUIDs als Funktionsreferenz. Aber auch in gewöhnlicher Weise um Partitionen zu identifizieren. Die Meldung oben sieht mir viel zu sehr nach einem gewöhnlichen Grub-Fehler aus, der seine Partition nicht finden kann.

Ich fürchte, wir sind beide auf dem Holzweg.
Wenn man mal genau hinschaut, dann stellt man fest, dass GPT-PARTUUIDs und auch UEFI-Protokoll-UUIDs das Format 8-4-4-4-12 haben. Was da auf meinem Schirm erschien hat aber das Format 4-4-4-4-16.

Auf einem funktionierenden UEFI wirst du feststellen, dass die UUIDs in den Booteinträgen von "efibootmgr -v" identisch sind zu den PARTUUIDs, die blkid anzeigt. Die PARTUUIDs stehen in der GPT, sind also von der Partitionstabelle abhängig und nicht vom Dateisystem.

Kann ich auf meinem System bestätigen. Aber die "UUID" aus dem Flackerschirm passt zu keiner PARTUUID auf irgendeinem der Datenträger die ich jemals zum Booten des Geräts verwendet habe, nicht auf der Endless-HDD, der Debian-SSD, dem Xubuntu-Stick oder dem rEFInd-Stick. Sie passt selbst dann nicht, wenn man die Bindestriche im Format ignoriert. Die Hex-Sequenz taucht nirgendwo sonst auf.

Hmm .. so als grobe Hypothese: Entweder
1) sucht das UEFI trotz ausgeschaltetem Secure Boot einen signierten Bootloader (smutberts Theorie), findet den unter /endless/shim.efi (sonst geht F2 nicht) und /endless/shim.efi will dann einen hardcodierten Pfad laden *a).
oder
2) der Pfad /endless/shim.efi ist irgendwo gespeichert (wo?!?) (meine Theorie), wird geladen wenn er gefunden wird und /endless/shim.efi will dann wieder einen hardcodierten Pfad laden *a).

*a) Welchen hardcodierten Pfad? Aus der Beschreibung von Shim (siehe unten) ergeben sich zwei Möglichkeiten.
a1) Shim sucht in <aktuelles Verzeichnis>/grubx64.efi (oder sucht generell eine Datei grubx64.efi in der Efi Partition, das halte ich für unwahrscheinlich).
a2) Acer benutzt einen manipulierten Shim, der nach /endless/grubx64.efi sucht.

Soweit ich das Chaos hier überblicke: wenn man shim.efi und Debians grubx64.efi in ein anderes Verzeichnis packt, dann funktioniert es nicht. Das schließt eine Kombination von 1) und a1) eigentlich aus. Den Rest kann man herausbekommen.

In dem Archiv unter [3] gibt es abgesehen vom Changelog zwei Dateien in denen "endless" erwähnt wird:

Code: Alles auswählen

debian/source/include-binaries:debian/endless-ca.der
debian/shim-efi-image-signed.install:MokManager.efi  /boot/efi/EFI/endless/
debian/shim-efi-image-signed.install:shim.efi /boot/efi/EFI/endless/
debian/shim-efi-image-signed.install:BOOT.CSV /boot/efi/EFI/endless/

Die .install halte ich für unspektakulär:

Code: Alles auswählen

bootx64.efi /boot/efi/EFI/BOOT/
fallback.efi /boot/efi/EFI/BOOT/
MokManager.efi  /boot/efi/EFI/endless/
shim.efi /boot/efi/EFI/endless/
BOOT.CSV /boot/efi/EFI/endless/

Die include-binaries verwirrt mich (vollständiger Inhalt):

Code: Alles auswählen

debian/endless-ca.der

Die Datei gibt es in dem Archiv nicht, dafür eine debian/endless-ca.cer
Ist das ein Tippfehler? Und falls ja, hat der Auswirkungen?

Was ich noch nicht ganz verstanden habe ist die Rolle von MokManager.efi. Die Datei habe ich bisher ignoriert. Unter [5] steht ein bisschen was dazu, aber das ist mir zu unspezifisch.


[1] https://mjg59.dreamwidth.org/20303.html ... #cmt790095
[2] https://wiki.debian.org/Derivatives/Census/Endless
[3] http://sources.endlessm.com/debian/pool ... im-signed/
[4] http://sources.endlessm.com/debian/pool/core/g/grub2/
[5] https://www.golem.de/news/uefi-secure-b ... 96085.html

[NAB]

Keine zwei der drei Dateien sind identisch.

hmm ... das lässt mich nun an meinem Verständnis von "signierter Bootloader" zweifeln ...
Andererseits hat auch niemand versprochen, dass jede Version von Shim signiert ist, dämmert mir gerade. Man könnte beliebige unsignierte Versionen erzeugen. Wozu man die dann braucht, wäre eine andere Frage.

Und wenn es ein unmanipulierter Shim ist, dann müsste meiner Meinung nach Folgendes klappen:
shim.efi -> /EFI/BOOT/bootx64.efi
(den removable media path bootet dein UEFI ja anscheinend brav)
/debian/grubx64.efi -> /EFI/BOOT/grubx64.efi

Das führt zu bootendem Debian aber fehlendem UEFI-Zugriff, egal ob mit shim bzw. bootx64 von Endless, Debian oder Ubuntu.

*mist* ... dein UEFI scheint wirklich in den Pfad /endless/shim.efi verliebt zu sein.

Aber ich befürchte, das funktioniert schon deswegen nicht, weil es einen signierten Shim braucht (der von Endless ist ja signiert). Ich ging bisher davon aus, dass Shim immer signiert ist, weil ich mir keinen anderen Nutzen vorstellen kann. Siehe weiter unten.

Hier sieht es anders aus. Nachdem irgendwelche Schreibaktionen nach /boot/efi/EFI ducrhgeführt wurden, dauert der Shutdown (egal ob kalt oder warm) jeweils 1-3 Minuten länger als üblich.

Huch? Das meinte ich eigentlich gar nicht. Ich meinte Änderungen im UEFI selber, die ins NVRAM/CMOS/Wasauchimmer geschrieben werden, keine Änderungen in der EFI Partition. Warum das UEFI auf Änderungen in der Partition derartig lange herumkaut, und das auch noch beim Herunterfahren, ist mir ein Rätsel. Das kenne ich nicht.

Ich vermute, dabei werden Änderungen geschrieben (die aber möglicherweise beim nächsten Boot noch irgendwie initialisiert werden müssen, was vieleicht nur beim Kaltstart geht).

"Eigentlich" nicht. Eigentlich sollte es dem UEFI egal sein, ob sich auf der Partition etwas ändert. Lediglich Änderungen am NVRAM müsste es irgendwie prüfen und integrieren. Wenn du deinen Bootloader löscht, dann würde es beim nächsten Booten den Eintrag im NVRAM nachschlagen, dann feststellen, dass die Datei nicht mehr existiert und meckern ... oder zum nächsten Booteintrag übergehen. Dein UEFI führt da ein merkwürdiges Eigenleben, das ich so nicht kenne.

Kombiniert man das mit der langen Shutdown-Prozedur eines fetten Live-Xubuntu von einem zugegeben nicht blitzschnellen USB-2.0-Stick,

Das mag sein, erklärt aber nicht, was Xubuntu auf der EFI-Partition (oder im NVRAM) zu ändern hatte. Eigentlich sollte ein Live-System beides nicht anfassen.

Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.

Huch? Da sollten aber welche sein:
http://www.syslinux.org/wiki/index.php?title=Isohybrid
Eigentlich ginge es auch ohne, aber dann müsste das UEFI (von USB) einen BIOS-Boot machen.

Im Endless-Repo gibt es auch Grub2-Quellen. [4] Ob die zu diesem "Acer-Grub" passen weiß ich nicht und ich sehe bisher auch keinen Weg, diesen Grub auszutauschen.

Das meinte ich nicht. Deinen Berichten zufolge steckt der Grub in der Firmware, ließe sich also nur durch ein Firmware-Update austauschen. Und die müssen inzwischen signiert sein. Ich meinte, den vorhandenen Grub zum Booten zu benutzen, insbesondere mit der vermeintlichen UUID, aber da hast du mir gerade den Wind aus den Segeln genommen.

Ich habe mich an smutberts Anleitung gehalten und die Module (efivars, efivarfs) werden dann laut lsmod auch nicht geladen, selbst nach einem grub-install ohne --no-nvram nicht.

Das bezweifele ich nicht, aber warum funktioniert grub-install (ohne --no-nvram) und efibootmgr bei dir? Wenn das Blacklisten von efivars den gewünschten Effekt hätte, dürfte beides nicht funktionieren. Hier steht etwas mehr darüber:
https://wiki.gentoo.org/wiki/Efibootmgr/de

Ich fürchte, wir sind beide auf dem Holzweg.
Wenn man mal genau hinschaut, dann stellt man fest, dass GPT-PARTUUIDs und auch UEFI-Protokoll-UUIDs das Format 8-4-4-4-12 haben. Was da auf meinem Schirm erschien hat aber das Format 4-4-4-4-16.

Upps ...
Ich würd ja gerne widersprechen, aber ich finde keinen Hinweis, dass UUIDs irgendwo/wie anders notiert werden. Dieses "error: no such device:" sieht aber trotzdem sehr verlockend nach einem suchenden Grub aus. Trotzdem ... ich wüsste nicht, wie man eine derartig verunstaltete UUID in eine Partitionstabelle schreibt. Und wenn wirklich ein Grub dieses "Ding" anzeigt, dann müsste der Grub selber eigenwillig verändert worden sein, nur wozu?

Es bleibt mysteriös ...

Die Datei gibt es in dem Archiv nicht, dafür eine debian/endless-ca.cer
Ist das ein Tippfehler? Und falls ja, hat der Auswirkungen?

Ich tippe mal darauf, dass es einen Fehler bei der Installation geben würde. Aber ... worauf willst du hinaus? Ich war bei der Frage, wie das UEFI funktioniert. Nun gräbst du Endless um, was wohl niemand hier installieren oder benutzen möchte.

Was sich mir hingegen gerade in die Netzhaut brennt ist das "shim-efi-image-signed". Der Shim aus Stretch scheint tatsächlich "unsigned" zu sein (wozu auch immer man sowas braucht). In Buster gibt es einen shim-signed:
https://packages.debian.org/de/buster/shim-signed
Du könntest dir da das "shimx64.efi.signed" rausklauen und versuchen, es statt des Endless-Shim zu benutzen.

Was ich noch nicht ganz verstanden habe ist die Rolle von MokManager.efi. Die Datei habe ich bisher ignoriert.

Wozu Shim überhaupt ein MokManager.efi braucht, ist mir auch unklar. MOKs hingegen sind "Machine Owner Keys" und eigentlich eine ziemlich tolle Sache. Du kannst nämlich aus dem UEFI den Microsoft-Key rausschmeißen und deinen eigenen MOK hinterlegen und fortan nur noch selbstsignierte Binaries starten. Ich hab mich damals ziemlich gefreut, als ich das gelesen habe und dachte mir "tolle Sache" aber irgendwie wird es bis heute nicht so richtig genutzt. Inzwischen hätte ich aber eher Angst davor, in welche UEFI-Bugs ich dabei stolpern würde. Mehr zum Thema:
https://firmware.intel.com/blog/using-m ... suse-linux
Und in der praktischen Anwendung:
https://knowledge.windriver.com/en-us/0 ... 70/000/010
Daraus kann man sich zurechtraten, was der MokManager.efi vermutlich tut. Kurz gesagt: nichts, was du nutzt.

[hikaru]

Aber ich befürchte, das funktioniert schon deswegen nicht, weil es einen signierten Shim braucht (der von Endless ist ja signiert).

In meinem letzten Beitag schrieb ich, dass es offenbar egal ist, welchen shim ich verwende (Endless, Stretch oder Ubuntu). Wichtig ist nur, dass das Teil in /endless liegt und auch wirklich shim.efi heißt (und nicht etwa boot64.efi).
So zumindest die Situation mit abgeschaltetem Secure Boot. Für einen weiteren Test mit Secure Boot bin ich gerade zu faul.

Huch? Das meinte ich eigentlich gar nicht.
[..]
Das meinte ich nicht.

Wir müssen an unserer Kommunikation arbeiten!

Das mag sein, erklärt aber nicht, was Xubuntu auf der EFI-Partition (oder im NVRAM) zu ändern hatte. Eigentlich sollte ein Live-System beides nicht anfassen.

Es kann sein, das ich einen meiner EFI-Reparaturversuche (hin- und herschieben von *.efi-Dateien) von Xubuntu aus durchgeführt habe.

Auf dem Xubuntu-Stick gibt es neben der iso9660-Partition zwar noch eine fat-Partition, ich finde darauf jedoch keine efi-Dateien.

Huch? Da sollten aber welche sein:

Oh, Tatsache:

Code: Alles auswählen

# md5sum /mnt/efi/boot/*
6e94c3d33194c89bd327bfaa5871e294  /mnt/efi/boot/bootx64.efi
7dc5588d483932c1215cc6ff785ceb36  /mnt/efi/boot/grubx64.efi

Keine Ahnung warum ich die nicht gesehen habe. (Ich bin mir 100%ig sicher, sie nicht gesehen zu haben. Aber vielleicht habe ich mich heute morgen vermountet.)

Das bezweifele ich nicht, aber warum funktioniert grub-install (ohne --no-nvram) und efibootmgr bei dir?

grub-install mit und ohne --removable funktioniert mit und ohne efivars/efivarfs. Ohne die Module geht's nur mit --no-nvram. Nach dem was ich bisher verstanden habe ist daran auch nichts seltsam.

Ich war bei der Frage, wie das UEFI funktioniert. Nun gräbst du Endless um, was wohl niemand hier installieren oder benutzen möchte.

Ich habe bisher keine Ahnung von UEFI. Da dachte ich, es wäre eine gute Idee nachzuschauen, wie das einzige mir bisher bekannte mit UEFI-Boot ausgelieferte System unter der Haube aussieht.
Außerdem suchte ich nach einer Möglichkeit, die Kiste mit Quellen aus dem Netz bootfähig zu machen, falls ich mir mal wieder irgendwas an der Bootsequenz zerschieße und mir in einem kosmischen Unglücksfall alle Backups gleichzeitig sterben.

[smutbert]

Habt ihr eigentlich noch einen Überblick - ich muss zugeben, dass obwohl ich mich bemühe, nicht ganz mitkomme?
Mir ist die Aussage in Erinnerung, dass das Aufrufen des BIOS/UEFI-Setup (<F2>) ohne »EFI/boot/bootx64.efi« funktioniert hat - ist das noch aktuell?

Weil dann wäre es meiner Meinung nach ganz interessant was passiert, wenn du von diesem endless OS aus unter dem ja alles (?) funktioniert mittels efibootmgr (oder eventuell auch chroot) einen Booteintrag für Debians grub anlegst »EFI/debian/grubx64.efi« anlegst und dafür »EFI/boot/bootx64.efi« (jeweils auf der internen SSD) löschst. Das sollte in etwa so gehen (bin mir jetzt nicht sicher, ob Debians EFI System Partition dafür gemountet sein muss oder nicht)

Code: Alles auswählen

# efibootmgr -c -d /dev/sda -p 1 -L "Debian" -l "\EFI\debian\grubx64.efi"

Bleibt dieser Befehl (auch) in endless OS hängen oder funktioniert dann das Booten von Debian und/oder <F2> wieder nicht?

[hikaru]

Habt ihr eigentlich noch einen Überblick - ich muss zugeben, dass obwohl ich mich bemühe, nicht ganz mitkomme?

Ich bin selbst etwas am Schleudern.
Dabei bin ich mir nicht sicher, ob es an meinem mangelnden Verständnis der Thematik, an Missverstänsnissen oder an der Fülle der Baustellen liegt, die wir hier mittlerweile aufgemacht haben.

Mir ist die Aussage in Erinnerung, dass das Aufrufen des BIOS/UEFI-Setup (<F2>) ohne »EFI/boot/bootx64.efi« funktioniert hat - ist das noch aktuell?

Aktueller Stand ist:
1. dass ich mit F2 in's UEFI komme, wenn es EFI/endless/shim.efi gibt, unabhängig davon, was woanders steht.
2. Falls es dieses EFI/endless/shim.efi gibt, dann muss Debians grubx64.efi im selben Verzeichnis liegen, sonst wird es nicht gefunden.
3. Falls es EFI/endless/shim.efi nicht gibt, dann ist es egal wo Debians grubx64.efi liegt, es wird immer gefunden.

Aus 1. und 2. folgt, dass es momentan nur eine sinnvolle Kombination gibt, nämlich shim.efi und grubx64.efi beide in EFI/endless.

Wenn es gar keine *.efi-Dateien nirgends gibt, komme ich ebenfalls mit F2 in's UEFI. Das habe ich aber seit dem Wochenende nicht mehr probiert und ich verspüre momentan auch wenig Lust dazu, denn dann habe ich ja kein Debian.

Weil dann wäre es meiner Meinung nach ganz interessant was passiert, wenn du von diesem endless OS aus unter dem ja alles (?) funktioniert mittels efibootmgr (oder eventuell auch chroot) einen Booteintrag für Debians grub anlegst »EFI/debian/grubx64.efi« anlegst und dafür »EFI/boot/bootx64.efi« (jeweils auf der internen SSD) löschst. Das sollte in etwa so gehen (bin mir jetzt nicht sicher, ob Debians EFI System Partition dafür gemountet sein muss oder nicht)

Code: Alles auswählen

# efibootmgr -c -d /dev/sda -p 1 -L "Debian" -l "\EFI\debian\grubx64.efi"

Bleibt dieser Befehl (auch) in endless OS hängen oder funktioniert dann das Booten von Debian und/oder <F2> wieder nicht?

Von Debian aus bleibt der Befehl mit efivars/efivarfs hängen, ohne die Module kriege ich eine Meldung die sinngemäß besagt, dass das System keine efivars unterstützt.
Von Endless aus möchte ich das nicht absetzen, so lange ich noch kein Vollbackup der HDD gemacht habe. Ich hoffe, ich komme in den nächsten Tagen dazu.

[NAB]

In meinem letzten Beitag schrieb ich, dass es offenbar egal ist, welchen shim ich verwende (Endless, Stretch oder Ubuntu). Wichtig ist nur, dass das Teil in /endless liegt und auch wirklich shim.efi heißt (und nicht etwa boot64.efi).

Verzeihung ... ich dachte, das "funktioniert" bezog sich nur auf das Booten. Anscheinend funktioniert auch "F2" und somit "alles".

Wenn ich dich recht verstehe, klappt das Booten und F2 nun mit nur Debian-Dateien auf der EFI-Partition. Das ist doch schon mal ein Erfolg.

Und es klingt, als sei es dem UEFI fast egal, was da unter /endless/shim.efi liegt. Du könntest es mal mit einer völlig sinnlosen Datei versuchen. Dann wüssten wir, dass das UEFI lediglich den Pfad prüft.

So zumindest die Situation mit abgeschaltetem Secure Boot. Für einen weiteren Test mit Secure Boot bin ich gerade zu faul.

Da fragt sich auch, welchen Sinn das macht. So wie ich die zahlreichen Ubuntu-Qellen verstanden habe, scheint Booten mit Secure-Boot zu funktionieren (wenn man ein BIOS-Passwort setzt). Nur kann Debian Stretch noch kein Secure Boot und du willst Stretch verwenden.

Ich hatte nur die dünne Theorie, dass das UEFI einen signierten Shim sehen möchte, damit F2 funktioniert, aber die scheint gerade zerbröckelt zu sein. Damit kann ich die noch dünnere Theorie, dass der Pfad mit /endless sich nur mit aktiviertem Secure Boot ändern lässt, wohl auch begraben.

Wir müssen an unserer Kommunikation arbeiten!

Weiß ich nicht ... ich find die ganz gut so. Immerhin durchkreuzt du meine Ideen immer wieder mit interessanten neuen Gedanken.

Keine Ahnung warum ich die nicht gesehen habe. (Ich bin mir 100%ig sicher, sie nicht gesehen zu haben. Aber vielleicht habe ich mich heute morgen vermountet.)

Der Gedanke, dass du die Dateien übersehen hast ist mir irgendwie lieber als der, dass dein UEFI auch noch hin und wieder Dateien ganz verschwinden lässt

grub-install mit und ohne --removable funktioniert mit und ohne efivars/efivarfs. Ohne die Module geht's nur mit --no-nvram. Nach dem was ich bisher verstanden habe ist daran auch nichts seltsam.

Hmm? Hier:
viewtopic.php?f=12&t=169061&start=30#p1168792
schriebst du noch:

grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.

Dadurch kam ich ja zu der Vermutung, dass das Blacklisten nicht funktioniert.
Und nun geht's auf einmal? Wie kam's denn nun zu der Änderung? (falls das nachvollziehbar ist).
Wobei das eigentlich egal ist. Interessant ist, dass grub-install (mit modulen und ohne --removable) dir eigentlich auch den passenden Eintrag ins NVRAM schreiben sollte. Tut's das? (efibootmgr -v)
Ich dachte eigentlich, dass genau dabei und deswegen die Debian-Installation hängengeblieben ist. Und nun geht's auf einmal ...

Ich habe bisher keine Ahnung von UEFI. Da dachte ich, es wäre eine gute Idee nachzuschauen, wie das einzige mir bisher bekannte mit UEFI-Boot ausgelieferte System unter der Haube aussieht.

Dazu müsstest du dann auch noch vergleichen, ob das was Acer da ausliefert identisch ist mit dem im Netz zu findenden Endless OS.

Außerdem suchte ich nach einer Möglichkeit, die Kiste mit Quellen aus dem Netz bootfähig zu machen, falls ich mir mal wieder irgendwas an der Bootsequenz zerschieße und mir in einem kosmischen Unglücksfall alle Backups gleichzeitig sterben.

So wie ich dich oben verstanden habe, läuft die Kiste jetzt mir nur-Debian-Dateien und ließe sich zumindest mit einem Ausflug zu Refind auch bootfähig machen ... oder ist mir wieder was entgangen?

Habt ihr eigentlich noch einen Überblick

Wirklichen Überblick hatte ich noch nie ... es tauchen immer wieder kuriose Details auf oder eigentümliche Wunderheilungen. Andererseits sieht's inzwischen ganz gut aus, so wie ich das verstehe. Booten und UEFI funktioniert, und beides ohne komische Dateien von Acer.

Ich weiß inzwischen nicht mehr, was hikaru noch erreichen möchte. Ein "heiles" UEFI wird das wohl nie werden. Ich würd's genau wie von dir vorgeschlagen noch mal mit dem efibootmgr versuchen - schon um dem UEFI diesen komischen /endless Pfad auszutreiben. Andererseits wäre das nur Kosmetik.

Von Endless aus möchte ich das nicht absetzen, so lange ich noch kein Vollbackup der HDD gemacht habe. Ich hoffe, ich komme in den nächsten Tagen dazu.

Xubuntu wäre auch einen Versuch wert.

Bei dem Endless, was du auf HDD hast, wissen wir nicht, wie weit es von Acer angepasst wurde. Wenn es damit geht, hast du zwar ein herstellerspezifisches Tool, mit dem du die NVRAM-Einträge einstellen kannst, aber ich fände es erstrebenswert herauszubekommen, ob das auch mit freier und frei verfügbarer Software geht. Dazu müsstest du dir dann eigentlich ein neues (veraltetes?) Endless von deren Servern ziehen. Da würd ich vorher mit (X)ubuntu mein Glück versuchen.

[hikaru]

Wenn ich dich recht verstehe, klappt das Booten und F2 nun mit nur Debian-Dateien auf der EFI-Partition. Das ist doch schon mal ein Erfolg.

Ja.

Und es klingt, als sei es dem UEFI fast egal, was da unter /endless/shim.efi liegt. Du könntest es mal mit einer völlig sinnlosen Datei versuchen. Dann wüssten wir, dass das UEFI lediglich den Pfad prüft.

Ich habe mal 1MB aus /dev/zero geholt und als /endless/shim.efi abgelegt.
Folge: F2 in's UEFI geht, Debians Grub kommt aber nicht hoch, dafür kriege ich eine Meldung vom UEFI, dass kein Bootmedium gefunden wurde. Die Meldung sieht nach einem ncurses-Dialog aus. Bisher waren solche Meldungen immer grafisch mit einem schicken Hintergrundbild einer leeren HDD.
Eigentlich hätte ich es genau andersrum erwartet.

So wie ich die zahlreichen Ubuntu-Qellen verstanden habe, scheint Booten mit Secure-Boot zu funktionieren (wenn man ein BIOS-Passwort setzt).

Ich musste ein BIOS-Passwort setzen, um Secure Boot abzuschalten. Vorher war die Option ausgegraut. Das war irgendwo bei Acer als erwünschtes Verhalten dokumentiert.

Hier:
viewtopic.php?f=12&t=169061&start=30#p1168792
schriebst du noch:

grub-install ohne --removable blieb übrigens hängen, sowohl mit als auch ohne geblacklistetem efivars/efivarfs. /EFI/debian/grubx64.efi wurde dabei allerdings noch abgelegt.

Dadurch kam ich ja zu der Vermutung, dass das Blacklisten nicht funktioniert.
Und nun geht's auf einmal? Wie kam's denn nun zu der Änderung? (falls das nachvollziehbar ist).

Nein, das kann ich leider nicht mehr nachvolziehen.

Wobei das eigentlich egal ist. Interessant ist, dass grub-install (mit modulen und ohne --removable) dir eigentlich auch den passenden Eintrag ins NVRAM schreiben sollte. Tut's das? (efibootmgr -v)

Momentan (morgen mag das wieder anders sein ) führt ein grub-install-Aufruf mit geladenen Modulen und ohne --no-nvram zum Aufhängen des Befehls.

Dazu müsstest du dann auch noch vergleichen, ob das was Acer da ausliefert identisch ist mit dem im Netz zu findenden Endless OS.

Wie gesagt, auf shim.efi trifft das zu.
Beim Rest des Systems wüsste ich nicht, wo ich anfangen sollte.

Ich weiß inzwischen nicht mehr, was hikaru noch erreichen möchte.

Ich würde gern noch den /endless-Pfad loswerden, oder zumindest verstehen wollen, warum der so wichtig ist.
Da das Gerät außer mit Endless auch mit Win10 verkauft wird vermute ich, dass es noch einen Win10-Pfad geben sollte, der ähnlich bevorzugt behandelt wird.

Xubuntu wäre auch einen Versuch wert.

Beim Versuch, mit geladenen efivars/efivarfs-Modulen von Debian aus diesen Booteintrag zu erstellen bleibt das Kommando entweder hängen (beim Laden der Module beim Booten) oder zu einem Segfault (beim nachträglichen Laden per Hand). lsmod-Vergleiche zwischen beiden Zuständen müsste ich noch anstelllen.
Auch im Xubuntu-Livesystem gibt es einen Segfault, denn da werden die Module nicht beim Booten geladen. Wie die Module hier geblacklistet werden weiß ich bisher nicht. Über einen Eintrag in /etc/modprobe.de passiert es nicht.

[NAB]

Ich habe mal 1MB aus /dev/zero geholt und als /endless/shim.efi abgelegt.
Folge: F2 in's UEFI geht, Debians Grub kommt aber nicht hoch, dafür kriege ich eine Meldung vom UEFI, dass kein Bootmedium gefunden wurde. Die Meldung sieht nach einem ncurses-Dialog aus. Bisher waren solche Meldungen immer grafisch mit einem schicken Hintergrundbild einer leeren HDD.
Eigentlich hätte ich es genau andersrum erwartet.

Hmm? Was hättest du anders herum erwartet? Das Bootverhalten oder das Hintergrundbild?

Ich schließe daraus, dass es für "F2" in der Tat egal ist, was /endless/shim.efi enthält. Lediglich die Datei muss existieren.

Nur aus dem Bootverhalten werde ich weiterhin nicht schlau, und aus deiner Beschreibung "ncurses-Dialog" auch nicht. Klingt als hättest du etwas noch-nie-Dagewesenes erblickt, während ich eine Meldung erwartet hätte wie damals, als du die EFI-Partition gelöscht hast.

Aber gut, shim.efi kann er in diesem Zustand nicht ausführen und interessanter Weise sucht er weiterhin nach einem Bootmedium. Gib ihm das doch mal, indem du grubx64.efi nach efi/boot/bootx64.efi kopierst.

Ich musste ein BIOS-Passwort setzen, um Secure Boot abzuschalten. Vorher war die Option ausgegraut. Das war irgendwo bei Acer als erwünschtes Verhalten dokumentiert.

Ubuntu kann Secure Boot. Debian nicht.
Die übliche Ubuntu-Anleitung zu deinem Laptop beläuft sich auf das hier:
https://wiki.ubuntuusers.de/EFI_Problem ... er-Rechner
Wie hier z.B.:
https://forum.ubuntuusers.de/topic/efi- ... aegt-fehl/
("knubbelchen" meldet sich nicht mehr, nachdem er den Hinweis erhalten hat, wie man den Secure Boot Bootloader korrekt installiert, scheint also für ihn zu funktionieren. "emmele_74" verweist danach auf eine ähnliche Anleitung. "emmele_74" berichtet übrigens auch von einem streikenden F2)
Und das klappt mit Debian halt nicht, mangels Secure Boot Unterstützung.

Die einzige Ausnahme, die ich finde, ist die hier:
https://askubuntu.com/questions/946886/ ... 18-rn-p7xq
Der beschreibt die gleichen Symptome wie du und spricht von einem Workaround, den ich nicht verstehe. Ich vermute, die Probleme hat er, weil er Secure Boot abgeschaltet hat.
(Und den Herrn von Amazon, der auf BIOS-Boot schwört)

Momentan (morgen mag das wieder anders sein ) führt ein grub-install-Aufruf mit geladenen Modulen und ohne --no-nvram zum Aufhängen des Befehls.

*seufz* ...

Ich hab eben noch diesen Bug-Report gefunden:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1724406
Der deutet darauf hin, dass bereits das Lesen der efivars (mit cat) sich aufhängt.

Ich würde gern noch den /endless-Pfad loswerden, oder zumindest verstehen wollen, warum der so wichtig ist.
Da das Gerät außer mit Endless auch mit Win10 verkauft wird vermute ich, dass es noch einen Win10-Pfad geben sollte, der ähnlich bevorzugt behandelt wird.

Ja, das ginge mir ähnlich ...
Du scheinst zu vermuten, dass diese Pfade fest in der Firmware stehen. Daran habe ich große Zweifel. Erstens sind diese Pfade dazu gedacht, veränderbar zu sein und zweitens wäre es ein Risiko für Acer, falls Microsoft oder Endless jemals auf die Idee kommen, den Pfadnamen zu verändern.

Ich vermute grob, dass dieser Endless-Pfad irgendwo im (veränderbaren) NVRAM steht und dir aus unbekannten Gründen nicht angezeigt wird.

Wenn man sich die Endless OS Installationsanleitung speziell für Acer Laptops anguckt:
https://support.endlessm.com/hc/en-us/a ... in-Windows
dann scheint die auch Secure Boot vorauszusetzen ("Choose Select a UEFI file as trusted for executing") und du musst manuell einen Pfad angeben. Es würde Sinn machen, dass dir diese Pfade nicht angezeigt werden, wenn Secure Boot ausgeschaltet ist (aus Sicherheitsgründen). Und es wäre ein möglicher Bug im UEFI, dass dir ein bestimmter Pfad nur angezeigt wird, wenn die entsprechende Datei existiert.

Soweit meine grobe Theorie. Wobei dein UEFI noch ein paar andere Bugs haben müsste, um das von dir bisher geschilderte Verhalten zu erklären.

Wenn du hingegen Recht hast und der endless/-Pfad fest in der Firmware kodiert ist, dann hättest du keine Chance, ihn da rauszubekommen. Dann fragt sich aber, wie es zu den erfolgreichen Ubuntu-Installationen (mit Secure Boot) kommt.

Aus Punkt 8. werde ich übrigens nicht schlau. Ein "Windows Boot Manager" im UEFI? Kannst du das nachvollziehen?

Auch im Xubuntu-Livesystem gibt es einen Segfault, denn da werden die Module nicht beim Booten geladen. Wie die Module hier geblacklistet werden weiß ich bisher nicht. Über einen Eintrag in /etc/modprobe.de passiert es nicht.

Ich würde mal einen Versuch mit Xubuntu und aktiviertem Secure Boot machen.

P.S.: noch ein Bug für die Sammlung:
https://forum.ubuntuusers.de/topic/von- ... er-spin-1/
damit Booten von USB klappt, muss "Network-Boot" eingeschaltet sein.

[smutbert]

Du scheinst zu vermuten, dass diese Pfade fest in der Firmware stehen. Daran habe ich große Zweifel. Erstens sind diese Pfade dazu gedacht, veränderbar zu sein und zweitens wäre es ein Risiko für Acer, falls Microsoft oder Endless jemals auf die Idee kommen, den Pfadnamen zu verändern.
[…]
Wenn du hingegen Recht hast und der endless/-Pfad fest in der Firmware kodiert ist, dann hättest du keine Chance, ihn da rauszubekommen. Dann fragt sich aber, wie es zu den erfolgreichen Ubuntu-Installationen (mit Secure Boot) kommt.

Ich tendiere dazu zu glauben, dass das uefi von sich aus endless OS kennt und automatisch einen Booteintrag dafür erstellt.

Es gibt (U)EFIs, die so einiges können und tun, was sie nicht können müssten (und tun sollten). Ein Notebook, mit dem ich zu tun hatte und dessen (U)EFI NTFS lesen konnte, hat sobald es irgendwo Windows gerochen hat, einen Booteintrag dafür erstellt und den per Default gebootet, nicht-Windows-Booteinträge wurden gnadenlos wieder gelöscht und die Apple-EFIs haben zu MacOS ja auch eine ganz besondere Beziehung, wieso also nicht auch Acer und endless OS?

Das heißt aber nicht, dass sich nicht trotzdem andere Linuxdistributionen ganz normal installieren und nutzen lassen, solange sie Secure Boot unterstützen. Bei allen Lösungen zu ähnlichen Problemen mit Acer-UEFIs, die ich finde, laufen auf eine dieser Möglichkeiten hinaus
- Secure Boot zu aktivieren und zu verwenden
oder falls das wie bei Debian (noch) nicht möglich ist
- refind zu verwenden
- einen nicht signierten grubx64.efi bzw. bootx64.efi im BIOS/UEFI-Setup als vertrauenswürdig einzustufen und den EFI removable media path zu verwenden

[hikaru]

Hmm? Was hättest du anders herum erwartet? Das Bootverhalten oder das Hintergrundbild?

Das Bootverhalten. Zumindest hätte es Sinn ergeben.

Aber gut, shim.efi kann er in diesem Zustand nicht ausführen und interessanter Weise sucht er weiterhin nach einem Bootmedium. Gib ihm das doch mal, indem du grubx64.efi nach efi/boot/bootx64.efi kopierst.

grubx64.efi als BOOT/bootx64.efi und irgendein endless/shim.efi (auch aus /dev/zero) führt zu UEFI-Zugriff (F2) und Debian-Grub.
grubx64.efi als BOOT/bootx64.efi ohne endless/shim.efi führt zu Debian-Grub aber fehlendem UEFI-Zugriff.

Ubuntu kann Secure Boot. Debian nicht.

Secure Boot interessiert mich nicht, so lange ich drumrum komme.
Das Bootverhalten mit den verschienen Kombinationen von shim.efi und grubx64.efi ändert sich meinen Beobachtungen nach auch nicht. Ich habe das aber nicht systematisch getestet.

Die übliche Ubuntu-Anleitung zu deinem Laptop beläuft sich auf das hier:
https://wiki.ubuntuusers.de/EFI_Problem ... er-Rechner

Liste A kan ich bis einschließlich Punkt 6 nachvollziehen. Genau das habe ich als erstes auf dem Rechner gemacht. Punkt 7 gibt es in meinem UEFI nirgends.
Liste B bricht schon bei Punkt 3 zusammen, weil es das Submenü bei mir nicht gibt.

Du scheinst zu vermuten, dass diese Pfade fest in der Firmware stehen.

Zumindest sehe ich im UEFI (mit und ohne Secure Boot) keine "Endless-Einträge", die darauf schließen lassen würden, dass das konfigurierbar sei.

Daran habe ich große Zweifel. Erstens sind diese Pfade dazu gedacht, veränderbar zu sein und zweitens wäre es ein Risiko für Acer, falls Microsoft oder Endless jemals auf die Idee kommen, den Pfadnamen zu verändern.

Wozu irgendwas laut Spezifikation gedacht sind, ist Schall und Rauch. Soviel glaube ich zum Thema UEFI mittlerweile verstanden zu haben. (Nicht, dass das bei BIOS besser war, Stichwort: ACPI)
Was MS oder Endless "jemals" machen, dürfte Acer reichlich egal sein. Der Produktzyklus dauert für gewöhnlich ein Jahr. "Nach mir die Sintflut!" Das ausgelieferte Endless ist ja mit der kaputten sources.list für die Zielgruppe (keine "Nerds") schon jetzt nicht mehr wartbar. Acer ist da übrigens in guter Gesellschaft von z.B. Asus (Xandros) und Dell (Ubuntu).

Wenn man sich die Endless OS Installationsanleitung speziell für Acer Laptops anguckt:
https://support.endlessm.com/hc/en-us/a ... in-Windows
dann scheint die auch Secure Boot vorauszusetzen ("Choose Select a UEFI file as trusted for executing") und du musst manuell einen Pfad angeben.

Nicht laut meinen Beobachtungen. Der Endless-HDD ist es egal, ob Secure Boot im UEFI eingeschaltet ist oder nicht. Die bootet immer.

Aus Punkt 8. werde ich übrigens nicht schlau. Ein "Windows Boot Manager" im UEFI? Kannst du das nachvollziehen?

Nein. Hier ist keine erkennbare Spur von Windows.

P.S.: noch ein Bug für die Sammlung:
https://forum.ubuntuusers.de/topic/von- ... er-spin-1/
damit Booten von USB klappt, muss "Network-Boot" eingeschaltet sein.

Ist bei mir nicht der Fall. Netzwerk-Boot war die ganze Zeit aus und ich habe munter von diversen USB-Medien gebootet.

[NAB]

Das Bootverhalten. Zumindest hätte es Sinn ergeben.

Also du hättest erwartet, dass er mit einem shim.efi aus /dev/zero Debian bootet? Stimmt, hätte sein können ... dann hätte er endless/shim.efi nur auf Existenz geprüft und bei Existenz endless/grubx64.efi ausgeführt.

Davon bin ich aber nicht ausgegangen, weil mich dieser blöde endless/-Pfad nach wie vor stört. Ich glaube nicht, dass im UEFI sowohl endless/shim.efi als auch endless/grubx64.efi hinterlegt sind. Ich vermute, dass ein gefundener endless/shim.efi erstens "F2" freischaltet und zweitens, wenn er gefunden wird, auch ausgeführt wird. Der endless/shim.efi besteht dann seinerseits auf einem endless/grubx64.efi. Nur dass shim.efi nicht ausführbar ist, wenn es aus /dev/zero stammt.

Aber gut, shim.efi kann er in diesem Zustand nicht ausführen und interessanter Weise sucht er weiterhin nach einem Bootmedium. Gib ihm das doch mal, indem du grubx64.efi nach efi/boot/bootx64.efi kopierst.

grubx64.efi als BOOT/bootx64.efi und irgendein endless/shim.efi (auch aus /dev/zero) führt zu UEFI-Zugriff (F2) und Debian-Grub.

Warte ...
Mit "Debian-Grub" meinst du einen erfolgreichen Debian-Boot? Es geht also "alles"?
Das ist mal wieder neu, oder? Hier:
viewtopic.php?f=12&t=169061&start=30#p1169481
schriebst du noch, dass bei einem gefundenen endless/shim.efi auch ein /endless/grubx64.efi existieren muss (und dort hatten wir nur funktionsfähige shim.efis ausprobiert).

Mit BOOT/bootx64.efi klappt es jetzt also auch, wenn shim.efi nicht aus /dev/zero stammt? Faszinierend ...

Das ist mir zwar alles etwas unheimlich, aber damit würde sich die Installationsprozedur vereinfachen auf:
* Debian ohne Grub installieren (vielleicht klappt es inzwischen sogar mit)
* Mit Refind beim Booten nachhelfen (der Debian Installer und ein chroot sollten es auch tun).
* Grub in den Removable Media Path installieren
* Ein /boot/efi/efi/endless/shim.efi aus /dev/zero erzeugen

Secure Boot interessiert mich nicht, so lange ich drumrum komme.

Ich hänge da der gleichen Glaubensrichtung an wie smutbert ... ich vermute, mit aktiviertem Secure Boot verhält sich dein UEFI wesentlich berechenbarer. Dass du es für den Debian-Betrieb nicht haben willst, ist klar ... aber Debian bootet ja auch ohne. Nur dieser blöde endless/-Eintrag und das blockierte "F2", die nerven halt ...

Zumindest sehe ich im UEFI (mit und ohne Secure Boot) keine "Endless-Einträge", die darauf schließen lassen würden, dass das konfigurierbar sei.

Hattest du das auch mit Endless OS ausprobiert? Nach meiner Theorie könnte der Endless-Eintrag vielleicht nur auftauchen, wenn endless/shim.efi vorhanden ist und Secure Boot aktiviert ist (eventuell auch nur, wenn von endless/shim.efi gebootet wird).

Nicht laut meinen Beobachtungen. Der Endless-HDD ist es egal, ob Secure Boot im UEFI eingeschaltet ist oder nicht. Die bootet immer.

Um's Booten geht's mir nicht. Debian bootet ja. Es geht mir um den blöden endless/-Eintrag.

Natürlich bootet Endless OS immer. Mit Secure Boot wird ein signierter shim.efi gefunden und gestartet. Ohne Secure Boot wird immer noch ein shim.efi gefunden und gestartet.

Es geht mir darum, dass ein shim.efi nur dann Sinn macht, wenn man Secure Boot benutzt. Sonst könnte man auch grubx64.efi nehmen. Also ist dein Endless OS ziemlich sicher mit aktiviertem Secure Boot installiert worden ... und der endless/-Eintrag mit aktiviertem Secure Boot ins NVRAM geschrieben worden.

Und selbst wenn du den Eintrag nicht sehen kannst, kannst du ihn vielleicht mit aktiviertem Secure Boot mit efibootmgr überschreiben (wie smutbert schon vorschlug). Wenn meine Theorie stimmt, dann hat der geänderte Eintrag auch bei wieder ausgeschaltetem Secure Boot bestand. Wenn smutberts Theorie stimmt, dann nicht.

Ich tendiere dazu zu glauben, dass das uefi von sich aus endless OS kennt und automatisch einen Booteintrag dafür erstellt.

Ja, das wäre ja ganz praktisch, wenn es das tun würde. Das tut es aber nicht.

Vielmehr beharrte es auf einem Eintrag zu einem nicht-existierenden Bootloader und zeigt diesen Eintrag nicht an.

Mag ja sein, dass endless/shim.efi wirklich hartkodiert im UEFI steht und bevorzugt behandelt wird. Aber wie du ja selber vermutest, muss man es irgendwie überschreiben können, vermutlich mit aktiviertem Secure Boot, ja.

Weiß eigentlich jemand Näheres über dieses Endless OS? Je mehr ich mich damit beschäftige, desto suspekter wird es mir. Warum ist gerade das so beliebt bei Acer (und anscheinend Asus)? Man würde vermuten, dass ein Ubuntu bekannter und besser dokumentiert und supportet ist.
Endless OS scheint plötzlich aus dem Nichts aufgetaucht zu sein. Die "Fachpresse" berichtet darüber seit ca. 2015 relativ arglos als ein Debian-Derivat mit ganz viel vorinstallierter Software.
Auf Youtube beschwert sich jemand über eine vorinstallierte, laufende und nicht-deinstallierbare Facebook-App:
https://www.youtube.com/watch?v=PpJds8FsVyo
Der Wikipedia-Eintrag liest sich unauffällig, aber mit eindeutig kommerziellem Hintergrund:
https://en.wikipedia.org/wiki/Endless_Computer
($176,538 für einen neuen Computer mit neuem Betriebssystem? Mark Shuttleworth kriegt das auch mit Milliarden nicht so richtig hin)
Endless Solutions umwirbt ausdrücklich Unternehmen und Regierungen damit, dass sie ihre maßgeschneiderten "Apps" mit Endless OS ausliefern können, und ausdrücklich inklusive Datensammelei:
https://endlessos.com/solutions/
Im Advisory Board findet sich dann eine recht illustre Sammlung an Persönlichkeiten:
https://endlessos.com/about-us/
mit tiefen Verbindung in die globale Wirtschaft, Medien, Bankwesen und Politik. Einige davon würde ich als wenig vertrauenswürdig einstufen, zum Beispiel den hier:
https://de.wikipedia.org/wiki/Anthony_Robbins
Niemand, den ich in einer "Tech"-Firma erwarten würde.
Das klingt so nach dem Geschäftsmodell "Wir bringen gegen Geld auch Ihre Spyware an den Mann und bezahlen die Firmen sogar noch dafür, wenn sie ihre Laptops mit Endless OS ausliefern". Für diese Vermutung finde ich aber keine Belege!
(wenn das hier off-topic ist, möge hikaru sich bitte beschweren)

[hikaru]

Warte ...
Mit "Debian-Grub" meinst du einen erfolgreichen Debian-Boot? Es geht also "alles"?

Ja.

Das ist mal wieder neu, oder? Hier:
viewtopic.php?f=12&t=169061&start=30#p1169481
schriebst du noch, dass bei einem gefundenen endless/shim.efi auch ein /endless/grubx64.efi existieren muss (und dort hatten wir nur funktionsfähige shim.efis ausprobiert).

Mit BOOT/bootx64.efi klappt es jetzt also auch, wenn shim.efi nicht aus /dev/zero stammt? Faszinierend ...

Ich war bisher noch nicht auf die Idee gekommen, grubx64.efi in bootx64.efi umzubenennen.
/endless/grubx64.efi bootet.
/boot/grubx64.efi bootet nicht.
/boot/bootx64.efi bootet.

(Jeweils die selbe Datei; bei vorhandener Datei namens /endless/shim.efi)

Ich hänge da der gleichen Glaubensrichtung an wie smutbert ... ich vermute, mit aktiviertem Secure Boot verhält sich dein UEFI wesentlich berechenbarer. Dass du es für den Debian-Betrieb nicht haben willst, ist klar ... aber Debian bootet ja auch ohne. Nur dieser blöde endless/-Eintrag und das blockierte "F2", die nerven halt ...

Wie gesagt, in meinen (nicht systematischen) Tests sah ich keinen Verhaltensunterschied beim Booten zwischen eingeschaltetem und ausgeschaltetem Secure Boot - weder bei Endless, noch bei Debian oder Ubuntu.
Ob es daran liegt, das ich das /endless-Verzeichnis zum Booten von Debian nutze, weiß ich nicht.

Zumindest sehe ich im UEFI (mit und ohne Secure Boot) keine "Endless-Einträge", die darauf schließen lassen würden, dass das konfigurierbar sei.

Hattest du das auch mit Endless OS ausprobiert? Nach meiner Theorie könnte der Endless-Eintrag vielleicht nur auftauchen, wenn endless/shim.efi vorhanden ist und Secure Boot aktiviert ist (eventuell auch nur, wenn von endless/shim.efi gebootet wird).

Mit angeschlossener Endless-HDD taucht diese als Bootoption im UEFI auf, egal ob mit oder ohne Secure Boot. Das Gleiche gilt aber auch für Debian (falls gerade eine bootfähige Kombination von *.efi-Dateien vorliegt) und die Ubuntu- und rEFInd-Sticks.
Hier ist also nichts Endless-Spezifisches.

Und selbst wenn du den Eintrag nicht sehen kannst, kannst du ihn vielleicht mit aktiviertem Secure Boot mit efibootmgr überschreiben (wie smutbert schon vorschlug).

Dafür bräuchte ich efivas/efivarfs, richtig? Das ginge also nach aktuellem Stand nicht unter Debian oder Ubuntu.

Weiß eigentlich jemand Näheres über dieses Endless OS?

Zumindest sieht das Dateisystem "interessant" aus. Es gibt auf der root-Partition nicht direkt die üblichen Linux-Systemverzeichnisse (/usr, /lib, /home, etc.), sondern da gibt es kryptische Unterverzeichnisse unter denen letztendlich zwei getrennte Linux-Installationen liegen. Das eine ist das Arbeitssystem und ich vermute, das andere ist so eine Art Recovery-System.
Außerdem habe ich irgendwo Datenschutzbedenken von Endnutzern aufgeschnappt, die sich so lasen, als würde Endless gern "nach Hause telefonieren". U.a. deshalb habe ich dem System, wenn ich es gebootet habe, nie Zugriff auf irgendein Netzwerk gegeben.

Man würde vermuten, dass ein Ubuntu bekannter und besser dokumentiert und supportet ist.………………

Vielleicht nimmt man es gerade deshalb nicht.

Ich habe vor Jahren mal LinuxXP auseinandergenommen. Das war eine auf Fedora basierende Distribution, deren Gnome2 dermaßen verbogen wurde, dass es oberflächlich tatsächlich wie Vista aussah. Der Standardbrowser war IE, der Standard-Texteditor Notepad (beides über Wine) und ich glaube sogar die Icons von Openoffice waren gegen welche von MS Word. Excel etc. ausgetauscht.
Es war ein recht umfangreiches Java-Gedöns aufgepfropft, das sich sowohl um die Vista-Optik (das Gnome-Menü sah 1:1 wie Vistas Startmenü aus, so lange man nichts lokalisierte) als auch um eine Nagware kümmerte, die den Nutzer zur kostenpflichtigen Registrierung des Systems innerhalb von 30 Tagen nach Installation aufforderte und das System nach Ablauf der Frist unbenutzbar machte.
Beim Versuch, nur die Nagware loszuwerden stellte sich das ganze Java-Geraffel als sehr widerspenstig heraus. Wurde die Nagware gekillt, startete sie nach wenigen Sekunden von selbst neu. Löschte man sie, dann kam sie nach einem Reboot aus einem Recovery-Bereich wieder. Löschte man den Recovery-Bereich, dann verweigerte das System beim nächsten Boot den Start des X-Servers.
Was letztendlich half war die Deinstallation von Java. Aber damit war auch das ganze Blingbling weg, und vom "Vista-Desktop" blieb nur noch das Gnome2 ohne Themes zurück.

Mit Fedora (und vermutlich auch Debian) kann man sowas wohl machen. Aber wenn eine Firma wie Canonical davon Wind bekäme, dass jemand ihre Distribution so verhunzt, dann gäbe es wohl Ärger. Nun ist Endless wohl längst nicht so verbogen wie LinuxXP, aber Canonical hat sich wegen weit weniger mit Mint angelegt.

[NAB]

Ich war bisher noch nicht auf die Idee gekommen, grubx64.efi in bootx64.efi umzubenennen.
/endless/grubx64.efi bootet.
/boot/grubx64.efi bootet nicht.
/boot/bootx64.efi bootet.

(Jeweils die selbe Datei; bei vorhandener Datei namens /endless/shim.efi)

Das wird ja immer drolliger. Also ohne /endless/shim.efi kommst du nicht ins UEFI.
Mit /endless/shim.efi hätte er gerne ein /endless/grubx64.efi. Wenn er das nicht findet, nimmt er auch ein /boot/bootx64.efi (also den Removable Media Path).
Dabei ist es egal, ob shim.efi ausführbar ist.

Das kann eigentlich nur bedeuten, dass das UEFI sich beide Pfade gemerkt hat: /endless/shim.efi und /endless/grubx64.efi. Ich bin erstaunt.

Mit angeschlossener Endless-HDD taucht diese als Bootoption im UEFI auf, egal ob mit oder ohne Secure Boot. Das Gleiche gilt aber auch für Debian (falls gerade eine bootfähige Kombination von *.efi-Dateien vorliegt) und die Ubuntu- und rEFInd-Sticks.
Hier ist also nichts Endless-Spezifisches.

hmm ... da sagst du was. Hat die Endless HDD eigentlich ein /boot/bootx64.efi?
Sonst würde ich eigentlich einen sprechenden Eintrag "EndlessOS" erwarten, der auf /endless/shim.efi verweist, um die Platte booten zu können.

Dafür bräuchte ich efivas/efivarfs, richtig? Das ginge also nach aktuellem Stand nicht unter Debian oder Ubuntu.

Mit Debian ginge es eh nicht, außer du bastelst dir ein Secure Boot zurecht. Bei Ubuntu bin ich mir nicht sicher, ob du die Experimente mit oder ohne Secure Boot gemacht hast. Die anderen Berichte aus dem Netz deuten darauf hin, dass es mit Secure Boot geht. Und mit Endless OS (und Secure Boot) müsste es klappen ... irgendwie wurde das ja mal installiert (und wie ich vermute, ins UEFI eingetragen)

Wie auch immer ... entweder du probierst es aus oder du gibst dich mit dem jetzigen Zustand zufrieden. Wir haben ja schon einiges herausbekommen und eigentlich läuft es ganz gut.

Zumindest sieht das Dateisystem "interessant" aus. Es gibt auf der root-Partition nicht direkt die üblichen Linux-Systemverzeichnisse (/usr, /lib, /home, etc.), sondern da gibt es kryptische Unterverzeichnisse unter denen letztendlich zwei getrennte Linux-Installationen liegen. Das eine ist das Arbeitssystem und ich vermute, das andere ist so eine Art Recovery-System.

Laut linux-community wird das mittels "OSTree" realisiert und sorgt dafür, dass das Ur-System neben den Updates erhalten bleibt. Außerdem werden angeblich sämtliche Anwendungen als Flatpak installiert:
http://www.linux-community.de/Internal/ ... article_i7

Man würde vermuten, dass ein Ubuntu bekannter und besser dokumentiert und supportet ist.………………

Vielleicht nimmt man es gerade deshalb nicht.
[...]
Mit Fedora (und vermutlich auch Debian) kann man sowas wohl machen. Aber wenn eine Firma wie Canonical davon Wind bekäme, dass jemand ihre Distribution so verhunzt, dann gäbe es wohl Ärger. Nun ist Endless wohl längst nicht so verbogen wie LinuxXP, aber Canonical hat sich wegen weit weniger mit Mint angelegt.

Du argumentierst, warum Endless Solutions sich nicht Ubuntu als Basis für Endless OS ausgesucht hat. Damit hast du wohl Recht. Mir ging es aber um die Frage, warum Acer sich sowas unbekanntes wie Endless OS aussucht, und nicht was Bekanntes (und berechenbareres) wie Ubuntu. Die Antwort könnte sein, dass Endless halt das bessere (besser verhunzte) Angebot macht.

[owl102]

Ich bin erstaunt.

Naja, diie Frage ist, wie der Booteintrag bei der Auslieferung des Rechners ins NVRAM kommt, wenn man nicht den Removable Media Path nehmen möchte, aus welchen Gründen auch immer. Die Platte wird vorbespielt und eingebaut. Beim Kunden muß sie dann booten können. Acer war hier wohl recht unkreativ und hat einfach die Pfade für Endless OS in ihr UEFI eingebaut. Daß andere OS als MS-Windows oder Endless OS Probleme ohne Ende machen dürfte Acer wohl am Allerwertesten vorbeigehen. (Für mich ein Grund mehr, um Acer einen großen Bogen zu machen.)

[NAB]

Acer war hier wohl recht unkreativ und hat einfach die Pfade für Endless OS in ihr UEFI eingebaut.

Ja, "die Pfade", das ist es ja. Wenn Acer (oder der Programmierer) möglichst arbeitssparsam hätte vorgehen wollen, dann hätte es gereicht, endless/shim.efi einzubauen.

Man könnte sich auch noch vorstellen, dass der UEFI-Programmierer keine Ahnung hat, sieht "Oh, endless/shim.efi und endless/grubx64.efi?" und sich denkt "Na gut, Linux braucht wohl zwei Bootloader, ich bau mal beide ein". Dann würde man aber erwarten, dass beide gleichberechtigt funktionieren. Tun sie aber nicht. endless/shim.efi schaltet "F2" frei, endless/grubx64.efi nicht.

[owl102]

Du unterstellst dem Entwickler, daß er sich bei seinem Tun etwas gedacht hat und dies dann gewissenhaft umgesetzt hat. Ich neige eher dazu, zu dem Schluß zu kommen, daß die Indizien eine andere Sprache sprechen. Wir haben es aufgrund von Unwissenheit und Schlampigkeit mit Fehlern zu tun, und versuchen herauszufinden, wann welcher Fehler greift. Dementsprechend greift es IMHO ins Leere, irgendein sinnvolles Verhalten zu erwarten. Ich denke zum Beispiel nicht, daß es gewollt war, F2 zu sperren, wenn der shim von Endless OS nicht auf der Platte ist.

[NAB]

Du unterstellst dem Entwickler, daß er sich bei seinem Tun etwas gedacht hat und dies dann gewissenhaft umgesetzt hat.

Nein. Ich sehe nur, dass der Entwickler hier eine Ungleichbehandlung zweier Pfade implementiert hat. Das würde ich bei möglichst schneller und schlampiger Entwicklung nicht erwarten. Alternativ ziehe ich auch in Erwägung, dass meine Interpretation falsch ist und es eine Interpretation gibt, die mehr Sinn ergibt. Also ... eigentlich hoffe ich auf etwas, was mehr Sinn ergibt

[hikaru]

Das wird ja immer drolliger. Also ohne /endless/shim.efi kommst du nicht ins UEFI.

Ohne /endless/shim.efi komme ich nur dann in's UEFI, wenn es auch keine anderen *.efis nirgends gibt.

Hat die Endless HDD eigentlich ein /boot/bootx64.efi?

Ja. Das komplette Listing der Endless-EFI-Partition hatte ich hier abgekippt. [1]

Sonst würde ich eigentlich einen sprechenden Eintrag "EndlessOS" erwarten, der auf /endless/shim.efi verweist, um die Platte booten zu können.

Weit und breit keine Spur von irgendeinem sprechenden Endless-Eintrag, mal abgesehen vom /endless-Verzeichnis selbst.

Laut linux-community wird das mittels "OSTree" realisiert und sorgt dafür, dass das Ur-System neben den Updates erhalten bleibt. Außerdem werden angeblich sämtliche Anwendungen als Flatpak installiert:
http://www.linux-community.de/Internal/ ... article_i7

Genau so ist es. Mir war nur der Name "OSTree" wieder entfallen.

Ich werde es wohl beim aktuellen Zustand belassen. Interessant wäre vielleicht nochmal auszuprobieren, ob Debians grubx64.efi getarnt als /endless/shim.efi dazu führt, dass mit nur einem einzigen *.efi weit und breit sowohl F2 als auch Debian starten. Aber dazu bin ich momentan zu faul.


[1] viewtopic.php?f=12&t=169061&start=15#p1168700

[NAB]

Ja. Das komplette Listing der Endless-EFI-Partition hatte ich hier abgekippt. [1]

Upps, sorry .. als ich es gesehen habe, fiel es mir auch wieder ein.

Im Prinzip wäre die Endless-HDD auch ohne jeglichen (unsichtbaren) Booteintrag bootbar, das macht uns also auch nicht schlauer.

Mir ist gerade noch ein interessantes Detail aufgefallen, und zwar hier:
https://github.com/rhboot/shim/blob/mas ... E.fallback
Ich weiß nicht, wie ich das "and create new boot variables" verstehen soll, aber es klingt so, als würde Shim selber nach erfolgreicher Installation den UEFI-Eintrag wiederherstellen, falls er verschwindet, also eigenmächtig ins NVRAM schreiben. Das bringt mir aber auch keine verwertbaren Erkenntnisse.

Ich denke, das einzig Interessante wäre es noch, das Endless OS mit aktiviertem Secure Boot zu starten und zu schauen, was der efibootmgr dann entdeckt. Andererseits kann man sich solche Experimente auch aufheben, bis Buster mal Secure Boot unterstützt ...