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

Du kommst mit der Installation nicht voran oder willst noch was nachfragen? Schau auch in den "Tipps und Tricks"-Bereich.
NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 30.03.2018 15:26:19

owl102 hat geschrieben: ↑ zum Beitrag ↑
30.03.2018 10:13:46
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

owl102

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von owl102 » 30.03.2018 15:39:54

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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 30.03.2018 16:10:27

owl102 hat geschrieben: ↑ zum Beitrag ↑
30.03.2018 15:39:54
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 :mrgreen:
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von hikaru » 04.04.2018 22:46:11

NAB hat geschrieben: ↑ zum Beitrag ↑
29.03.2018 23:54:20
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.03.2018 23:54:20
Hat die Endless HDD eigentlich ein /boot/bootx64.efi?
Ja. Das komplette Listing der Endless-EFI-Partition hatte ich hier abgekippt. [1]
NAB hat geschrieben: ↑ zum Beitrag ↑
29.03.2018 23:54:20
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.
NAB hat geschrieben: ↑ zum Beitrag ↑
29.03.2018 23:54:20
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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: UEFI-Installation: "grub-install dummy" hängt

Beitrag von NAB » 05.04.2018 06:08:28

hikaru hat geschrieben: ↑ zum Beitrag ↑
04.04.2018 22:46:11
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 ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

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

Beitrag von smutbert » 24.04.2018 18:34:51

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.

Antworten