Grub Startproblem bei zusätzlichen Platten

[sfp77]

Hallo Linux-Gemeinde,

ich habe hier im Forum schon viel über Grub gelesen, aber die Lösung für mein Problem nicht so recht gefunden.

Folgende Plattenkonfiguration habe ich in meinem Rechner:

Am on-Board SATA Controller 2 Platten im RAID 0
Darauf habe ich Debian installiert und es läuft super. ;-)

Dann habe ich einen PCI-SATA-Controller, wo 3 Platten im RAID 5 hängen.

Die Startreihenfolge ist so, dass zuerst das PCI-Controller BIOS angezeigt wird und dann der interne Controller das RAID 0 anzeigt.
Die Platten am PCI-Controller hängen zusätzlich an einer SATA-Backplane.

Wenn ich jetzt den Rechner starte und die Platten am PCI Controller aus lasse, dann startet Debian ganz normal ohne Probleme.

Wenn ich die Platten anschalte, dann sehe ich das Grub-Menü, Grub lädt, endet aber dann mit dem Punkt "savedefault" ohne Fehlermeldung. Das System bleibt einfach stehen und bootet nicht weiter. Grub ist in den MBR installiert.

Ich kann auch den Rechner starten und die Platten am PCI-Controller erst beim starten von Debian anschalten. Das funktioniert auch.

Allerdings halte ich das nicht für die beste Lösung. ;-)
Kann mir jemand helfen wie ich es hinbekomme, dass Debian vernünftig lädt, wenn die Platten von anfang an angeschaltet sind?

Leider kann ich nicht genau sagen, wie die Reihenfolge der Platten mit "fdisk -l" genau ist, da ich einen Treiber für den PCI-Controller brauche der für das Debian-System kompiliert ist und nur da geladen wird. Deshalb hilft mir auch eine Live-CD nicht weiter.

Weiß jemand, wie ich die richtige Plattenreihenfolge trotzdem herausbekomme?

Danke und Gruß

Sören

[RockingRolli]

Hallo Sören,
kann sein, dass grub mit der Festplattenreihenfolge durcheinander kommt. Benutze die UUID für die Festplatten und das Problem könnte behoben sein

Gruß,
Roland

[Aqualung]

Am on-Board SATA Controller 2 Platten im RAID 0
Darauf habe ich Debian installiert und es läuft super. ;-)


Hardware-RAID, richtig? Das Debian sieht gar nix von RAID, für Debian ist es einfach eine schnelle Platte.

Im Kofler steht zu RAID und LVM und GRUB, dass Grub 0.9.n nicht mit einer /boot-Partition zurechtkommt, die im RAID/LVM liegt. Eigentlich ist das bei Dir ja nicht der Fall. Oder bindest Du etwa Dein RAID 0 mit den anderen Platten zu einem RAID 5 zusammen? Die Anzahl der Platten würde das ja nahe legen, allerdings dürftest Du dann kein Hardware-RAID haben :confused:

Das "savedefault" würde ich in der menu.lst mal rausnehmen - das ist im RAID-Kontext von Übel.

Generell ist Lilo im RAID-Umfeld gutmütiger, weil der ja zur Bootzeit nix in die /boot -Partition schreiben kann.


Gruß Aqualung

[tictactux]

Hi Sören,
mit Debian Sarge in Verbindung mit Hardware-RAID-Controllern hatte ich auch öfter das Problem, daß die Laufwerksnamen nicht sicher definiert waren.
Manchmal wird dem RAID sda und manchmal sdb/sdc u.s.w. zugewiesen, je nachdem wie schnell die Initialisierung des RAID-Controllers erfolgte.

Als Lösung hab ich in /boot/grub/menu.lst und /etc/fstab die Platten über LABEL= angesprochen, analog ginge auch die oben erwähnten UUIDs,
wobei bei vielen Platten (die auch mal ersetzt werden) IMHO Labels praktischer wären.

HTH
Wolfgang

[sfp77]

Hallo,

erstmal vielen Dank für Eure Hilfe.
Nachdem ich mich erstmal in das Thema UUIDs etwas eingearbeitet habe hier meine Ergebnisse und Vorgehensweise:

Listing von: fdisk -l



Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 5099 40957686 7 HPFS/NTFS
/dev/sda2 5100 14200 73103782+ 83 Linux
/dev/sda3 14201 14593 3156772+ 5 Extended
/dev/sda5 14201 14593 3156741 82 Linux swap / Solaris
Warning: invalid flag 0x0000 of partition table 5 will be corrected by w(rite)

