Ich habe ein Problem auf einem Server mit 4 x 1 TB-Laufwerken, auf denen Debian wheezy und GRUB 1.99-27 + deb7u3 ausgeführt werden.

sda und sdb haben Partitionen, die mit (Linux-Software) RAID1 gespiegelt wurden, einschließlich /boot. sdc und sdd haben jeweils eine einzelne Partition, die ein physisches LVM-Volume für Daten spiegelt. GRUB ist auf sda und sdb installiert. Früher habe ich mdadmzu --failund --removeder 1 TB - SDC und ersetzt das alte Laufwerk (a ST91000640NS) mit einem neuen 2 TB ST2000NX0243.

Mit dem neuen Laufwerk kommt GRUB so weit wie möglich

GRUB loading.
Welcome to GRUB!

Das Menü wird jedoch nicht angezeigt. Die Laufwerksanzeige auf SDC leuchtet kontinuierlich, sodass der GRUB-Kern vermutlich versucht, dieses Laufwerk zu lesen, obwohl es nicht für den Zugriff auf / boot / grub benötigt wird. Ich habe zwei Laufwerke desselben Modells ausprobiert smartctl, mit denen beide problemlos getestet werden können , mit demselben Ergebnis. Wenn der SDC-Laufwerksschacht leer ist, wird alles normal gestartet. Das System startet von Live-USB und das neue Laufwerk ist zugänglich, sodass es sich nicht um eine Hardware-Inkompatibilität handelt (*). Ich bin sicher, dass SDC entfernt wurde, und es gibt keinen Hinweis darauf, dass das BIOS die Laufwerke neu angeordnet hat.

(*) Dies war möglicherweise keine sichere Annahme. Siehe Antworten.

Ich habe also folgende verwandte Fragen:

1. Könnte die geänderte Größe des logischen Sektors (4096 statt 512 Byte) ein Problem verursachen, möglicherweise in der im GRUB-Kern integrierten RAID-Unterstützung? Warum bekomme ich nicht wenigstens eine grub rescue>Aufforderung? Könnte ein 4K-Problem auch die Verwendung des Laufwerks für Linux-RAID verhindern?
2. Was ist der schnellste Weg, um dies zu lösen? [Frühere Vorschläge enthalten: Muss ich GRUB mit dem neuen Laufwerk neu installieren und in diesem Fall wie? Hätte ein GRUB Rescue USB (hergestellt aus demselben System) das gleiche Problem? Ist es ein bekannter Fehler in GRUB und sollte ich ein Upgrade durchführen? Die Antworten auf diese Fragen scheinen zu sein: Nein, Ja und Nein.] Kann ich das von Debian verwendete GRUB-Image-Präfix dauerhaft konfigurieren?
3. Wie würde man diese Phase von GRUB debuggen? Es mag empfindlich sein, welche Module eingebaut sind, aber wie finden Sie das heraus?

Ich denke an eine debug.cfg mit just debug=allund so etwas wie:

grub-mkimage -c debug.cfg -o dcore.img configfile normal raid fs multiboot
grub-setup -c dcore.img /dev/sda

Funktioniert das? (Ich spreche diesen Punkt 3 in meiner eigenen Antwort an, aber das Hängenbleiben in meinem Fall scheint zu geschehen, bevor auf die eingebettete Konfiguration reagiert wird.)

Weitere Systemdetails

Falls dies zur Visualisierung beiträgt, ist hier ein Teil der lsblkAusgabe:

NAME                             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb                                8:16   0 931.5G  0 disk  
├─sdb1                             8:17   0   957M  0 part  
│ └─md0                            9:0    0 956.9M  0 raid1 /boot
├─sdb2                             8:18   0   9.3G  0 part  
│ └─md1                            9:1    0   9.3G  0 raid1 /
├─sdb3                             8:19   0 279.4G  0 part  
│ └─md2                            9:2    0 279.4G  0 raid1 /var
└─sdb4                             8:20   0 641.9G  0 part  
  └─md3                            9:3    0 641.9G  0 raid1 
    ├─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
    └─vg0-swap (dm-2)            253:2    0    32G  0 lvm   [SWAP]
