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

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