ubuntuusers.de

EFI_Problembehebung

Status: Gelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels EFI_Problembehebung.

aasche

Anmeldungsdatum:
30. Januar 2006

Beiträge: 14259

Ist es wirklich notwendig, innerhalb des Artikels urheberrechtlich geschuetztes Material (konkret: das Win8-Logo) zu verwenden? Obwohl auf den ersten Blick nichts dagegen spricht, bin ich kein Freund der Praxis, sich einfach bei Closed-Source-Programmen zu bedienen und (unbewusst) so zu tun, als waere es das Gleiche wie OSS.

Anmerkung: dies ist meine persoenliche Meinung und (noch) kein rechtliches Problem.

aasche

(Themenstarter)

Anmeldungsdatum:
30. Januar 2006

Beiträge: 14259

Aufgrund der aktuellen Situation zum UEFI-Logo stelle ich meine Frage nochmal: ist das Logo von Windows 8 wirklich notwendig? Welchen Mehrwert traegt es zum Inhalt des Artikels bei?

axt

Anmeldungsdatum:
22. November 2006

Beiträge: 34254

Entferne das Win8-Logo doch einfach! uu-de ist ein Linux-Portal und keine Werbefläche für konkurrierende kommerzielle Software.

Nachtrag: Habe sowohl Win8- als auch UEFI-Logo auskommentiert. Man kümmert sich zuerst um Lizenzen.

raabf

Avatar von raabf

Anmeldungsdatum:
6. Juli 2014

Beiträge: Zähle...

Ich habe mir mal den Anzeige des NVRAM Teil näher angesehen und konnte es leider mit dieser Vorgehensweise nicht zum funktionieren bringen mein Ubuntu 14.04 zu starten. Ich habe ein bisschen rumprobiert und auch mal andere gefragt, von denen es auch einer bestätigt hat. Genauere Deteils: http://superuser.com/q/777634/341696 Hat das mal mit einer älteren Windows Version funktioniert oder so?

Naubaddi

Avatar von Naubaddi

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 744

Hi,

was mir bei den vielen Infos zu EFI gefehlt hat ist ein Hinweis auf die Problematik mit 64Bit Computern/Tabletts die ein 32Bit EFI haben, es hat mir reichlich Zeit gekostet dieses heraus zu finden und wie man damit umgeht.

Um z.B. einen USB-Stick mit Ubuntu zu erstellen der als Live-System funktioniert braucht man nicht viel, eine Ubuntu iso und eine bootia32.efi die man von Hand auf den erstellten USB-Stick nach /EFI/boot/ kopiert.

Grüßle

Frieder108

Avatar von Frieder108

Anmeldungsdatum:
7. März 2010

Beiträge: 9573

hier wird ja beschrieben, wie man einen Eintrag deaktiviert, also im Beispiel mit

sudo efibootmgr -b 0000 -A

den Eintrag deaktivieren und dann die Bootreihenfolge

sudo efibootmgr -o 0000,0004,0001,0002,0003 

ergibt ja, dass "0004" als erstes bootet.

Was ich vermisse, ist ein Hinweis, wie man den deaktivierten Eintrag "0000" wieder aktivieren kann?

nachfragende Grüße

Frieder

apt-ghetto

Anmeldungsdatum:
3. Juni 2014

Beiträge: 2943

Frieder108 schrieb:

Was ich vermisse, ist ein Hinweis, wie man den deaktivierten Eintrag "0000" wieder aktivieren kann?

Das steht im Artikel zum efibootmgr, also sinngemäss

sudo efibootmgr -b 0000 -a  

Noch etwas anderes:

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi  

Ist das die einzige richtige Variante oder sollte man bei aktiviertem secure boot eher

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi  

verwenden? Ich kann das leider nicht selbst testen.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Hallo Gerry Ghetto & Frieder108,

das kommt dabei heraus, wenn unqualifizierte Änderungen am WIKI vorgenommen werden - hier durch nixCorvus.

Das Verändern des Windows-Eintrag wie von nixCorvus eingearbeitet führt dazu, dass das Windows überhaupt nicht mehr startet - also auch nicht über einen Aufruf seitens GRUB 2!

Wir werden das sofort wieder entfernen und das mit dem efibootmgr deutlicher herausstellen.

gruß syscon-hh

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Das Verändern des Windows-Eintrag wie von nixCorvus eingearbeitet führt dazu, dass das Windows überhaupt nicht mehr startet - also auch nicht über einen Aufruf seitens GRUB 2!

Vorweg: Ich finde die Lösung von nixCorvus auch suboptimal und ein Anwender, der nach einem

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi 