Disk /dev/sdb: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 5099 40957686 7 HPFS/NTFS
/dev/sdb2 5100 14200 73103782+ 83 Linux
/dev/sdb3 14201 14593 3156772+ 5 Extended

Disk /dev/sdc: 1000.0 GB, 1000056291328 bytes
255 heads, 63 sectors/track, 121583 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 121583 976615416 83 Linux


Es handelt sich bei beiden Controllern OnBoard und PCIX um keine "echten" RAID-Controller.

Ein: ls -l /dev/disk/by-uuid



UUID sdc1 1c612eac-4015-45fd-8208-2611276945c5 (RAID5)
UUID sda1 7A68176B68172583
UUID sda2 e0bf2865-dcc8-4d0b-89dd-12b950815196 (RAID1)


Dann habe ich die Einträge in /boot/grub/menu.lst wie folgt angepasst:



# kopt=root=UUID=e0bf2865-dcc8-4d0b-89dd-12b950815196 ro

title Debian GNU/Linux, kernel 2.6.18-5-amd64 (normal)
kernel /boot/vmlinuz-2.6.18-5-amd64 root=UUID=e0bf2865-dcc8-4d0b-89dd-12b950815196 ro
initrd /boot/initrd.img-2.6.18-5-amd64


Danach ein: vim /etc/fstab



# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=e0bf2865-dcc8-4d0b-89dd-12b950815196 / ext3 defaults,errors=remount-ro 0 1
/dev/sda5 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
UUID=1c612eac-4015-45fd-8208-2611276945c5 /home/daten ext3 user,suid,dev,exec 0 0


Zum Schluss, ein beherztes update-grub

Leider hatte ich keinen Erfolg damit!
Das Ergebnis ist das Gleiche. Ohne RAID 5-Platten startet debian wie gewohnt und gut.
Wenn ich die RAID 5 Platten vom BIOS starten lasse, bekomme ich nur folgende Bildschrimausgabe:



Booting 'Debian GNU/Linux, kernel 2.6.18-5-amd64 (normal)'
kernel /boot/vmlinuz-2.6.18-5-amd64 root=UUID=e0bf2865-dcc8-4d0b-89dd-12b950815196 ro
[Linux-bzImage, setup=0x1e00, size=0x16f450]
initrd /boot/initrd.img-2.6.18-5-amd64
[Linux-initrd @ 0x37aeb000, 0x505000 bytes]


Weiter passiert garnix?! :-(

@Aqualung
Ich habe auch versucht LILO zum Laufen zu bewegen, allerdings hatte ich Probleme beim konfigurieren. Kann es sein, dass LILO nicht mit der AMD64-Version von Debian funktioniert?

@Wolfgang
Mit dem Label bin ich auch nicht weitergekommen. Ich hatte der sda2 das Label "system" verpasst und fstab und menu.lst entsprechend angepasst. Selbes Ergebnis, ohne RAID5-Platten, alles wie gewohnt, mit: hängt grub bei starten fest! :-(

Habe ich vergessen etwas auf UUID umzustellen? Noch irgendwelche Einträge in der menu.lst oder so? Mir ist da ab und zu nochmal ein groot (hd0,1) aufgefallen?!

Vielen Dank für Eure Ratschläge und ein schönes Wochenende,

Sören

[tictactux]

da das Ganze anscheinend schon direkt nach Laden der initrd stoppt, würde ich die Konfiguration der initrd untersuchen.
z.B. ob die benötigten Module da rechtzeitig geladen werden..
Anlaufste,le wären unter Debian deren Konfigurationsdateien unter /etc/initramfs-tools, speziell die Datei modules dort.
Siehe dazu die Doku die apropos initramfs nennt.

HTH
Wolfgang

[sfp77]

Hallo an Alle,
Hallo Wolfgang,

super Tip mit initramfs!
Gesagt, getan, habe ich mir die Doku zu initramfs angeschaut.

1. ein vim /etc/initramfs-tools/modules brachte bei mir:




# List of modules that you want to include in your initramfs.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod


Also nicht wirklich viel! ;-) *grübbel*

Zum testen habe ich einfach mal folgendes gemacht:



# List of modules that you want to include in your initramfs.
#
# Syntax: module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
rr2310_00
# Treibermodul von meinem RAID5 Controller welches beim booten geladen wird


Danach ein Hoffnungsvolles: update-initramfs -k`uname -r` -t -u



update-initramfs: Generating /boot/initrd.img-2.6.18-5-amd64


Um zu überprüfen ob alles seine Richtigkeit hat:


cp /boot/initrd.img-2.6.18-5-amd64 /tmp/initrd.img.gz
gzip -d initrd.img.gz
mkdir initrd-folder
cd initrd-folder
cpio -id < ../initrd.img


Aber der modules-Ordner unter /tmp/initrd-folder/modules
Ist immer noch leer?!

Kann mir jemand weiterhelfen?

Viele Grüße,

Sören

[tictactux]

Hi nochmal,

also die Vorgehensweise nochmal kurz:
Nach Editieren der /etc/initramfs-tools/initramfs.conf und modules:
update-initramfs -u
keine weiteren Argumente nötig, wenn der richtige Kernel läuft.

Um zu prüfen ob die erstellte initramfs alles nötige enthält:
-die Datei modules landet in der initramfs als /conf/modules
-unter /lib/modules/`uname -r`/... sollte das Modul für den RAID-Controller drin sein.
Tipp: falls Du den Midnight Commander (mc) benutzt, brauchst Du die initramfs nicht manuell entkomprimieren, kopiere sie einfach irgendwohin, und nach Umbenennen mit Endung .cpio.gz öffnet der mc sie wie andere Archive.
Ist praktisch um mal eben schnell reinzuschauen ;)

