staging.inyokaproject.org

Bitte an das WIKI-Team:

Dieser Teil- / Unterabschnitt vom Projekt EFI Bootmanagement kann aus der Baustelle genommen werden.

In wie weit diese Diskussion mit der Projektseite und den anderen Kapiteln verknüpft werden muss / kann, überlasse ich Euch. Die technische Information wurde jetzt von uns ausreichend getestet.

gruß syscon-hh

Hallo,

Artikel ist im Wiki.

Gruß, noisefloor

Vielleicht sollte Boot-Repair in diesem Artikel erwähnt werden

https://help.ubuntu.com/community/Boot-Repair

Siehe meinen Erfahrungsbericht hier:

http://forum.ubuntuusers.de/topic/dualboot-von-ubuntu-13-4-und-windows-8-mit-uef/

Hallo zusammen,

ein paar Anmerkungen und Fragen zum Artikel/Verständnis (nach meinem erfolglosen Versuch, mit der chroot-Methode und einem Ubuntu 14.04-Live-System eine BIOS-GRUB-Installation auf EFI umzustellen):

• Gibt es Unterschiede zu anderen Live-Systemen als UNetbootin, sprich ISO-Image von ubuntu.com gebrannt oder usb-creator-gtk? Bitte noch als Halbsatz ergänzen (mit welchem wurde die Beschreibung getestet, welche für Vermutungen andere gibt es).

• Um grub-install in der chroot-Umgebung ausführen zu können, muss ich ebenso /bin (für efibootmgr) und /usr/lib/grub in diese mounten. Spricht etwas dagegen die Mountpoints zu ergänzen (die Änderungen führen bei mir nur dazu, dass grub-install ausgeführt wird, die Installation wird allerdings nicht korrekt ausgeführt (der EFI-Eintrag wird beim Start einfach übersprungen), aber vielleicht hilft es bei anderen, die Ausführung von grub-install ist ohnehin nötig)?

• Die Überschrift "Andere Distribution einbinden" muss meiner Ansicht nach angepasst werden, da der Begriff einbinden einfach zu viele Bedeutungen - zumal in der UNIX-Welt - hat und die Assoziationsfähigkeit stark einschänkt. Ich habe auch noch immer nicht verstanden, was der Absatz beschreibt. Wird ein Multiboot-System eingerichtet? Für bestehende OS oder soll eine Möglichkeit geschaffen werden, zukünftig OS "einzubinden", d.h. beim Systemstart zur Auswahl zu stellen? Soll im laufenden System etwas eingebunden werden? Sind die Schritt dafür notwendig oder eine Optimierung?

• Es wäre besser, den Artikel neu aufzusetzen und ihn vom Standpunkt der Notwendigkeit zu schreiben, liest man z.B. den Absatz "Anderes Bootverzeichnis erstellen" ist unklar, ob das nun notwendig ist, oder nicht - man kann es sich erschließen, aber die - sagen wir mal - nicht-maximale Klarheit ist nicht notwendig.

Beste Grüße, Kalle

J8iv6k9oi4rv schrieb:

Hallo zusammen,

ein paar Anmerkungen und Fragen zum Artikel/Verständnis (nach meinem erfolglosen Versuch, mit der chroot-Methode und einem Ubuntu 14.04-Live-System eine BIOS-GRUB-Installation auf EFI umzustellen):

• Gibt es Unterschiede zu anderen Live-Systemen als UNetbootin, sprich ISO-Image von ubuntu.com gebrannt oder usb-creator-gtk? Bitte noch als Halbsatz ergänzen (mit welchem wurde die Beschreibung getestet, welche für Vermutungen andere gibt es).

Im Artikel steht doch z.B. - das heißt doch, dass es auch mit anderen Tools geht - solange es nur ein für ein EFI Bootmanagement passendes Ergebnis ergibt.

• Um grub-install in der chroot-Umgebung ausführen zu können, muss ich ebenso /bin (für efibootmgr) und /usr/lib/grub in diese mounten. Spricht etwas dagegen die Mountpoints zu ergänzen (die Änderungen führen bei mir nur dazu, dass grub-install ausgeführt wird, die Installation wird allerdings nicht korrekt ausgeführt (der EFI-Eintrag wird beim Start einfach übersprungen), aber vielleicht hilft es bei anderen, die Ausführung von grub-install ist ohnehin nötig)?