sdc                                8:32   0 931.5G  0 disk  
└─sdc1                             8:33   0 931.5G  0 part  
  └─md4                            9:4    0 931.5G  0 raid1 
    └─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
sdd                                8:48   0 931.5G  0 disk  
└─sdd1                             8:49   0 931.5G  0 part  
  └─md4                            9:4    0 931.5G  0 raid1 
    └─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
sda                                8:0    0 931.5G  0 disk  
├─sda1                             8:1    0   957M  0 part  
│ └─md0                            9:0    0 956.9M  0 raid1 /boot
├─sda2                             8:2    0   9.3G  0 part  
│ └─md1                            9:1    0   9.3G  0 raid1 /
├─sda3                             8:3    0 279.4G  0 part  
│ └─md2                            9:2    0 279.4G  0 raid1 /var
└─sda4                             8:4    0 641.9G  0 part  
  └─md3                            9:3    0 641.9G  0 raid1 
    ├─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
    └─vg0-swap (dm-2)            253:2    0    32G  0 lvm   [SWAP]

Dies ist ein BIOS vor 2010 und verfügt über keine EFI-Funktionen.

Irrelevant: Auf dem laufenden System gibt das Folgende den gleichen LVM-Fehler von Grub-Probe 1.99 wie bei der Grub-Installation, obwohl alles zu funktionieren scheint (dies scheint in GRUB 2.02 behoben zu sein).

# grub-fstest /dev/sda cp '(loop0,msdos1)/grub/grub.cfg' grub.cfg
error: unknown LVM metadata header.

Die Debug-Methoden in der folgenden Antwort zeigen, dass das Präfix des zu sd [ab] installierten Images wie folgt lautet:

grub-mkimage -d /usr/lib/grub/i386-pc -O i386-pc --output=/boot/grub/core.img '--prefix=(mduuid/<UUID of sdN1>)/grub' biosdisk ext2 part_msdos part_msdos raid mdraid09

Ich weiß nicht, warum 'part_msdos' wiederholt wird. Es gibt keine GPT-Tabellen. md0 (boot) verwendet RAID-Superblock Version 0.9, ebenso wie md1, md2 und md4 (dies sind alte Arrays). md3 ist super 1.2, sollte aber nicht am booten beteiligt sein.

Aktualisieren

Vielen Dank für die bisherigen Vorschläge. Nach weiteren Tests:

• Das BIOS war bereits so eingestellt, dass es mit sda (ata1.00) bootet. Nachdem GRUB auf allen Laufwerken mit neu installiert wurde dpkg-reconfigure grub-pc, hat sich nichts geändert und GRUB bleibt vor dem Menü hängen, wenn das neue Laufwerk über SATA verbunden wird. Dies konnte nicht durch / boot / grub-Inhalte erklärt werden, die ohnehin nicht mit dem Kern-Image übereinstimmen. Ebenso macht das physische Neuanordnen von Laufwerken keinen Unterschied.
• Ein Upgrade auf GRUB auf 2.02 in Debian Jessie hat nur zur Folge, dass die Welcome to GRUB!Nachrichten nicht gedruckt werden - stattdessen wird der Grafikmodus geändert. Es hängt immer noch unter den gleichen Bedingungen.
• Der Hang scheint aufzutreten, bevor die eingebettete Konfiguration die debugVariable festlegt . Es werden keine nützlichen Debug-Informationen ausgegeben.
• GRUB zeigt beim Booten von einem Wechselmedium ein Menü an, in dem das Präfix keine UUIDs verwendet. Auf diese Weise kann das System mit dem physisch vorhandenen Laufwerk gestartet werden. Die TAB-Aufzählung der Laufwerke friert jedoch ein. Wie erwartet hängt das Kettenladen von GRUB von einer Festplatte wie zuvor. Das Booten von einem USB-Laufwerk, das von grub-mkrescuedemselben System erstellt wurde, hängt ebenfalls.
• Als separater Fehler führt der Versuch, auf dem Live-System (Linux 3.2.0-4-amd64) das neue 4Kn-Laufwerk entweder über internes SATA oder USB zum RAID1-Array hinzuzufügen, Bad block number requestedauf dem Gerät zum Ausfall des md-Systems das Laufwerk BUG: unable to handle kernel paging requestund ein Kernel oops. ( mdadm --removesagt, das ausgefallene Element ist ausgelastet und der md-resync-Prozess reagiert nicht auf SIGKILL. Ich habe es nicht versucht echo frozen > /sys/block/mdX/md/sync_action. Beim Testen des Laufwerks ddüber SATA scheint alles in Ordnung zu sein.) Sicherlich können die Linux MD-Treiber ein 4Kn-Laufwerk mit älteren Laufwerken synchronisieren und verwenden das BIOS nicht?