[sfp77]

Hallo Wolfgang,

besten Dank für die Hinweise. Der mc ist ja wirklich Klasse. Da fühlt man sich direkt in die guten alten Zeiten vom Norton Commander zurückversetzt. ;-)
Nun aber zu meinem Problem! Nachdem ich noch eine Weile mit der initrd.img rumgespielt habe, hatte ich mir gleich die erste "kernel panic!" eingehandelt. Das habe ich gleich zum Anlass genommen ein neues Kernel-Update einzuspielen (2.6.18-6-amd64).
Getreu dem Moto: "Wer nicht patched verliert!", habe ich den Treiber für den RAID5-Controller neu kompiliert. Dabei ist mir aufgefallen, dass das Installationsskript die initrd.img gleich mit pached! So hatte ich dann eine "Originale" initrd.img-2.6.18-6-amd64 (ungepached) und eine initrd.img-2.6.18-6-amd64 (gepached) erhalten. Die gepachte Version ist ca. 100kB grösser als die Originale, was dafür spricht, dass da auch mehr drin ist. Nach einem Blick in die gepachte Datei findet man unter:


/lib/modules/2.6.18-6-amd64/drivers/scsi/rr2310_00/rr2310_00.ko

Den Treiber für den RAID-Controller!

Schaut man sich die Datei /conf/modules an, gibt es da 2 Einträge:



rr2310_00
unix


Aber geändert hat sich leider nichts. Debian hängt beim Starten immer noch an dem Punkt fest:



Booting 'Debian GNU/Linux, kernel 2.6.18-6-amd64'
kernel /boot/vmlinuz-2.6.18-6-amd64 root=LABEL=raid1 ro
[Linux-bzImage, setup=0x1e00, size=0x16f450]
initrd /boot/initrd.img-2.6.18-6-amd64
[Linux-initrd @ 0x37aeb000, 0x505000 bytes]


Bei ausgeschalteten RAID5-Platten läuft alles normal!
Ich habe auch versucht von der ungepachteten, originalen Initrd.img Version zu booten.
Das Ergebnis ist das Selbe: Ohne Platten geht's, mit Platten geht gar nix! :-(

Weiß noch jemand was?!

Vielen Dank,

Sören

[tictactux]

tja, leider kann ich dazu mangels Hardware nicht mehr viel sagen, doch ein kurzes googlen nach "rr2310_00 hängt" oder "rr2310_00 hang" zeigt daß innerhalb der letzten 2-3 Monate etliche Leute Probleme dieser Art hatten, sowohl beim Booten als auch im laufenden Betrieb.

Falls möglich, würde ich mal testen, ob die 32-Bit Version von Debian dieses Problem auch hat, bei 64-Bit liest man schon öfter mal, daß der eine oder andere Treiber (noch) Probleme macht, besonders welche mit proprietärem Binärmodul wie es hier anscheinend der Fall ist (laut Alan Cox in der Kernel Mailingliste)
Viel Erfolg

[sfp77]

Hallo,

Tja! Das ist zwar nicht gerade die Antwort die ich mir erhofft hatte aber anscheinend leider nicht zu ändern. Trotzdem vielen Dank für die tolle Hilfe an alle die sich mit meinem Problem beschäftigt haben. Sollte ich noch eine Lösung finden, dann werde ich Sie hier posten.

gruß

Sören