Nein ausschließlch die beschriebenen Schritte sind erforderlich. Die anderen Verzeichnisse sind nicht erforderlich, den EFI-Eintrag neu zu (über) schreiben. Und das mit dem

/bin (für efibootmgr)

stimmt so nicht - dann ist im System ein anderer Fehler, der nichts mit diesem Teilabschnitt / einer Reparatur zu tun hat.

• Die Überschrift "Andere Distribution einbinden" muss meiner Ansicht nach angepasst werden, da der Begriff einbinden einfach zu viele Bedeutungen - zumal in der UNIX-Welt - hat und die Assoziationsfähigkeit stark einschänkt. Ich habe auch noch immer nicht verstanden, was der Absatz beschreibt. Wird ein Multiboot-System eingerichtet?

Es steht doch dort: Bis Raring Ringtail ist dieses relevant - danach ist die Beschreibung ohnehin obsolet und wird bald ganz rausfallen.

Für bestehende OS oder soll eine Möglichkeit geschaffen werden, zukünftig OS "einzubinden", d.h. beim Systemstart zur Auswahl zu stellen? Soll im laufenden System etwas eingebunden werden? Sind die Schritt dafür notwendig oder eine Optimierung?

Bitte mal lesen - das Letztere wäre dann nicht Bestandteil dieses Artikels - dass wird dann wie verlinkt, in GRUB 2/Skripte nachzulesen sein.

• Es wäre besser, den Artikel neu aufzusetzen und ihn vom Standpunkt der Notwendigkeit zu schreiben, liest man z.B. den Absatz "Anderes Bootverzeichnis erstellen" ist unklar, ob das nun notwendig ist, oder nicht - man kann es sich erschließen, aber die - sagen wir mal - nicht-maximale Klarheit ist nicht notwendig.

Dann hast Du das mit dem Überschreiben nicht verstanden - es ist zugegeben ein seltener Fall, dass man sich mehrere Derivate anlegt - aber kommt eben vor. Und diese Benutzer merken sehr schnell, was Sache ist.

Und ohne ein schlüssiges Konzept für das Bootmanagement geht es in einem solchen Fall ohnehin nicht.

gruß syscon-hh

Nein ausschließlch die beschriebenen Schritte sind erforderlich.

Ok, danke für die Info, dann muss ich ein bisschen tüfteln oder nochmal im Forum fragen.

Dann hast Du das mit dem Überschreiben nicht verstanden

Ja klar, meine Kritik ist auch (fast) ausschließlich an die Eingänglichkeit und den Aufbau des Artikels gerichtet.

Bitte mal lesen

Das habe ich schon vor dem ursprünglichen Post und nach deiner/vor meiner Antwort erneut getan. Ich komme aber zu dem gleichen Urteil, dass ein anderer Aufbau die Klarheit (wie beschrieben) verbessern würde.

Beste Grüße, Kalle

Hallo zusammen,

auch von mir erstmal ein dickes Dankeschön für diese tolle Artikelserie.

Ich finde allerdings, dass der Abschnitt EFI Eintrag neu erstellen in den Artikel EFI Problembehebung gehört.

Begründung: Wenn jemand seinen EFI-Eintrag gelöscht hat, ist das ein Problem, dass in der Regel in keinem zeitlichen Zusammenhang mit der Installation steht. Im Allgemeinen ist der EFI-Eintrag nach der Installation ja vorhanden. Eine Nachbearbeitung ist somit nicht erforderlich.

Wie seht Ihr das?

Viele Grüße

Vej

Vej schrieb:

Ich finde allerdings, dass der Abschnitt EFI Eintrag neu erstellen in den Artikel EFI Problembehebung gehört.

Ja das kann man so machen!

gruß syscon-hh

Hallo.

Vej schrieb:

Ich finde allerdings, dass der Abschnitt EFI Eintrag neu erstellen in den Artikel EFI Problembehebung gehört.

Ich habe den Absatz EFI Eintrag neu erstellen als EFI-Eintrag wurde gelöscht oder zerstört in den Artikel EFI Problembehebung verschoben. Die Änderung des Titels war notwendig um dem Konzept des Zielartikels zu entsprechen. Dort werden Lösungen nach den Problemen benannt.