sein Windows nicht mehr starten kann, ist auch für mich schon aus menschlichen Gründen ein verärgerter Anwender zu viel; auch, wenn vielleicht Windows hier im Forum keine Priorität hat.

Ich nehme aber schon an, dass nixCorvus den Befehl bei sich erfolgreich (Windows blieb startbar) getestet hat; zumindest, dass nixCorvus den Befehl aus einer Anleitung hat, die schon jemand anderer getestet hat. Ich habe hier zumindest ein UEFI-Problemgerät, bei dem auch nach diesem Befehl Windows noch startbar blieb.

So weit ich das gesehen habe, wurde bei

bcdedit /enum firmware 

nach diesem Untergriff und einem Neustart der ursprüngliche Eintrag mit "\EFI\Microsoft\Boot\bootmgfw.efi" nun als "Firmware-Anwendung" gelistet. Als GUID wurde jene gewählt, die vorher {bootmgr} zugeordnet war. {bootmgr} hatte nun eine neue GUID und den neuen Pfad "\EFI\ubuntu\grubx64.efi".

Wenn das aber nur manchmal so funktioniert und auch unklar ist, wie lange das stabil bleibt, würde ich das auch so nicht ins Wiki aufnehmen; die Idee, die hinter der Wiki-Änderung von nixCorvus steckte, war aber aus meiner Sicht auch nicht ganz falsch.

Was eventuell schon noch sinnvoll wäre, wäre eine Windows-Lösung für bcdedit, die auch jene Fälle abdeckt, die mit den bestehenden Tipps für bcdedit - aus welchen Gründen auch immer (SecureBoot, alte UEFI-Firmware?, Windows-Konfiguration?) nicht funktionieren.

Mein Vorschlag dazu wäre ein Skript wie dieses:

@ECHO OFF
rem Ubuntu-EFI-Starteintrag

for /f "tokens=2 delims={}" %%a in ('bcdedit /copy {bootmgr} /d "Ubuntu Secure Boot"') do set guid={%%a}
bcdedit /set %guid% path \EFI\ubuntu\shimx64.efi
bcdedit /set {fwbootmgr} displayorder %guid% /addfirst

bcdedit /enum firmware 

Das Skript lässt den aktuellen Eintrag für den aktuellen Bootmanager {bootmgr} unverändert. Es wird eine Kopie davon erstellt und dort dann der Name des Eintrags und das zu startende EFI-Programm geändert. Danach wird dieser Bootmanager ("Windows-Start-Manager") im EFI-Menü an erste Stelle gesetzt. Der letzte Befehl listet dann alle Einträge, die für die EFI-Firmware relevant sind (nur zur Kontrolle).

Das sieht auf den ersten Blick nicht viel anders aus, als das, was bereits im Wiki steht. Der Unterschied ist nur, dass ein "Windows-Start-Manager" im EFI-Menü eingetragen wird und auch von dort direkt gestartet wird, ohne dass ein "Windows Boot Manager" vorher aufgerufen wird. Der Eintrag für den "Windows Boot Manager" bleibt im EFI-Menü in geänderter Reihenfolge weiterhin bestehen und kann auch weiterhin dort gestartet werden. Wird der "Windows Boot Manager" gestartet, gibt es dann natürlich keinen zusätzlichen Eintrag für Ubuntu mehr; der befindet sich ja bereits im EFI-Menü.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Du hast es ja richtig herausgearbeitet - es wurde als Befehl einzig

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi 

vorgegeben - nichts Anderes. Und danach startet kein Windows mehr. Eine Sicherung des Eintrages war da nicht vorgesehen. Das es komplexer ist, kann man Deinem obigen Beitrag entnehmen.

Und diese Abhandlung ist hier bei Ubuntu u.E. fehl am Platze.

Außerdem es geht nur um einen ganz bestimmten Hersteller und ein bestimmtes (Fehl-)Verhalten, bei dem das UEFI vermutlich aus kommerziellen Überlegungen so verunstaltet wurde.

Die einfache Lösung über Ubuntu und dann efibootmgr erscheint uns an dieser Stelle angebrachter.

Und außerdem: Alle Problemfälle detailiert in unserem Wiki zu erfassen, erscheint uns ohnehin unmöglich.

hakunamatata Team-Icon

Supporter
Avatar von hakunamatata

Anmeldungsdatum:
30. Juni 2009

Beiträge: 5130

syscon-hh schrieb:

Du hast es ja richtig herausgearbeitet - es wurde als Befehl einzig

bcdedit /set {bootmgr} path \EFI\ubuntu\grubx64.efi 