Problemumgehungen können daher das Mounten einer Nicht-RAID-Partition als umfassen /boot/. Installieren von GRUB mit einem geräteabhängigen Präfix; oder das BIOS flashen. Am sinnvollsten ist es wahrscheinlich, den Lieferanten zu kontaktieren, um die Laufwerke auszutauschen.

Mit anderen Worten, Frage 3 hat eine Lösung, deren Ineffektivität möglicherweise Gegenstand einer GRUB-Funktionsanforderung ist. Frage 2 hat den falschen Baum angebellt, also habe ich ihn überarbeitet. und Frage 1, wenn es nicht zu weit vom Thema entfernt ist, befasst sich jetzt zusätzlich damit, warum das Laufwerk anscheinend nicht für Linux-RAID verwendet werden kann.

Ich würde das Kopfgeld gerne für eine anständige Erklärung all dessen vergeben, etwas über den RAID-Resync-Fehler oder Anekdoten über die Verwendung flashromfür 4Kn-Unterstützung, wie man grub-install anweist, keine UUIDs oder relevante Sysadmin-Tipps zu verwenden.

Ich werde den dritten Teil meiner Frage zu einem Verfahren zur Installation von GRUB mit aktiviertem Debugging beantworten. Ich würde mich immer noch über informierte Vorschläge darüber freuen, wo das Problem liegen könnte, oder über Strategien, die mit minimalen Ausfallzeiten und maximalen Informationen zur Ursache gelöst werden können.

Einige allgemeine Punkte: GRUB bietet andere Methoden zum Debuggen - grub-mkrescueerzeugt eine ISO-Datei, die alle Module enthält, die Sie möglicherweise benötigen. So kann beispielsweise ein Live-USB verwendet werden, um in einem RAID-Array zu navigieren und die .cfg zu laden Datei oder sogar den Kernel. Der grub-emuEmulator ist in den meisten Distributionen verfügbar, orientiert sich jedoch eher an der Darstellung des Menüs. Weiterentwickelt ist das Standard-GRUB-Modul zum Debuggen gdbüber ein serielles Kabel .

Verfahren zum Installieren von GRUB mit aktiviertem Debugging

Das Verfahren zum Abrufen von Debug-Meldungen wird im Abschnitt 6 des GRUB-Handbuchs beschrieben , jedoch nicht im Detail. Das erste, was Sie in Betracht ziehen sollten, ist das Debuggen über eine serielle Konsole und das Ausführen scriptvor screendem Aufzeichnen der Debug-Meldungen. Offensichtlich benötigen Sie Root-Rechte. Beachten Sie, dass das Laufwerkslayout in dieser Antwort nicht unbedingt mit der Frage übereinstimmt und nur ein Beispiel ist. Angenommen, normales (nicht debuggendes) GRUB wird entsprechend auf anderen Laufwerken installiert: Dies ist nur das Verfahren zum Installieren eines Debug-GRUB auf dem Laufwerk, das Sie voraussichtlich starten werden. (Das bedeutet, dass Debug-Meldungen deutlich machen, welches Laufwerk gestartet wird. Bei der Installation auf einer RAID-Partition ist das Präfix in beiden Fällen wahrscheinlich dasselbe, sodass Sie nur den gleichen Befehl für /dev/sdaas ausführen können /dev/sdb.)

