Debian bootet nicht mehr (Grub2, Raid1)

[whatsmyname2009]

Hi Leute,

mein System bootet nicht mehr, das Grub-Menü fährt noch hoch, nach der Auswahl bleibt dann alles hängen und er läd das System nicht.

Lief vorher ohne Probleme, ich habe ein Software-Raid1 und habe größere Platten eingebaut, also die Installation von einer LiveCD auf ein USB-HD gebackupt und auf den neuen Platten wieder eingespielt, chroot gemacht und grub-install ohne Fehlermeldungen.

Mein grub.cfg (Grub2 - Debian testing):

Code: Alles auswählen

### BEGIN /etc/grub.d/00_header ###
set default=0
insmod raid
insmod mdraid
insmod ext2
set root=(md0)
search --no-floppy --fs-uuid --set f667115f-ec88-4ac2-ab1f-76ac92d47e00
if loadfont /usr/share/grub/unicode.pf2 ; then
  set gfxmode=640x480
  insmod gfxterm
  insmod vbe
  if terminal_output gfxterm ; then true ; else
    # For backward compatibility with versions of terminal.mod that don't
    # understand terminal_output
    terminal gfxterm
  fi
fi
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, Linux 2.6.30-1-amd64" {
        insmod raid
        insmod mdraid
        insmod ext2
        set root=(md0)
        search --no-floppy --fs-uuid --set f667115f-ec88-4ac2-ab1f-76ac92d47e00
        linux   /boot/vmlinuz-2.6.30-1-amd64 root=/dev/md0 ro  quiet
        initrd  /boot/initrd.img-2.6.30-1-amd64
}
menuentry "Debian GNU/Linux, Linux 2.6.30-1-amd64 (recovery mode)" {
        insmod raid
        insmod mdraid
        insmod ext2
        set root=(md0)
        search --no-floppy --fs-uuid --set f667115f-ec88-4ac2-ab1f-76ac92d47e00
        linux   /boot/vmlinuz-2.6.30-1-amd64 root=/dev/md0 ro single 
        initrd  /boot/initrd.img-2.6.30-1-amd64
}
### END /etc/grub.d/10_linux ###

Die neue Partition habe ich mit ext3 formatiert und als bootable getaggt. Wer weiß was?

Gruss,
DS

[whatsmyname2009]

Sieht so aus als würde Grub md0 gar nicht finden. Hab noch ein bisschen gegoogelt und irgendwo gefunden: "Man muss allerdings etwas aufpassen: Die Kernelheinis haben nun schon das xte Redesign des raid-superblocks rausgebracht. GRUB kann aber nur mit dem superblock 1.0 umgehen, ansonsten findet er das raid volume gar nicht". Sagt das jemanden was?

Gruss,
DS

[whatsmyname2009]

So hab noch ein bisschen weitergefummelt, sieht so aus als hätte das mdadm meiner LiveCD (Grml x64 05/2009) die Raid-Chains mit Superblock version 0.9 ausgestattet ("Version : 0.90.00"):

Code: Alles auswählen

mdadm -E /dev/sda1
/dev/sda1:
          Magic : a92b4efc
          Version : 0.90.00
           UUID : e4fe6f5f:ec1e5422:d8b78f65:99226e41
  Creation Time : Sun Oct  4 16:29:32 2009
     Raid Level : raid1
  Used Dev Size : 48829440 (46.57 GiB 50.00 GB)
     Array Size : 48829440 (46.57 GiB 50.00 GB)
   Raid Devices : 3
   Total Devices : 3
Preferred Minor : 0

    Update Time : Mon Oct  5 13:54:01 2009
          State : clean
   Active Devices : 3
Working Devices : 3
   Failed Devices : 0
   Spare Devices : 0
   Checksum : 849db4b2 - correct
         Events : 6

Das könnte das Problem sein, weiß jemand mehr? Kann das jemand bestätigen? Kann ich die Superblock-Version verändern oder muß ich den Raid-Chain nochmal anlegen irgendwie mit Superblock 1.0?

Gruss,
DS

[whatsmyname2009]

So ich habe noch mehr Informationen gesammelt (falls jemand dasselbe Problem hat/bekommt): zum Thema Superblock-Version habe ich jetzt schon wieder unterschiedliches gefunden, auch das Grub2 (1.97~beta3-1 - Debian testing) mit Superblock version 0.9 durchaus zurechtkommen müßte.

