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

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

[smutbert]

Entschuldigung für das Ausgraben und wahrscheinlich ist es nicht mehr von großem Interesse, aber als hikaru geschrieben hat, dass grub-install hängt und ich das mit den efi-Variablen in Zusammenhang gebracht habe, habe ich empfohlen ein paar Module zu blacklisten, damit die efi-Variablen nicht mehr geändert werden können.
Ich habe gewußt, dass ich das schon einmal anders (und meinem Gefühl nach besser) gelöst habe, aber nicht mehr wie.

Jetzt ist es mir wieder eingefallen:
Statt dem Blacklisten von Kernelmodulen habe ich den Kernelparameter »noefi« verwendet. Das hat den denselben Effekt ohne, dass er durch das explizite Laden der Module zunichte gemacht werden kann und es lässt sich praktischerweise bequem beim Booten von Livesystemen oder ähnlichem verwenden.