staging.inyokaproject.org

syscon-hh schrieb:

War klar - ist eben dort nicht vorhanden - warum auch immer. Kann jetzt aber auch an der Grub-Version liegen, dass müsste man jetzt mal durchtesten.

Ah, schon mal gut zu wissen, dass man wohl nicht zwangsläufig davon ausgehen kann, dass dieses Modul in das EFI-Image integriert wird - auch wenn das jetzt für mich unerklärlich ist.

Gruß, Martin

Noch ein Hinweis, dass das gezielte Nachladen von Modulen wichtig sein kann:

Ich hatte weiter oben berichtet, dass der Grubmenü-Befehl

• ls

bei einem BIOS gestarteten System die HD's nicht richtig ausweist, also z.B.:

(md0) (hdo) (hd0,3) (hd0,2) (hd0,1) (hd1) (hd2) (hd3) (hd3,3) (hs3,2) (hd3,1)

wobei (hd0) + (hd3) Teile des RAID (md0) sind - das ändert sich, sobald man mittels

• insmod part_gpt

das richtige Modul nachlädt, dann erhält man z.B. (auszugsweise)

((md0) (hdo) (hd0,3) (hd0,2) (hd0,1) (hd1) (hd1,gpt2) (hd2,gpt1) .. usw.

Dieses Vorgehen gilt m.E. nur für selbst gestrickte Skripte, die Skripte aus /etc/grub.d sollten die erforderliche Module selbstständig einbinden.

Mal noch eine "schöne" Verwirrung stiftende Erfahrung von meinem MSI-Board:

Ich habe hier zwei USB Sticks zum installieren von Windows oder Ubuntu:

• Verbatim mit Ubuntu Live 12.04.1 amd64 - erstellt mit dem Startmedienersteller unter Lucid

• Kingstion mit Windows Prof. 64bit - erstellt mit Windows_7_USB_DVD_Download_Tool unter Windows

Normalerweise habe ich damit im UEFI-Boot-Menü zur Auswahl - je nach angestecktem Stick (verkürzte Darstellung):

• UEFI: NTFS File System

• Kingston

oder

• UEFI: Verbatim

• Verbatim

Wenn ich nun mit dem Ubuntu-Live (Verbatim) Stick arbeite, den Rechner dann herunterfahre und den Windows Stick (Kingston) anstecke, dann habe ich im EFI-Boot-Menü die folgende Auswahl:

• UEFI: Verbatim 😲

• Kingston

Was würdet Ihr da jetzt erwarten?

Meine beiden Erwartungen waren:

1. Namen sind nur Schall und Rauch - wird halt trotzdem UEFI vom aktuell angestecktem Kingston Stick gebootet.

2. Der Kingston-Stick bootet nicht, da ja ein EFI-Eintrag an ein spezifisches Gerät gebunden ist, das ja hier nicht mehr angeschlossen ist. Es kommt zu einer Fehlermeldung oder man sieht wieder das EFI-Boot-Menü.

Tatsächlich ist es aber so, dass beide aufgeführten Einträge den Stick im BIOS-Modus starten. Ein Start im EFI-Modus ist so nicht möglich. 🙄

Würgaround 1:

Man löscht vor dem Herunterfahren im Live-System mit efibootmgr die Verbatim-Einträge, fährt das System herunter und wechselt auf den Kingston-Stick.

Würgaround 2:

System herunterfahren, ganz ohne Stick wieder einschalten Post-Device-Probe abwarten, EFI-Boot-Menü aufrufen, Rechner ausschalten. Kingston-Stick anstecken, Rechner wieder einschalten, EFI-Boot-Menü aufrufen.

Da braucht man sich echt nicht wundern, dass bei solchen Vorraussetzungen vermurkste Installation dabei herauskommen. 😎

Gruß, Martin

syscon-hh schrieb:

Ich habe dazu jetzt ausführliche Tests auf verschiedenen EFI-Boards durchgeführt. Dabei bing es um das Laden eines EFI-Eintrages aus einer EFI-Umgebung heraus und bin zu einer allgemein gültigen Form gekommen:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#!/bin/bash # EFI-Partition suchen und auswerten [ ! -f /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi ] && exit; EFI_MEDIUM=$( cat /etc/mtab | grep /boot/efi | cut -d ' ' -f 1 ); EFI_UUID=$( blkid -c /dev/null -o value -s UUID ${EFI_MEDIUM} | cut -d ' ' -f 2 ); echo "Menüeintrag für Windows eingefügt" >&2 cat <<EOF menuentry "Windows 7 Professional" { insmod fat insmod chain search --no-floppy --fs-uuid --set=root ${EFI_UUID} chainloader /EFI/Microsoft/Boot/bootmgfw.efi } EOF

Grundsätzlich gehen wir da den gleichen Weg.

1. Im Gegesatz zu Newubunti vertrete ich nicht den Minimalismus bei diesen Einträgen, aber das ist eben Ansichtssache.

   • Aus Dokumentationssicht bin ich für die Aufführung der benötigten Module (kann später mal hilfreich sein - grub.cfg)

   • Wenn ein Modul nicht mehr geladen werden muss, dann gehe ich davon aus, dass es auch nicht mehr geladen wird, sprich, dass GRUB das schon anständig regelt.

2. Deine Zeilen 3-5 erledige ich mit GRUB-Mitteln selbst (funktioniert auch mit files), d.h.

   1 2	EFI_MEDIUM=$(grub-probe -t device /boot/efi/EFI); EFI_UUID=$(grub-probe -t fs_uuid /boot/efi/EFI);

   Da es sich um ein Hilfsskript in /etc/grub.d handelt, läuft dieses ja, beim Aufbau, unter Root und ermittelt die Werte aus GRUBsicht beim Aufruf.

Saludos

syscon-hh schrieb:

Noch ein Hinweis, dass das gezielte Nachladen von Modulen wichtig sein kann: ...

Ja, das ist schon klar. Mir ging es ja jetzt aber nur um die Erfahrung, wie das bei Euren System aussieht. Ich hätte jetzt gesagt, dass das fat-Modul - auch wenn es an sich kein Problem ist es nachzuladen - zum Standard eines GRUB-EFI-Images gehört. Dass das scheinbar nicht so ist, ist natürlich kein Problem, verwundert mich aber trotzdem.

Zumal ja das Platzargument bei GRUB-EFI nicht zieht. Da fällt mir ein, dass ich ja mal testen wollte, was passiert, wenn man ein Image mit allen Modulen erstellt. Könnte eventuell etwas langsam anlaufen.

Gruß, Martin

Hallo Newubunti und RapaNui, ich habe da gerade einen Effekt bei mir - nur weiß ich im Moment nicht, woran das liegen könnte - erst einmal die Fakten:

Ich probiere jetzt gerade ein GIGABYTE-Mainboard mit

• Award Software BIOS

  • Version: V6 00PG F1

Installation via

• Ubuntu 12.04.1 64bit

  • gestartet von CD im EFI-Modus

Nun habe ich am Desktop aber die Installationsoption

• Etwas Anderes..

ausgewählt und als normales BIOS-System installiert. Und nun tritt trotz einer leeren (Test)-HD nach der Installation folgendes auf:

• Installation ist total in Ordnung

lässt sich fremd starten - via USB-Stick mit dem relevanten Menüeintrag aus der Installation.

• sudo grub-install /dev/sdc

(/dev/sdc ist die relevante HD) - es wird die normale Erfolgsmeldung angezeigt

• "Installation finished. No error reported"

Nur der MBR wird nicht wirklich geschrieben - das boot-info-script bescheinigt einen unbenutzten MBR. Auch nach einem Fremdstart (siehe oben) läßt sich das innerhalb des Systems auch nachträglich nicht bereinigen, immer der gleiche Effekt.

Das muss also im installierten System drin sein, dass eine fiktive EFI-Installation vorliegt - nur fragt sich, wohin das abgelegt wird, eine relevante EFI-Partition ist nicht vorhanden noch im Spiel. Eine Installation mit gleicher CD, aber im normalen Modus gestartet, läßt sich normal installieren und auch der MBR schreiben.

Das habe ich jetzt mehrfach ausprobiert und es läßt sich wechselseitig reproduzieren - kann das Verhalten mal einer nachvollziehen / austesten. Das würde ggf. einige der Foren-Beiträge erklären und müsste dann als im Ubiquity gemeldet werden.

gruß syscon-hh

Hallo syscon-hh,

das hier hast Du gelesen? Da geht es jetzt nicht so deutlich hervor, aber Du kannst - bwz. ich habe es noch nie erlebt bzw. hinbekommen - im EFI-Modus nicht im BIOS-Modus installieren. Auch nicht, wenn Du keine EFI-System-Partition anlegst. Durch das Nicht-Anlegen der EFI-System-Partition erreichst Du nur, dass GRUB-EFI nicht installiert werden kann.

Damit erreichst Du aber nicht, dass stattdessen ein GRUB-BIOS installiert wird.

Das ist für mich insoweit noch kein BUG, sondern einfach verständlich - und zwar aus dem Umstand heraus, dass sonst die zwei unterschiedlichen Modi verwässern würden.

Man kann also grundsätzlich sagen:

• Im EFI-Modus kann man nur eine EFI-Installation machen.

• Im BIOS-Modus nur eine BIOS-Installation.

Was ich an dem Installer-Verhalten aber auch fragwürdig finde, dass das ganze überhaupt nicht transparent ist. Der Installer sollte einem zumindest darauf hinweisen, wenn GRUB nicht installiert werden kann. Im Moment sagt er nur erfolgreich abgeschlossen und man kann nur aus dem Installer-Log lesen, dass dabei gar kein GRUB installiert wurde.

Das ist ja meine Rede von Anfang an, der Schlüssel zur erfolgreichen Installation liegt im Druchschauen der verschiedenen Modi der Ubuntu-CD und zu welchem Verhalten diese führen.

IMO wäre es gut, wenn sich EFI-Modus und BIOS-Modus des Installerst optisch deutlicher unterscheiden würden - immerhin sind die Startbildschirme beim Booten des Mediums unterschiedlich - sonst würde man da als Laie irre. Bei Windows sind die Modi erst mal gar nicht auseinander zu halten.

Ich war eigentlich der Meinung oder soll ich besser sagen der Hoffnung, dass man das soweit auch schon aus dem Artikel herauslesen kann. Ich muss aber jetzt zugeben, dass es unter dem Punkt "etwas anderes" gar nicht so deutlich hervorgeht, wie ich bisher gedacht habe.

Aber wie gesagt, das grundverhalten ist, dass Du im EFI-Modus mit dem Installer kein GRUB-PC installieren kannst. Es wird dagegen GRUB-EFI installiert, auch wenn Du gar keine EFI-System-Partition hast. Dass das dann nicht erfolgreich ist - also nur die GRUB-Installation - zeigt Dir der Installler nicht an. Letzteres könnte man als BUG ansehen.

Was Du in so einem Fall im nachhinein mach musst ist:

1. Live-CD

2. chroot

3. grub-efi purgen

4. grub-pc installieren

Diese Problematik habe ich so in den letzten Tagen auch teilweise schon im Rahmen des Supports hier so durchführen müssen. Richtig wäre für Dein Vorhaben gewesen, die Ubuntu-CD im BIOS-Modus zu starten - was Du ja auch schon gemacht hast. Weil Du wolltest ja nichts anderes, als eine BIOS-Installation. Dafür nutzt man dann auch den BIOS-Modus der CD. Finde ich eigentlich logisch und würde ich so nicht als BUG bezeichnen. Aber über die Transparenz des ganzen kann man natürlich streiten.

Da morgen mal wieder Deadline für den Artikel ist:

Vielleicht kannst Du jetzt meine Fragen vom Thread-Anfang noch besser nachvollziehen.

Das Problem bei GRUB-EFI - das zeigen übrigens auch meine Support-Tätigkeiten über die letzten 2 Wochen - liegt im Durchschauen des Umstandes, dass es zwei Modi der CD gibt und dass je nach Modi nur eine bestimmte Installation erfolgreich ist.

So, wo bringt man das aber nun unter? Im Prinzip gehört das nach Installation, dort kann es aber eben auch verwirren. Nicht jeder hat ein EFI-System und ich fürchte, dass die Leute ohne ein solches abgeschreckt werden, wenn man davon erzählt, dass man erst mal untersuchen muss, was man für ein System hat usw..

Setze ich aber einfach nur einen Link der Marke "bei EFI muss das hier beachtet werden", dann wird der ignoriert, weil im Zweifel die Leute gar nicht wissen, dass sie eine EFI-System haben.

Ich zermartere mir seit Tagen den Kopf über diese Problematik und komme bis dato zu keiner überzeugenden Lösung.

Gruß, Martin

EDIT:
Da sieht man übrigens mal, was so bei I-Net-Kommunikation auf der Strecke bleibt. Ich dachte nämlich, dass Dir das Phänomen, dass Du heute beschrieben hast schon lange bekannt wäre - aufgrund der Baustelle hier und aufgrund meiner Beiträge hier im Thread.

Newubunti schrieb:

Da sieht man übrigens mal, was so bei I-Net-Kommunikation auf der Strecke bleibt. Ich dachte nämlich, dass Dir das Phänomen, dass Du heute beschrieben hast schon lange bekannt wäre - aufgrund der Baustelle hier und aufgrund meiner Beiträge hier im Thread.

War mir nicht bekannt - den Artikel hatte ich in letzter Zeit nicht mehr gelesen. Aber aus eigenem Schaden wird man oftmals viel schlauer.

Und ich muss Dir zustimmen - es muss eine direkte Fehlermeldung erfolgen bzw. der Installer sollte gar nicht erst die Installation beginnen, wenn z.B. im EFI-Modus die EFI-Partition fehlt (nicht gesetzt wurde)!!

Nur was soll der Durchschnitts-User denn machen?? Lesen tut der in den seltensten Fällen.

Noch ein Hinweis (ggf. auch für den obigen Artikel verwendbar):

• bei Wubi

habe ich einen Warnhinweis bezüglich GPT eingebracht, dass diese Art der Ubuntu-Installation dort nicht zu betreiben ist. Auch mit Wubi gilt → man kann installieren - nur starten will es nicht. Hierbei steigt sogar schon Windows mit dem Hinweis

• Pfad /ubuntu/winboot/wubildr.mbr wurde nicht gefunden.

aus.

Dito hab' ich das zum Anlass genommen, auch bei der GRUB 2/Reparatur einen entsprechenden Warnhinweis einzubauen.

gruß syscon-hh

Wäre für mich aber jetzt noch interessant zu wissen, ob Du das hier in einem solchen Fall - also mit der fehlerhaften bzw. nicht vollständig erfolgten GRUB-EFI-Installation nachvollziehen kannst?:

Newubunti schrieb:

1. Live-CD

2. chroot

3. grub-efi purgen

4. grub-pc installieren

Gruß, Martin

Newubunti schrieb:

Wäre für mich aber jetzt noch interessant zu wissen, ob Du das hier in einem solchen Fall - also mit der fehlerhaften bzw. nicht vollständig erfolgten GRUB-EFI-Installation nachvollziehen kannst?:

Klingt logisch - nur, das System ist jetzt (fertig) in den produktiven Bereich gewandert, also zum Testen muss ich auf das nächste System / Board warten - tut mit leid.

Sicher scheint mir dabei, dass man dann mit dem Modus starten muss, wo man hin will

• wenn es EFI werden soll → "EFI-Modus"

• wenn es MBR werden soll → "BIOS-Modus"

syscon-hh schrieb:

Sicher scheint mir dabei, dass man dann mit dem Modus starten muss, wo man hin will

• wenn es EFI werden soll → "EFI-Modus"

• wenn es MBR werden soll → "BIOS-Modus"

Ja, das ist definitiv so.

Weil wir gerade beim Ubiquity-Bugs sind:

Habt Ihr schon mal einen Rechner gehabt, bei dem beim Start des Ubuntu Installations-Mediums im EFI-Modus ein vorinstalliertes EFI-Windows vom Ubuntu-Setup erkannt wurde?

Ich hatte das noch auf keinem System bisher. Windows wird schlicht nicht erkannt. Die Woche habe ich aber in einem Thread support gegeben - finden den Thread gerade nicht - da hatte jemand behauptet, dass es auf einem ASUS-Board kein Problem mit der Erkennung von Windows durch das Ubuntu-Setup gegeben habe. Allerdings hatte der betreffende das ASUS-Board mittlerweile duch ein Gigabyte-Board ersetzt.

Gruß, Martin

Newubunti schrieb:

Weil wir gerade beim Ubiquity-Bugs sind:

Habt Ihr schon mal einen Rechner gehabt, bei dem beim Start des Ubuntu Installations-Mediums im EFI-Modus ein vorinstalliertes EFI-Windows vom Ubuntu-Setup erkannt wurde?

Nein - ist mir bisher nicht untergekommen - auf unser ASUS-Board warten wir noch!!

Hier mal meine bisherigen Erfahrungen tabellarisch aufbereitet (lfd. 3A bzw. 3B variieren leicht)

gruß syscon-hh

Für was steht "–-" bei 4C bzw. 4D? "Nicht möglich", "nicht sinnvoll", "nicht erfolgreich" oder für was auch sonst immer?

Gruß, Martin

Ein bisschen unglücklich:

• bei 4C sollte auch unter "Im EFI-Modus" stehen

  • "für alle Festplatten"

• Bei 4D unter "Im BIOS-Modus"

  • "–-" = nicht vorhanden

Im Übrigen hat sich bei Quantal die Optionen bei 3A schon wieder erweitert (heutiges Update). Nur komme ich an die Tabelle nicht mehr ran - ist ja auch nur ein erster grober Einstieg.

syscon-hh schrieb:

Nur komme ich an die Tabelle nicht mehr ran - ist ja auch nur ein erster grober Einstieg.

Ich habe Dir die Tabelle gerade mal in den Artikel gestellt.

Ansonsten kann ich unter 4D - wenn ich die Tabelle richtig verstehe - aber eine BIOS-Boot-Partition anlegen. Die braucht man ja gerade für die BIOS-Installation auf einem GPT-Datenträger.

Gruß, Martin