Grundlegende Details zum Arbeitssystem:
Ich habe die Ubuntu 12.04-Server-CD verwendet, um einen Server zu installieren.
Ich habe 4 Festplatten. Auf allen Festplatten habe ich Folgendes ausgeführt, ähnlich wie in diesem Howto :
- hat eine 2 GB Swap-Partition erstellt
- hat eine 256 GB / Boot-Partition erstellt
- hat eine 64 GB RAID10-Partition erstellt (für root)
- hat eine große RAID10-Partition erstellt, die den Rest des Speicherplatzes einnimmt
Ich habe den Boot als ext3 formatiert. Ich habe RAID10 auf dem Root und großen Partitionen eingerichtet. Ich habe die Wurzel ext4 formatiert. Ich habe ein logisches Volume auf dem großen erstellt und es ext4 formatiert.
Das resultierende System funktioniert einwandfrei und bootet einwandfrei.
Problemdetails:
Dann habe ich beschlossen, ein Fehlerverfahren zu dokumentieren. Als ersten Schritt entschied ich mich, grub neu zu installieren.
# grub-install /dev/sda
warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!.
error: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
# grub-install /dev/sdb
warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible!.
error: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
Es sieht also so aus, als wäre es gescheitert, aber es scheint auch aufgegeben zu haben und keine Änderungen vorgenommen zu haben. Also habe ich neu gestartet. Der Start ist fehlgeschlagen. Es hängt nur mit einem schwarzen Bildschirm mit einem blinkenden Cursor etwa 4 Zeilen nach unten. Wenn ich mit gedrückter Umschalttaste starte, wird links vom Cursor das Wort "GRUB" angezeigt, jedoch keine interaktive Eingabeaufforderung.
Zu diesem Zeitpunkt habe ich Boot-Repair-Disk verwendet , um diesen Bericht zu erstellen: http://paste.ubuntu.com/966531/
Beachten Sie im obigen Bericht, dass der Bootloader nicht auf den richtigen Sektor für core.img verweist. (sda ist die virtuelle CD; sdb ist die Bootdiskette; sdc ist ein Spiegel von sdb, aber boot wird nicht gespiegelt, es ist nur eine separate, nicht verwandte Partition vorhanden und ext3 formatiert; sdd und sde haben Platz zum Booten, aber es ist nicht formatiert)
Dann habe ich von der Ubuntu-Server-CD gebootet, das Rettungssystem gestartet und die folgenden Befehle ausgegeben, die ohne Fehler ausgeführt wurden (wobei sda die virtuelle CD ist und b, c, d, e die Festplatten sind, die a, b, c waren , d in den vorherigen Grub-Befehlen):
# parted /dev/sdb set 2 bios_grub on
# parted /dev/sdc set 2 bios_grub on
# grub-install /dev/sdb
# grub-install /dev/sdc
Zu diesem Zeitpunkt habe ich Boot-Repair-Disk verwendet , um diesen Bericht zu erstellen: http://paste.ubuntu.com/966561/
Beachten Sie, dass im obigen Bericht das Problem mit core.img behoben ist. Es scheint auf den richtigen Sektor hinzuweisen.
Wenn ich jetzt versuche zu booten, erhalte ich eine Grub-Eingabeaufforderung. Wenn ich "set" ausführe, sehe ich, dass root gefunden und gesetzt wurde. Wenn ich "ls /" ausführe, wird mein Stammverzeichnis auf dem RAID-Volume angezeigt, einschließlich der vmlinuz-Kerneldatei. Wenn ich "ls / vmlinuz" eingebe, heißt es "Fehler: Datei nicht gefunden". Es wird der gleiche Fehler angezeigt, wenn ich den Befehl "linux" verwende, um zu versuchen, den Kernel zu laden. Die vmlinuz-Datei wird nicht aufgelistet, wenn ich "ls -l /" verwende.
Übermäßig ausführliche Details, falls Sie folgen möchten:
Mir ist aufgefallen, dass es auch kein /boot/grub/grub.cfg gibt, also bin ich gelaufen
# grub-mkconfig -o /boot/grub/grub.cfg
Das Problem bleibt jedoch bestehen.
Wenn ich das Tool "gptsync" verwende, ändert sich dieses Verhalten nicht.
Die Boot-Repair-Disk repariert das System nicht, da ich mit einem EFI-fähigen BIOS booten soll. Ich habe mich kurz damit befasst, aber ich weiß nicht, wie das funktioniert. Ich habe in meinen Startoptionen eine UEFI-Shell gefunden, weiß aber nichts darüber und sehe nicht, wie ich den Start von dort aus ändern kann (z. B. um die CD von dieser EFI-Shell zu starten).
Ich habe diese Seite auch gelesen , aber Ubuntu wird nicht mit dem Befehl "grub" geliefert, sodass ich ihm nicht genau folgen kann. Ich könnte diesen Befehl einfach installieren, bin aber neugieriger, wie das Ubuntu-Installationsprogramm es geschafft hat, ihn zu installieren, als ein anderes Setup zu haben. Hat es Blocklisten verwendet?
Hier ist die Ausgabe von parted, während auf der Boot-Repair-Disk gebootet (wobei hier die SDB die erste Festplatte ist, sda beim Booten von der Disk und "Boot" in "bios_grub" im 2. Einfügelink geändert wird):
Model: ATA Hitachi HUA72303 (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 2000MB 2000MB linux-swap(v1) swap1
2 2000MB 2256MB 256MB ext3 boot1 boot (this says bios_grub in 2nd link)
3 2256MB 66.3GB 64.0GB root1 raid
4 66.3GB 3001GB 2934GB data1 raid
Hier ist eine nicht verwandte super alte virtuelle Maschine zum Vergleich (für alle, die mit Boot-Repair-Disk nicht vertraut sind ): http://paste.ubuntu.com/966799/
Hier ist die neueste Einfügung aus dem Problemsystem, nachdem Sie die obige grub-mkconfig ausgeführt und "bios_grub" wieder auf "boot" gesetzt haben. http://paste.ubuntu.com/966808/
Im Vergleich der beiden sieht das interessant aus:
sdb2: __________________________________________________________________________
File system:
Boot sector type: Grub2's core.img
Boot sector info:
Mounting failed: mount: unknown filesystem type ''
md/bcserver8:0: ________________________________________________________________
File system: ext4
Boot sector type: -
Boot sector info:
Operating System: Ubuntu 12.04 LTS
Boot files: /boot/grub/grub.cfg /etc/fstab /boot/grub/core.img
Es sieht so aus, als ob der RAID die Boot-Dateien hat und die SDB2 nicht formatiert ist. (Trotzdem wurde das System vor dem Ausführen von grub-install gestartet). Auf der Rettungs-CD schlägt "mount -t ext3 / dev / sdb2 / boot" fehl. Es ist jedoch sinnvoll, dass dies die Dinge verwirren würde, da grub Partition 2 explizit verwendet (die 2 im parted-Befehl, die bios_grub aktiviert).
Also habe ich so etwas gemacht:
# mkfs.ext3 -L boot1 /dev/sdb2
# mv boot boot_on_root
# mkdir boot
# mount /dev/sdb2 boot
# rsync -avHP boot_on_root/ boot/
# parted /dev/sdb set 2 bios_grub on
# parted /dev/sdc set 2 bios_grub on
# grub-install /dev/sdb
# grub-install /dev/sdc
Dann neu gestartet, und ich habe wieder den schwarzen Bildschirm, keine Eingabeaufforderung. http://paste.ubuntu.com/966848/
An diesem Punkt gehe ich davon aus, dass grub beim Festlegen von bios_grub nicht auf dem MBR und nicht auf dem ext3-Dateisystem auf ext3 installiert wird, sondern auf der Partition selbst, als wäre es EFI ... was offensichtlich zu Problemen führen würde dort das ext3-Dateisystem hochfahren. Nach meiner kurzen Lektüre über EFI klang es so, als würde EFI annehmen, dass die erste Partition der Boot ist, aber in meinem Fall ist die erste Swap, und es sollte dann auch FAT sein und nicht etwas Unmontierbares ... also, da das wenig / nein macht Sinn, ich bin immer noch völlig ahnungslos verloren. [BEARBEITEN: Jetzt habe ich eine Ahnung ... überspringen Sie ein wenig für die Aktualisierung]
Und jetzt, wenn ich auf "Reparieren" in " Boot-Repair-Disk" klicke, wird etwas anderes gefragt. Das letzte Mal war der Fehler unter dem Fenster versteckt und ich musste den anderen wegziehen, um ihn zu sehen. Dieses Mal ist das Hauptfenster weg und das neue Fenster sagt:
GPT detected. You may want to retry after creating a
BIOS-Boot partition (>1Mo, flag). Do you want to continue?
Also habe ich auf Ja geklickt und festgestellt, dass es erfolgreich repariert wurde, und eine weitere Paste erstellt: http://paste.ubuntu.com/966862/
Aber ich habe immer noch einen schwarzen Bildschirm mit einem blinkenden Cursor.
Nun ist meine Theorie, dass der Boot von einem fettfreien Nicht-EFI-Ding überschrieben wurde, bei dem es sich nur um Grub-Code handelt, der sonst in den Sektoren 0-63 gewesen wäre. Zum Glück bin ich auf dieser Seite auf eine sehr klare Aussage gestoßen, die wahrscheinlich mein Verständnis darüber vervollständigte, was dies alles bedeutet. Und nachdem ich das gefunden hatte, veröffentlichte Jeremy eine Antwort, die bestätigt, dass dies das fehlende Schlüsselkonzept ist. http://blog.psych0tik.net/2011/08/grub-embedding-blocklists-and-bios_grub-partitions/
Fragen:
Was ist los? Warum sollte grub nicht booten? Warum heißt es "Datei nicht gefunden"?
Warum möchte grub nicht ohne diese Einstellung installieren, die ich mit parted festgelegt habe (die nicht vom Ubuntu-Installationsprogramm festgelegt wurde)? Ich dachte, alles was ich brauchte, um es zu installieren, war ein separater / Boot, der weder in LVM noch in Software-RAID ist, da mein Stamm in RAID ist und die Partitionstabelle GPT ist.
Wie installiert das Ubuntu CD-Installationsprogramm es ohne dieses Problem und ohne die Einstellung bios_grub?
Ich würde auch in Betracht ziehen, EFI zu verwenden. Wenn dies eine gute Idee ist und es eine Standardmethode zum Einrichten gibt, bin ich immer bereit, neue Dinge zu lernen.
Die schnellste Antwort, die mich glücklich machen würde, selbst ohne alle meine Fragen zu beantworten, wäre eine Reihe von Befehlen, die ich von der Rettungs-CD ausführen könnte, um den Bootloader auf die gleiche Weise zu reparieren, wie es die Installations-CD getan hat. Es wäre auch besonders schön, wenn ich sie mit dem gebooteten System anstelle der CD ausführen könnte.