Überprüfen Sie zunächst, wo sich die vorhandenen Grub-Dateien befinden /boot/gruboder wahrscheinlicher /boot/grub/<platform>. In diesem Fall nehmen Sie an, dass sie in sind /boot/grub/i386-pc/. Wir werden die bereits vorhandenen Dateien nicht ändern, sondern ein zusätzliches Core-Image mit aktiviertem Debug hinzufügen. Wenn die .cfgDateien fehlen oder geändert wurden, generieren Sie sie standardmäßig mit neu grub-mkconfig -o /boot/grub/grub.cfg.

Überprüfen der installierten Module und des Präfixes

Der schnelle und schmutzige Weg, um zu zeigen, welche Module bereits in Ihrem Kernimage kompiliert sind, besteht darin, sie grub-installerneut auszuführen . Dies funktioniert in GRUB 2.02:

grub-install -v /dev/sda 2>&1 | grep '\(mkimage\|setup\)'

In einem einfachen Fall ohne RAID oder lvm kann dies eine Liste wie anzeigen ext2 part_gpt biosdisk. GRUB 1.99 wird jedoch nicht -vfür ausführlich verwendet --debug. Verwenden Sie stattdessen. Wir werden dies mit dem Trick kombinieren, das Image nicht tatsächlich zu installieren, um ein wenig Zeit zu sparen:

grub-install --debug --grub-setup=/bin/true /dev/sda 2>&1 | grep '\(-mkimage\|-setup\|true\)'

Beachten Sie, dass grub-installShell-Skripte anstelle der aufgerufenen Programme ausgeführt werden können. Stattdessen hätten wir Folgendes tun können:

# create grub-mkimage wrapper
cat > /usr/local/bin/grub-mkimage.sh <<"EOF"
echo Arguments to grub-mkimage: $*
/usr/bin/grub-mkimage $*
EOF
# create a dummy grub-setup
cat > /usr/local/bin/grub-setup.sh <<"EOF"
#!/bin/bash
echo Arguments are: $*
EOF
# run grub-install using the above
chmod u+x /usr/local/bin/grub-*.sh
grub-install --grub-mkimage=/usr/local/bin/grub-mkimage.sh \
  --grub-setup=/usr/local/bin/grub-setup.sh /dev/sda 2>&1 \
  | grep 'Arguments' | tee grub-args.txt

Die Pfade können natürlich je nach Verteilung und gewählter Shell variieren.

Festlegen der Debug-Variablen

Wir erstellen jetzt eine Datei, die wir debug.cfgmit den Debug-Einstellungen aufrufen können. (Der Kern generiert einen nicht schwerwiegenden Fehler, wenn er zu diesem Zeitpunkt auf einen Kommentar stößt, sodass wir keinen verwenden.)

set pager=1
set debug='init modules disk ata,scsi,linuxefi,efi,badram,drivemap linux,fs,elf,dl,chain serial,usb,usb_keyboard,video'
set

Jede Kombination von Leerzeichen, ,, ;oder |kann verwendet werden , um die Modulnamen zu trennen innerhalb der Zeichenfolge.

Ich habe die Liste der Debug-Funktionen aus der GRUB 2.02-Quelle extrahiert und sie semantisch bestellt. 'all'erzeugt zu viele Speicherinformationen vom scriptingInterpreter. Es gibt zusätzliche Funktionen für bestimmte Dateisysteme wie 'xfs' und 'reiserfs' sowie 'net', 'partition' und 'loader' ('loader' ist zu spät für das, was uns vor dem Menü interessiert. Wenn wir kann ein Menü bekommen, wir können dort die Debug-Variable setzen.) Es gibt leider keine Debug-Meldungen in der 'mdraid_linux'-Quelle, diskzeigt aber die wichtigsten Operationen.

