Sony VAIO mit Insyde H2O EFI-BIOS bootet nicht in GRUB EFI

Ich habe einen neuen Laptop der Sony Vaio S-Serie gekauft. Es verwendet Insyde H2O BIOS EFI und der Versuch, Linux darauf zu installieren, macht mich verrückt.

root@kubuntu:~# parted /dev/sda print
Model: ATA Hitachi HTS72756 (scsi)
Disk /dev/sda: 640GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End    Size    File system  Name                          Flags
 1      1049kB  274MB  273MB  fat32        EFI system partition          hidden
 2      274MB  20.8GB  20.6GB  ntfs        Basic data partition          hidden, diag
 3      20.8GB  21.1GB  273MB  fat32        EFI system partition          boot
 4      21.1GB  21.3GB  134MB                Microsoft reserved partition  msftres
 5      21.3GB  342GB  320GB  ntfs        Basic data partition
 6      342GB  358GB  16.1GB  ext4        Basic data partition
 7      358GB  374GB  16.1GB  ntfs        Basic data partition
 8      374GB  640GB  266GB  ntfs        Basic data partition

Überraschend ist, dass sich auf der Festplatte zwei EFI-Systempartitionen befinden. Die sda2-Partition ist eine 20-GB-Wiederherstellungspartition, die Windows mit einer grundlegenden Wiederherstellungsschnittstelle lädt. Dies erreichen Sie durch Drücken der "ASSIST" -Taste im Gegensatz zur normalen Einschalttaste. Ich gehe davon aus, dass die sda1 EFI-Systempartition (ESP) in diese Wiederherstellung geladen wird.

Das sda3-ESP verfügt über detailliertere Einträge für Microsoft Windows, das tatsächlich in Windows 7 integriert ist (wie von bcdedit.exe unter Windows bestätigt). Ubuntu ist auf SDA6 installiert, und während der Installation habe ich SDA3 als Boot-Partition ausgewählt. Das Installationsprogramm hat die Anwendung sda3 / EFI / ubuntu / grubx64.efi korrekt erstellt.

Das eigentliche Problem: Für mein Leben kann ich es nicht als Standard festlegen! Ich habe versucht, eine sda3 / startup.nsh mit dem Namen grubx64.efi zu erstellen, aber es hat nicht geholfen - beim Neustart bootet das System immer noch in Windows. Ich habe versucht, efibootmgr zu verwenden, und das zeigt, wie es funktioniert hat:

root@kubuntu:~# efibootmgr 
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
root@kubuntu:~# efibootmgr --create --gpt --disk /dev/sda --part 3 --write-signature --label "GRUB2" --loader "\\EFI\\ubuntu\\grubx64.efi" 
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2
root@kubuntu:~# efibootmgr
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2

Beim Neustart wurde der Computer jedoch, wie Sie vermutet haben, direkt wieder in Windows gestartet.

Die einzigen Dinge, an die ich denken kann, sind:

1. Die sda1-Partition wird irgendwie benutzt
2. Überschreiben Sie /EFI/Boot/bootx64.efi und /EFI/Microsoft/Boot/bootmgfw.efi mit grubx64.efi [aber das scheint wirklich radikal zu sein].

Kann mir bitte jemand helfen? Danke - jede Hilfe wird sehr geschätzt, da diese Ausgabe mich verrückt macht!

Ich konnte das schließlich lösen. Ich habe die Datei EFI / Microsoft / boot / bootmgfw.efi durch die Datei grub64.efi ersetzt. Ich habe die erstere in bootmgfw.efi.old umbenannt und grub verwendet, um eine Menüoption zum Chainload hinzuzufügen.

Dies impliziert, dass die Firmware für die Suche nach dem Microsoft Windows-Bootloader fest codiert ist und die Einstellungen von efibootmgr oder startup.nsh nicht berücksichtigt. Das ist wirklich schrecklich.

Ich habe herausgefunden, wie der Sony EFI-Startvorgang funktioniert:

1. Suchen Sie in /EFI/Microsoft/Boot/fwbootmgr.efi; Wenn vorhanden, booten Sie es.
2. Suchen Sie in allen Unterverzeichnissen von / EFI / nach grubx64.efi. Wenn vorhanden, booten Sie es.
3. Booten Sie /EFI/Boot/bootx64.efi
4. Zeigt eine Fehlermeldung an, z. B. "Betriebssystem nicht gefunden".

Unter Linux funktioniert das Tool efibootmgr zwar, es zeigt jedoch eine Menge automatisch generierten Unsinn an, einschließlich des letzten von Ihnen verwendeten USB-Laufwerks.

So habe ich das alles gelernt:

1. Ich habe meinen neuen Computer geöffnet und die Windows-Partition reduziert, um Linux und Mac nebeneinander zu installieren.
2. Ich habe Ubuntu 12.10 installiert und das Installationsprogramm hat fwbootmgr.efi überschrieben und den alten Windows-Bootloader gesichert.
3. Ich habe den alten Windows-Bootloader wiederhergestellt, konnte aber nichts außer Windows booten.
4. Ich habe den Windows-Bootloader in etwas Falsches umbenannt, und dann hat der Grub BL übernommen.
5. Ich habe das Ubuntu-Verzeichnis in etwas anderes umbenannt und Grub immer noch geladen, obwohl ich rEFInd installiert hatte.

6. Der einzige Weg, wie ich REFInd dazu bringen konnte, das zu tun, was ich wollte, war der folgende:

7. Verschieben Sie die Datei fwbootmgr.efi in das übergeordnete Verzeichnis. rEFInd findet es weiterhin und Windows beschwert sich nicht, dass Sie es umbenannt haben.

8. Benennen Sie grubx64.efi in rfgrubx64.efi oder etwas anderes Erkennbares um.
9. Kopieren Sie rEFInd von / EFI / refind nach / EFI / boot, benennen Sie /EFI/refind_x64.efi in * .bak um und benennen Sie zuletzt /Boot/refind_x64.efi in bootx64.efi um. Sie sollten jetzt in der Lage sein, Windows BL oder GRUB von rEFInd zu booten. Ich plane, meine MacOS-Installation auf Clover zu aktualisieren und Clover auch von rEFInd zu laden.

(Vielleicht ist es möglich, den Windows-Start-Manager zu verwenden, aber die EFI-Unterstützung von EeasyBCD ist nach meiner Erfahrung immer noch ein Chaos. Ich weigere mich, es eine Weile lang erneut zu berühren.)

Erstens haben Sie keine zwei ESPs. Ein ESP ist eine Partition mit dem Partitionstypcode C12A7328-F81F-11D2-BA4B-00A0C93EC93B, die als Partition mit gesetztem "Boot-Flag" gekennzeichnet ist. Ihre Ausgabe zeigt an, dass nur in / dev / sda3 das "Boot-Flag" gesetzt ist, sodass Sie nur ein ESP haben - / dev / sda3. Unter GPT können Partitionen Namen haben, und Sie haben zwei Partitionen mit dem Namen "EFI-Systempartition". Diese Namen werden jedoch nur zur Identifizierung durch den Benutzer verwendet. Ich vermute daher, dass Sie (oder ein anderes automatisches Dienstprogramm) ein / dev / sda1 mit der Absicht erstellt haben, es zu einem ESP zu machen. Es ist jedoch entweder ein Fehler beim Festlegen des Partitionstypcodes aufgetreten oder ein anderes Dienstprogramm hat den Typcode von falsch geändert C12A7328-F81F-11D2-BA4B-00A0C93EC93B an etwas anderes.

Es gibt verschiedene Möglichkeiten, dies zu korrigieren. Am einfachsten ist es, einfach den Namen / dev / sda1 zu ändern, um Verwirrung zu vermeiden. Wenn Sie der Meinung sind, dass / dev / sda1 keinen Zweck erfüllt, können Sie es sichern und löschen. Dadurch wird das Problem behoben und Verwirrung vermieden, aber Sie haben dann natürlich 273 MB freien Speicherplatz. Alternativ können Sie das Leerzeichen einem anderen Zweck widmen, indem Sie gegebenenfalls den Namen und den Typcode ändern, um Verwechslungen zu vermeiden. EFI lässt explizit mehrere ESPs zu, sodass Sie den Typcode ändern (indem Sie das "Boot-Flag" beispielsweise mit parted setzen) und beide ESPs verwenden können. aber das könnte verwirrend sein.

Wahrscheinlich hat dieses Problem nichts mit Ihrer Unfähigkeit zu tun, Linux zu booten, da es so aussieht, als wären alle relevanten Dateien auf / dev / sda3. Für dieses Problem treten mehrere mögliche Gründe auf:

• Möglicherweise haben Sie in Ihrem Befehl efibootmgr etwas falsch eingegeben. Ich sehe keine offensichtlichen Tippfehler, aber wenn sich die GRUB-Binärdatei nicht an der von Ihnen angegebenen Stelle befindet, funktioniert der Befehl nicht. Die Optionen "--gpt" und "--write-signature" sind mit ziemlicher Sicherheit nicht erforderlich und können möglicherweise Probleme verursachen, sind es aber höchstwahrscheinlich nicht.
• Ihre Firmware könnte einen Fehler aufweisen, der dazu führt, dass der Befehl efibootmgr nur vorübergehend ausgeführt wird. Versuchen Sie einen Neustart und geben Sie dann "sudo efibootmgr -v" ein, um festzustellen, ob der von Ihnen erstellte Eintrag einen Neustart überstanden hat.
• Ihre Firmware könnte einen Fehler aufweisen, der dazu führt, dass die Variable für die Startreihenfolge ignoriert wird. Ich habe so ein Motherboard; Es wird in der Reihenfolge gestartet, in der die Starteinträge erstellt wurden, und nicht in der Reihenfolge, in der sie durch die Variable BootOrder angegeben wurden. Um diesen Fehler zu umgehen, müssten Sie alle Einträge löschen und sie in der gewünschten Startreihenfolge neu erstellen.
• Ihre grubx64.efi-Binärdatei kann so beschädigt werden, dass die Firmware den Start verweigert und zum nächsten Element in der Startreihenfolge übergeht.

Sie können versuchen, Ihren Befehl efibootmgr anzupassen, eine neue Binärdatei zu suchen oder diese Möglichkeiten zu testen. Wenn alles andere fehlschlägt, empfehle ich Ihnen Folgendes:

1. Löschen Sie alle Starteinträge mit efibootmgr oder Ihrer Firmware (sofern eine Schnittstelle dafür vorhanden ist).
2. Kopieren Sie grubx64.efi auf dem ESP nach EFI / Boot / bootx64.efi.
3. Wenn Sie beim Neustart immer noch Windows erhalten, benennen Sie EFI / Microsoft / Boot / bootmgfw.efi in EFI / Microsoft / bootmgfw.efi um.

Damit sollte GRUB mit dem Standardnamen für den Bootloader (EFI / Boot / bootx64.efi) gestartet werden. Ein Problem dabei ist, dass GRUB möglicherweise keinen funktionierenden Eintrag für Windows hat. Sie können wahrscheinlich eine manuell erstellen; Ein Eintrag wie dieser sollte funktionieren:

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/bootmgfw.efi
}

Alternativ können Sie rEFIt oder rEFInd als EFI / Boot / bootx64.efi installieren. Beachten Sie, dass die auf der Site verfügbaren rEFIt-Binärdateien auf UEFI-basierten PCs nicht funktionieren. Sie müssen die Version in den Ubuntu-Repositories verwenden. rEFInd ist ein Fork von rEFIt mit zahlreichen Bugfixes und Updates, einschließlich einer besseren UEFI-Unterstützung. (rEFIt scheint vor ungefähr zwei Jahren aufgegeben worden zu sein.) Daher empfehle ich die Verwendung von rEFInd anstelle von rEFIt - aber ich bin der Betreuer von rEFInd, daher bin ich in dieser Hinsicht kein unabhängiger Beobachter. Leider ist AFAIK rEFInd (noch) nicht in den Ubuntu-Repositories enthalten, sodass Sie es manuell herunterladen und installieren müssen.

Gleiche Ausgangsposition hier auf einer neuen Sony Vaio E-Serie. Danke Rod für deine Antwort.

Nur für den Fall, dass jemand eine Komplettlösung benötigt, hat dies für mich funktioniert:

Installierte Ubuntu 12.04 von USB neben Win7.

mount / dev / sda3 aus der Live-Session

• kopiere EFI / ubuntu / grubx64.efi nach EFI / Boot /
• Benennen Sie EFI / Boot / bootx64.efi in bootx64.efi.old um
• Benennen Sie EFI / Boot / grubx64.efi in bootx64.efi um

jetzt bootete es direkt in grub2, aber ohne win7 eintrag

Nach dem Laden von Ubuntu habe ich bearbeitet

/etc/grub.d/40_custom

Hinzufügen

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

und danach

sudo update-grub

alles funktioniert gut

Ich schlage zwei verschiedene Alternativen vor:

1. Überschreiben Sie Windows nicht, sondern verwenden Sie es, um grub zu starten

2. Ändern Sie die BIOS-Einstellungen ( f2oder f3beim Start) in den Startoptionen von UEFI zu LEGACY. Anschließend wird normalerweise das zuletzt installierte System gestartet

1. Führen Sie Boot-Repair von einer liveCD / liveUSB aus
2. Klicken Sie auf die Recommended RepairSchaltfläche. (Dadurch werden automatisch die richtigen Parameter für grub-efi installiert, einschließlich der SecureBoot-Parameter, falls erforderlich, und die EFI-Dateien werden umbenannt, falls die UEFI-Firmware auf Windows-Dateien beschränkt ist.) Geben Sie die URL an, die bei Problemen angezeigt wird.