black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej UlfZibis, UlfZibis schrieb: ...Hat jemand eine Idee, wie ich dem beibringen kann, dass die EFI-bootorder so erhalten bleibt, wie sie von Ubuntu installiert wurde?
es gibt hier manchen thread, da wird dann der Vorschlag gemacht, den NVRAM Eintrag von Windows auf inactiv zu setzen; betraf aber mWn. andere Fabrikate, versuch 's halt. ...
Da sehe ich gar kein GRUB-Menü, jedenfalls nicht das von dem Ubuntu-Live-Medium. Das liegt wohl daran, dass ich dieses mittels einem MultiSystem-Datenträger starte. Dessen buntes GRUB-Menü sehe ich aber. Es scheint also, dass die GRUB-Konfiguration von Ubuntu es nicht schafft, den Lenovo-Splash-Screen auszuschalten.
ich hätte jetzt erwartet (Fehlereingrenzung!), daß Du dafür dann eben nicht irgendeine Variante verwendest, sondern einen mit dd erstellst und im EFI Modus bootest, da gibt es dann grub : Sichtbar oder eben nicht? naja, bei nem simplen Dualboot Ubuntu/Windows ist das evtl doch wie mit Kanonen auf Spatzen schießen → so ein Dualboot funktioniert normalerweise ohne jegliche Skriptbearbeitung "out of the box".
Sehe ich auch so.
aber bei Dir scheint ja eben kein "normalerweise" vorzuliegen. Gruß black tencate
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
black_tencate schrieb: es gibt hier manchen thread, da wird dann der Vorschlag gemacht, den NVRAM Eintrag von Windows auf inactiv zu setzen; betraf aber mWn. andere Fabrikate, versuch 's halt.
Das werde ich dann auch noch mal versuchen. Erst muss ich aber kapieren, was "inactive" bedeutet. Es stellt sich mir die Frage, ob es in der UEFI-Konfiguration evtl. sowas gibt, womit immer der zuletzt aufgerufene Bootloader in der bootorder nach oben geschoben und damit automatisch gestartet wird, also so ähnlich, wie es in GRUB per GRUB_DEFAULT=save passiert, oder ob Windows selbst da vielleicht reinpfuscht.
ich hätte jetzt erwartet (Fehlereingrenzung!), daß Du dafür dann eben nicht irgendeine Variante verwendest, sondern einen mit dd erstellst und im EFI Modus bootest, da gibt es dann grub : Sichtbar oder eben nicht?
Ich habe hier noch einen mit dd erstellten Ubuntu 18.04 amd64 Stick herumliegen. Mit dem komme ich in der Tat in das für Ubuntu übliche GRUB-Boot-Menü, genauso wie ich mit einem MultiSystem-Medium in das entsprechend bunte GRUB-Boot-Menü komme. Das bestärkt meine Vermutung, dass bei mir etwas mit GRUB bzw. dessen Konfiguration nicht stimmt. Vielleicht hat sich in das aktuelle GRUB ja ein Bug eingeschlichen.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej UlfZibis, UlfZibis schrieb: ...was "inactive" bedeutet
läßt sich alles nachlesen → efibootmgr (sudo efibootmgr -b xxxx -A ) Vielleicht hat sich in das aktuelle GRUB ja ein Bug eingeschlichen.
wohl eher in Deiner Konfiguration. Gruß black tencate
|
schollsky
Anmeldungsdatum: 3. Dezember 2012
Beiträge: 1491
Wohnort: Ruhrgebeat
|
Guten Abend allerseits, das merkwürdigste an der Problematik ist nach meiner Einschätzung das @-Zeichen in der Konfiguration. Hat sich die Syntax innerhalb von GRUB2 geändert? Das würde ich als erstes prüfen. Wenn hiermit eine Verknüpfung auf eine andere Partition/einen anderen Systembereich erzeugt wird, könnte das den Fehler verursachen. Das os-prober Skript ist zwar schon fortschrittlich, kann aber nicht jede Eventualität berücksichtigen. An Deiner Stelle würde ich vermutlich /boot auf einem externen Datenträger sichern, GRUB manuell auf Deinem primären Boot-Device installieren und dafür sorgen, dass keinerlei Bootinformation auf einem anderen Datenträger mehr vorhanden ist. Grüße schollsky
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej schollsky, schollsky schrieb: ...
das merkwürdigste an der Problematik ist nach meiner Einschätzung das @-Zeichen in der Konfiguration.
nein, das ist normal
blacktencate@T520-ff:~$ sudo os-prober
[sudo] Passwort…
[...]
/dev/sdb1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
[...]
blacktencate@T520-ff:~$ An Deiner Stelle würde ich…
es geht doch nur um ein paar 'verbogene' Skripte Gruß black tencate
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
black_tencate schrieb: ...was "inactive" bedeutet
läßt sich alles nachlesen → efibootmgr (sudo efibootmgr -b xxxx -A )
Ja, dass das eine Deaktivierung bewirkt, soweit gingen meine Englischkenntnisse auch schon vorher. Aber was hat das für Folgen, und warum wird diese Deaktivierung normalerweise nicht vorgenommen, und dennoch funktioniert – außer in meinem Fall – alles so wie es soll?
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej UlfZibis, UlfZibis schrieb: ...Aber was hat das für Folgen
eben daß der Eintrag nicht benutzt wird (ist ja inaktiv) und automatisch zum nächsten gewechselt wird; und wenn das eben ein Ubuntu/grub ist, dann hast Du Dein Menü. und warum wird diese Deaktivierung normalerweise nicht vorgenommen
weil das normalerweise nicht nötig ist, der Eintrag, den DU an erste Stelle setzt, wird "normalerweise" auch nicht verändert (außer durch eine O/S Installation) und dennoch funktioniert – außer in meinem Fall – alles so wie es soll?
Du meinst: Ubuntu EINS, Windows ZWEI und gut issssssss. Tja, da mußt Du
Windows den EFI Implementierer
fragen. Das ist aber nicht unbedingt allgemein gültig, das mit dem Inaktivsetzen. Gruß black tencate
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
black_tencate schrieb: eben daß der Eintrag nicht benutzt wird (ist ja inaktiv) und automatisch zum nächsten gewechselt wird; und wenn das eben ein Ubuntu/grub ist, dann hast Du Dein Menü.
Allerdings bisher nur das beschriebene Blindflug-Menü. Ansonsten ist das in der Tat ein "workaround".
weil das normalerweise nicht nötig ist, der Eintrag, den DU an erste Stelle setzt, wird "normalerweise" auch nicht verändert (außer durch eine O/S Installation)
Die Frage bleibt, wo der Bug ist, der den "workaround" nötig macht.
Du meinst: Ubuntu EINS, Windows ZWEI und gut issssssss. Tja, da mußt Du
Windows den EFI Implementierer
fragen.
Oder 3. die GRUB-Entwickler, ob sie vielleicht in ihrer neuesten Version das zuletzt gestartete OS in der EFI bootorder automatisch nach vorne schieben. Leider bin ich hier bisher scheinbar der einzig bekannt gewordene Fall, wo das Problem auftritt. Wenn noch andere so etwas oder ähnliches beobachtet hätten, ließ sich evtl. mutmaßen, welche der 3 Möglichkeiten zutrifft.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10958
|
Hej UlfZibis, UlfZibis schrieb: ...
Die Frage bleibt, wo der Bug ist, der den "workaround" nötig macht.
ein bißchen 'nachdenken' hilft: Was würdest Du sagen, wenn Du nach der Installation eines O/S (egal, ob jetzt Windows oder Linux und"legacy" oder EFI) NICHT booten würde. ❓ ...
Oder 3. die GRUB-Entwickler, ob sie vielleicht in ihrer neuesten Version das zuletzt gestartete OS in der EFI bootorder automatisch nach vorne schieben.
hä? Ich jedenfalls würde dann wohl nach einem anderen Bootloader Ausschau halten, ich möchte mich schon darauf verlassen, daß der Loader, den ich eingerichtet habe, nicht durch das zuletzt gebootete O/S verdrängt wird.
Leider bin ich hier bisher scheinbar der einzig bekannt gewordene Fall, wo das Problem auftritt. Wenn noch andere so etwas oder ähnliches beobachtet hätten, ließ sich evtl. mutmaßen, welche der 3 Möglichkeiten zutrifft.
da braucht man nicht lange mutmaßen:
ein LiveUSB Stick zeigt Dir sein grub Menü Dein – soll ich sagen Konstrukt? – zeigt trotz eingestellter Variablen GRUB_TIMEOUT_STYLE=… nicht so wie gewünscht; woran wird das wohl liegen?
Ich habe hier in letzter Zeit so viele Installationen gemacht, mit Beaver, Fossa und Gorilla quer durch alle Flavors, und immer nur gleich GRUB_TIMEOUT_STYLE=… von "hidden" auf "menu" gestellt, kein einziges mal hatte ich dann "schwarze Schrift auf schwarzem Grund". Gruß black tencate
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
black_tencate schrieb: Die Frage bleibt, wo der Bug ist, der den "workaround" nötig macht.
ein bißchen 'nachdenken' hilft: Was würdest Du sagen, wenn Du nach der Installation eines O/S (egal, ob jetzt Windows oder Linux und"legacy" oder EFI) NICHT booten würde. ❓
Nach der Installation läuft's ja, nur nicht mehr nach dem Start von Windows. Vielleicht finden die sich ja so wichtig, dass sie die von Ubuntu eingerichtete EFI-Boot-Reihenfolge wieder auf sich priorisieren.
Oder 3. die GRUB-Entwickler, ob sie vielleicht in ihrer neuesten Version das zuletzt gestartete OS in der EFI bootorder automatisch nach vorne schieben.
hä? Ich jedenfalls würde dann wohl nach einem anderen Bootloader Ausschau halten, ich möchte mich schon darauf verlassen, daß der Loader, den ich eingerichtet habe, nicht durch das zuletzt gebootete O/S verdrängt wird.
Von der Seite betrachtet muss ich Dir Recht geben. GRUB kann man demnach als Übeltäter ausschließen.
Leider bin ich hier bisher scheinbar der einzig bekannt gewordene Fall, wo das Problem auftritt. Wenn noch andere so etwas oder ähnliches beobachtet hätten, ließ sich evtl. mutmaßen, welche der 3 Möglichkeiten zutrifft.
da braucht man nicht lange mutmaßen:
ein LiveUSB Stick zeigt Dir sein grub Menü Dein – soll ich sagen Konstrukt? – zeigt trotz eingestellter Variablen GRUB_TIMEOUT_STYLE=… nicht so wie gewünscht; woran wird das wohl liegen?
Letzteres liegt wohl daran, dass das von Ubuntu installierte GRUB-Konstrukt nicht in der Lage ist, den BIOS-Splash zu unterdrücken. Die GRUB-Konstrukte sowohl vom Ubuntu- als auch MultiSystem-LiveUSB schaffen das ja. Das ist aber das andere Problem und betrifft nicht die EFI bootorder, über die wir hier ja sprechen.
Ich habe hier in letzter Zeit so viele Installationen gemacht, mit Beaver, Fossa und Gorilla quer durch alle Flavors, und immer nur gleich GRUB_TIMEOUT_STYLE=… von "hidden" auf "menu" gestellt, kein einziges mal hatte ich dann "schwarze Schrift auf schwarzem Grund".
Ich sonst auch immer, und das sogar mit GRUB_TIMEOUT_STYLE=hidden .
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
|