In diesem Artikel habe ich einen Hinweis belassen, damit Links in den Supportforen nicht ins Leere laufen. Wenn jemand mit mehr Ahnung da eine bessere Lösung (oder auch nur eine bessere Formulierung) kennt, wäre ich über eine kleine Anpassung dankbar.

Viele Grüße

Vej

Folgendes steht momentan im Wiki:

Experten-Info:

Das Verzeichnis /boot/efi/EFI/ubuntu darf nie gelöscht werden - dieses wird immer von dem aktuellen primären Betriebssystem benutzt! Die sekundären Betriebssysteme werden dann über den GRUB 2-Eintrag im primären Betriebssystem aufgerufen / gestartet.

Nachdem ein sekundäres Betriebssystem über das primäre Betriebssystem gestartet werden kann, sollte man den Eintrag im NVRAM für das sekundäre Betriebssystem wieder löschen!

Warum sollte man den Eintrag im NVRAM wieder löschen?

Damit dieser nicht (ungewollt) aufgerufen wird.

Da sei z.B. ein zweiter Eintrag für Ubuntu, der durch das Installieren eben entstehen kann. Dieser hat aber den Inhalt einer beliebigen Installation, die nichts mehr mit dem Inhalt vom Verzeichnis /boot/efi/EFI/ubuntu zu tun hat.

Als Beispiel siehe diesen Forenbeitrag.

Wollte gerade ein Edit einfügen und auf den von dir genannten Beitrag verweisen. 😀

Danke für die Aufklärung!

Hab hier mal eine Unklarheit/ Ungenauigkeit.

Hier steht oben:

Die Nutzung von secure-boot ist erst mit der aktuellen Ausgabe von Precise Pangolin-12.04 LTS sinnvoll/problemlos möglich.

In EFI Grundlagen:

Die Nutzung von secure-boot ist erst ab Precise Pangolin Version 12.04.2 LTS sinnvoll/problemlos möglich.

Und dann in EFI Grundlagen:

Erst ab Trusty Tahr (14.04 LTS) kann man Ubuntu sowie alle Derivate auch im secure-boot-Modus starten

Oder bezieht sich das nur auf den Start? So dass man bei 12.04.2 secure boot nach der Installation wieder aktivieren konnte und zuvor deaktivieren musste, um booten zu können?

Grüße, Benno

Sieht im ersten Moment widersprüchlich aus:

... erst mit der aktuellen Ausgabe von Precise Pangolin-12.04 LTS

und

... erst ab Precise Pangolin Version 12.04.2 LTS

Der erste Hinweis ist eine unpräzise Angabe, die die zweite präzise Angabe mit einschließt. Hierbei ist die grundsätzliche Möglichkeit für das Arbeiten mit secure-boot zu verstehen (davor war und ist wegen fehlender, signierter Kernel kein secure-boot möglich gewesen).

Den Hinweis in den EFI Grundlagen habe ich mal (auf einheitliche Aussage) umgestellt.

Erst ab Trusty Tahr (14.04 LTS) kann man Ubuntu sowie alle Derivate auch im secure-boot-Modus starten

Hier liegt die Betonung auf alle, davor waren noch nicht alle ISO's der verschiedenen Derivate mit der Eigenschaft versehen, dass sie auch mit aktivierten secure-boot starten konnten.

Es ist eben eine crux mit diesem WIKI, dass bisher erwartet wird, dass jeder halbjährige Zwischenschritt auch dokumentiert sein sollte.

Vlt. ist dieses mal wieder ein Anlass, eine Diskussion zu starten, das WIKI nur auf LTS-Versionen abzustellen.

Hallo,

syscon-hh schrieb:

Vlt. ist dieses mal wieder ein Anlass, eine Diskussion zu starten, das WIKI nur auf LTS-Versionen abzustellen.

Kurzinfo dazu: wir sprechen da intern öfters drüber und das Thema steht akuell _nicht_ zu Diskussion.

Falls da jemand nichts desto trotz Diskussionsbedarf sieht → bitte einen eigenen Thread starten.

Gruß, noisefloor