vorgegeben - nichts Anderes. Und danach startet kein Windows mehr. Eine Sicherung des Eintrages war da nicht vorgesehen. Das es komplexer ist, kann man Deinem obigen Beitrag entnehmen.

Sicherung vor dem Befehl hab ich natürlich gemacht. SecureBoot war ebenfalls deaktiviert. Aber sonst habe ich wirklich nur einzig diesen Befehl testweise ausgeführt und beobachtet, was passiert. Was mit der GUID passiert, war auch nur eine Beobachtung und der etwas komplexere Vorschlag danach unabhängig davon.

Ich kann nur sagen, dass es bei mir auch mit diesem Befehl alleine auf einem Problemgerät funktionieren würde, ohne dass Windows unstartbar wird; aber wenn du mit auf jeden Fall umfangreicheren Erfahrungswerten sagst, im Regelfall ist danach Windows unstartbar, ist das keine Lösung die im Wiki stehen sollte. Da bin ich ganz deiner Meinung.

Ich könnte mir nur vorstellen, dass wenn es bei mir auf einem Gerät funktioniert hat, auch vielleicht bei nixCorvus oder anderen die diese Lösung ins Internet gestellt haben (z.B.: hier), genauso war.

Die einfache Lösung über Ubuntu und dann efibootmgr erscheint uns an dieser Stelle angebrachter.

Ist für mich auch OK. So weit ich mich erinnere, hat auf dem UEFI-Problemgerät auch die Lösung mit dem deaktivierten Eintrag funktioniert, so dass eine Löung mit bcdedit nicht notwendig gewesen wäre.

apt-ghetto

Anmeldungsdatum:
3. Juni 2014

Beiträge: 2943

syscon-hh schrieb:

Außerdem es geht nur um einen ganz bestimmten Hersteller und ein bestimmtes (Fehl-)Verhalten, bei dem das UEFI vermutlich aus kommerziellen Überlegungen so verunstaltet wurde.

Von welchem Hersteller reden wir hier?

Die einfache Lösung über Ubuntu und dann efibootmgr erscheint uns an dieser Stelle angebrachter.

Und außerdem: Alle Problemfälle detailiert in unserem Wiki zu erfassen, erscheint uns ohnehin unmöglich.

Nach allem, was ich hier und in einem anderen Ubuntu-Forum gelesen habe, sieht es so aus, als ob es bei den meisten HP-Rechner mit Dualboot (Win8, Ubuntu) nicht möglich ist, die Bootreihenfolge dauerhaft umzustellen, sodass entweder nur Win8 startet oder aber übers EFI-Boot-Menu Ubuntu ausgewählt werden muss. Auch das Deaktivieren der Booteinträge im NVRAM mittels efibootmgr hilft hier nicht. Könnte oder sollte man einen (Warn)Hinweis platzieren? Eine einfache Lösung (eine einfachere als: umbennen von bootmgfw.efi und ersetzen durch eine Kopie von shim oder aber EasyBCD) scheint es nicht zu geben.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Habe mal die Arbeitsschritte für ACER Rechner eingearbeitet - universell geht's eh' nicht - sind zu viele Varianten auch bei ACER unterwegs.

Wir haben hier diskutiert, die geräte-spezifischen Probleme und Lösungen in einen eigenen Artikel auszulagern bzw. zu sammeln, Z.B.: als

  • "EFI_Hardware-Lösungen"

gruß syscon-hh

Progressive

Anmeldungsdatum:
22. Januar 2016

Beiträge: 166

syscon-hh schrieb:

Habe mal die Arbeitsschritte für ACER Rechner eingearbeitet - universell geht's eh' nicht - sind zu viele Varianten auch bei ACER unterwegs.

Wir haben hier diskutiert, die geräte-spezifischen Probleme und Lösungen in einen eigenen Artikel auszulagern bzw. zu sammeln, Z.B.: als

  • "EFI_Hardware-Lösungen"

gruß syscon-hh

Mir fehlt(e) der Zusatz, dass die Bootreihenfolge "nachhaltig" nur geändert wird, wenn man diese nicht-live ändert. Der Befehl in der Art von sudo efibootmgr -o 0000,0004,0001,0002,0003 hat auch nicht funktioniert, nur sudo efibootmgr -n 0004.

syscon-hh

Anmeldungsdatum:
8. Oktober 2005

Beiträge: 10220

Das werden wir prüfen - in der Regel reicht es aus, nur den Eintrag vom ubuntu in der BootOrder an die erste Stelle mit

sudo efibootmgr -o 000X 

zu setzen (für X den relevanten Eintrag einsetzen). Allerdings erst, wenn dieser als zulässig freigeschaltet wurde.

Antworten |