Die pagerVariable wird zum Lesen der Debug-Meldungen benötigt, wenn Sie sie nicht über eine Konsole erfassen (z. B. mit script). Ich habe festgestellt, dass pagerdies nicht funktioniert, ohne ein zusätzliches Modul wie sleepoder einzuschließen configfile, das die Größe des Bildes mehr als verdoppelt. Die Debug-Umgebungsvariable wird unabhängig davon wirksam.

Installieren

Erstellen Sie nun ein variantes Image desjenigen, das Sie debuggen möchten:

grub-mkimage -p '(,msdos3)/boot/grub' -c debug.cfg \
   -O i386-pc -o dcore.img -C auto ext2 part_msdos biosdisk

Die Liste der Module ist die von grub-install, die Sie debuggen möchten, und enthält sleepoder alles andere, was Sie benötigen. Das Präfix -psollte auch aus der Ausgabe von kopiert werden grub-install, da es offensichtlich einen großen Einfluss darauf hat, was nach dem GRUB-Banner passiert. Möglicherweise möchten Sie jedoch mit der Verwendung eines GRUB-Gerätecodes (wie in diesem Fall) anstelle der Standard-UUID experimentieren. Sie können UUIDs mit lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE,STATE,UUIDoder ls -l /dev/disk/by-id/auf RAID-Laufwerken mit anzeigen mdadm --detail /dev/sda.

Installieren Sie nun den soeben erstellten Core auf der normalerweise gebooteten Festplatte:

cp dcore.img /boot/grub/i386-pc
grub-bios-setup -d /boot/grub/i386-pc -c dcore.img /dev/sda

Bei Versionen von GRUB vor 2.0 kann der grub-bios-setupBefehl weiterhin grub-setupwie im Handbuch aufgerufen werden .

Starten Sie neu. Welcome to GRUB!Bevor das Menü angezeigt wird (oder auch nicht), sollten mehrere Seiten mit Debug-Meldungen angezeigt werden.

Ich beantworte jetzt meine eigene Frage 1. Ist dies ein 4Kn-Problem ('Advanced Format')?

Ja.

4Kn-Laufwerke werden nicht so häufig unterstützt, wie Sie vielleicht denken . Beispielsweise sind sie nicht mit Windows 7 oder GRUB 1 oder vielen Intel-Chipsätzen kompatibel. In meinem Fall scheint das Problem der Intel 82801I Enterprise Southbridge-Controller-Chip (ICH9-Familie) auf dem Motherboard zu sein. Ich denke, dies ist auch der Grund für einen teilweisen Ausfall des Laufwerks auf md_resync auch über USB. Die Analyse im obigen Link scheint zu ergeben, dass der Linux-Treiber ata_piix für 4Kn über Intel ICH10 trotz fehlender offizieller Unterstützung durch Intel einwandfrei funktioniert hat. Ich habe möglicherweise anders für ICH9 gefunden. Ich habe nicht getestet, ob das Laufwerk im AHCI- oder SAS-Modus funktioniert.

Nur der Motherboard-Hersteller oder eine andere Person, die einen gründlichen Test durchgeführt hat, kennt wahrscheinlich Informationen zur Laufwerkskompatibilität. Ich kam zu früh zu dem Schluss, dass "es keine Hardware-Inkompatibilität ist", nur weil einfache Lese- und Schreibvorgänge funktionierten. Es gibt einen Grund, warum das aktualisierte BIOS für dieses Motherboard 4Kn nicht unterstützt: weil das Motherboard dies nicht zuverlässig tut.

Es gibt keinen Grund, warum das entsprechende 512e-Laufwerk in diesen Situationen nicht funktionieren sollte.

Um Ihre zweite Frage zu beantworten, gibt es einen Fehler im Zusammenhang mit raid1 , der in 2.02 gepatcht wurde.

Ich hoffe, es wird helfen, auch wenn ich nicht sagen kann, ob dieser Fehler vor 2.02 ~ beta1 (Version, in der der Fehler gemeldet wurde) vorhanden war oder nicht.

Bearbeiten: Außerdem stellte sich direkt nach dem Posten eine Frage: Ist Ihr RAID1 ein Software- oder Hardware-RAID?