Eine andere Spur ist das einige behaupten, das Raid-Modul von Grub2 müßte mit ins core.img kompiliert werden sonst könnte es gar nicht laufen (siehe: http://grub.enbug.org/LVMandRAID). Auf der Seite von Grub-Wiki steht, dass man core.img mit grub-mkimage "per Hand" mit den anderen Modulen erstellen soll, auf anderen Seiten steht, dass das Image bei Anwendung von grub-install vor dem installieren aber wieder überschrieben wird und dass man die Module bei grub-install mitgeben soll (grub-install "(md0)" --modules="ext2 raid mdraid") - läuft beides nicht.

Dann habe ich einige Beiträge gefunden die von einen Bug sprechen. Ich habe es mal mit Grub2 1.96 vom Debian Server versucht, läuft aber auch nicht, bleibt auch hängen, es scheint aber irgendwo Patches zu geben von Leuten, die dasselbe Problem hatten.

Was mich allerdings stutzig macht ist das diesselbe Konfiguration auf den anderen Platten funktioniert hat, da hat alles ordentlich gebootet.

Fällt einem noch etwas ein?

Gruss,
DS

[incredibletimbo]

Die neue Partition habe ich mit ext3 formatiert und als bootable getaggt.

Ähm... du hast die PARTITION formatiert? Du hättest besser /dev/md0 formatiert...

Nur zur Sicherheit: Du hast...
- ...den Partitionstyp bei beiden Partitionen auf fd gesetzt?
- ...das RAID- Device mit mdadm erstellt und gestartet?
- ...in /proc/mdstat geschaut, was da steht? Auch der Typ des Superblocks steht dort drin
- ... /dev/md0 formatiert und gemountet?

So viel fürs erste. Schick mal den Output von /proc/mdstat (nach Booten von CD und Bau des RAID) und deine
/etc/fstab.

timbo

[whatsmyname2009]

Ähm... du hast die PARTITION formatiert? Du hättest besser /dev/md0 formatiert...

Nur zur Sicherheit: Du hast...
- ...den Partitionstyp bei beiden Partitionen auf fd gesetzt?
- ...das RAID- Device mit mdadm erstellt und gestartet?
- ...in /proc/mdstat geschaut, was da steht? Auch der Typ des Superblocks steht dort drin
- ... /dev/md0 formatiert und gemountet?

So viel fürs erste. Schick mal den Output von /proc/mdstat (nach Booten von CD und Bau des RAID) und deine /etc/fstab.

Nein der Raid ist einwandfrei, Partitionen mit FD getaggt, zusammengesetzt und /dev/md0 mit ext3 formatiert, autoassemble funktioniert (Grml beim hochfahren), Filesystem lässt sich ohne Probleme mounten. Mdadm:

Code: Alles auswählen

root@ubuntu:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Sun Oct  4 14:29:32 2009
     Raid Level : raid1
     Array Size : 48829440 (46.57 GiB 50.00 GB)
  Used Dev Size : 48829440 (46.57 GiB 50.00 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Oct  6 11:22:43 2009
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

           UUID : e4fe6f5f:ec1e5422:d8b78f65:99226e41
         Events : 0.6

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1

[incredibletimbo]

Mit Version 0.90 sollte er eigentlich klar kommen. Dann wäre jetzt noch der Output vom fehlgeschlagenen Bootvorgang von Interesse, denn im Moment fällt mir nix mehr ein...

timbo

[whatsmyname2009]

Tja Mist ich weiss auch nicht wie ich ein Log vom Booten kriegen könnte.

DS

[whatsmyname2009]

Was neues: nach einiger Zeit des Festhängens beim Booten springt er in ein Notshell und eine Fehlermeldung kommt "ALERT! /dev/md0 does not exist"!
Die Fehleranalyse ist also richtig.

Gruss,
DS

[whatsmyname2009]

Ich habe nochmal die alten Platten reingehängt, hier bootet alles wie gehabt prima. Es fällt mir auf, daß sich die /boot/grub/grub.cfg-Dateien maßgeblich unterscheiden. Auf dem "alten" System wird root= über UUID angesprochen:

linux /boot/vmlinuz-2.6.30-1-amd64 root=UUID=84372ceb-usw-usf ro quiet

auf dem "migriertem" System heißt es an dieser Stelle:

linux /boot/vmlinuz-2.6.30-1-amd64 root=/dev/md0 ro quiet

Die veränderte grub.cfg-Datei entsteht, wenn ich unter chroot update-grub drüberlaufen lasse. Ich versuche jetzt, grub.cfg per Hand zu verändern, aber die UUID vom neuen Raid-Chain (e4fe6f5f:ec1e5422:d8b78f65:99226e41, siehe oben mdadm) einzutragen hilft auch nichts, immerhin sagt er beim booten jetzt, das dieses Device nicht existiert. Ich nehme mal an, dass es immer noch dasselbe Problem ist, dass beim booten der Raid-Chain nicht zusammengesetzt wird? Ist das richtig? Kennt sich jemand damit aus?

Hilfe!
DS

[agaida]

Es gibt da 2 mögliche Lösungsansätze - vielen Dank erst mal für Dein Thema, das hat mir eine Menge suchen erspart, das ist so ungefähr die Essenz dessen, was man freiwillig aus Google herausbekommt. Da ich das selbe Problem habe/hatte, aber aufgrund mangelnder Kenntnisse und einer irgendwie aufkommenden Frustration keinen Bock mehr hatte, mich darum zu kümmern - folgende Vorschläge:

1. Du nutzt grub legacy und packst Deinen /boot in ein eigenes Raid. Das formatierst Du mit ext2. Über den wunderbaren Befehl grub setzt Du die MBRs der einzelnen Platten und gut ist. Dieser Weg ist in vielen Dokus ausfühlich beschrieben und funktioniert seit Jahren einwandfrei. So habe ich das auf meinem Webserver gelöst und damit die grub2 Problematik umgangen.

2. Wenn die meinen, dass Grub2 Metadaten > 0.90 haben möchte, könnte es durchaus sein, dass das Ernst gemeint ist. Hier heisst es aber nochmal aufpassen, denn ich glaube, Metadaten der jüngesten Generation machen wieder Probleme. Da ich aber grade beim Server schrauben bin und eben genau jenes Problem auch habe, werde ich das heute austesten, denn momentan sieht der Zustand bei mit wie folgt aus. Boot separat sda1, sdb1 ext2, beide mit MBR versehen. Wenn also eine Platte den Hintern zusammenkneift, kann immer noch manuell von der anderen Platte gebootet werden. Ob das Raid dahinter degraded läuft, ist im Fehlerfall erst mal hochgradig Wurst, dafür gibt es den Mail-Eintrag in der mdadm.conf. Die Partitionierung habe ich übrigens deshalb so, damit ich im Notfall zurück auf grub legacy könnte.