• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gelöst: SuSE11 nach XP: Grub bootet nicht; wg. SCSI?

boyherre

Member
Hallo Freunde,
nachdem ich bereits seit SuSE 9 dabei bin (ohne allzuviel Erfahrung), hatte ich nach vielerlei Versuchen unter SuSE-Updates auf 10.3 und danach auf 11 plötzlich Probleme mit Hardware-Anpassung (keine Floppy mehr zu mounten), Scanner weg, Sound-Probleme, usw. - egal: Ich dachte, eine Neu-Installation würde alles klären. . ., erst runtergeladen, dann pc-welt Linux spezial, heute heise c't Linux special gekauft, SuSE 11 installiert - auf einer eigenen, frischen IDE-Platte, parallel zum bestehenden WinXP. Installation verläuft reibungslos inkl. Konfiguration, kann danach sofort loslegen und arbeiten, war happy.
Aber ein Reboot ist nicht möglich: Der Versuch zu booten bringt nur das Wort "GRUB" ohne weitere Ergänzung auf den Bildschirm. Abhilfe schafft nur der Reset-Button. Danach Windows-Reparatur-Konsole mit fixmbr, damit ich wenigstens ein bißchen Rechner habe. . .
Der zusätzliche Rescue-Versuch mit grub-install auf /dev/sda oder /dev/fd0 zeigt dasselbe Ergebnis: Grub wird offenbar fehlerfrei installiert, bestätigt, daß alles stages (1, 1_5 und 2) vorhanden sind, alles "succeeded" etc., aber Grub bootet trotzdem nicht, auch nicht per Floppy. Meine Vermutung: Grub kommt nicht mit SCSI-Platten zurecht.
Die liegen bei mir so im Rechner:
sda=SCSI (FAT32 MBR-Laufwerk/Win-Boot C:), enthält nur WinXP boot.ini, sonst nichts, plus weitere FAT32-Partitionen)
sdb=SCSI (FAT32),
sdd=IDE (WindowsXP-OS auf NTFS Partition U:),
sdc=SATA (NTFS, Win-Daten),
sde=IDE (nur Linux SuSE11, frische Installation).
BIOS-Boot-Reihenfolge:
Floppy, DVD, Festplatte
BIOS-HD-Reihenfolge:
1. SCSI-Card (der klassische Adaptec AHA 2940 - 2 Platten angeschlossen, inzwischen sonst nichts mehr)
2. IDE
3. SATA
4. IDE
Primäre Partitionen nur auf C: (sda) und D: (sdb).
Die ganze Installation ist eigentlich relativ unverdächtig. Wo steckt also der Wurm?
Mir fällt leider nichts mehr ein. . . . :???:
Und übrigens: Ubuntu 8.04 reagiert genauso, auch trotz Grub auf Floppy etc.
Könnt Ihr mir helfen?
Boy
 

spoensche

Moderator
Teammitglied
Grub kommt definit mit SCSI Platten zurecht.

Boote mal mit einer Live-CD und mounte deine / Partition. Danach poste mal die Ausgabe von
Code:
cat /mountpoint/etc/boot/grub/menu.lst
.
 
OP
boyherre

boyherre

Member
Danke für Deine Antwort. Zwischenzeitlich hatte ich den Verdacht, daß ein Hardware-Fehler vorliegt und habe eine erneute Installation versucht, diesmal auf mit GParted zuvor abgeknapsten 40 GB auf der großen SATA-Platte. Lief wunderbar durch, hat aber am beanstandeten GRUB-Verhalten nichts geändert.
Hier der (abgeschriebene/zusammengefaßte) Inhalt der menu.lst nach dieser neuerlichen Installation:

Code:
default 2
timeout 8
gfxmenu (hd3,6) /boot/message

title openSUSE 11.0-2.6.25.5-1.1
root (hd3,6)
kernel /boot/vmlinuz -2.6.25.5-1.1-pae root=/dev/disk/by-id/scsi-SATA_SAMSUNG_HD321KJS0MQJ1KP301644-part7 resume=/dev/sdc6 /splash=silent showopts vga=0x3

title Failsafe
root (hd3,6)
kernel […] showopts ide=nodma apm=off acpi=off noresume no smp noapic maxcpus=0 edd=off x11failsafe vga=0x31a initrd /boot/initrd-2.6.25.5-1.1-pae

title Windows
rootnoverify (hd3,6)
chainloader (hd0,0)+1

title Diskette
rootnoverify (hd3,6)
chainloader (fd0)+1
Hab's vom Bildschirm aus 'ner Rescue-edit-Darstellung vom Screen abgeschrieben, etwaige Tippfehler/Auslassungen sind diesem Umstand geschuldet.

Die Festplattenreihenfolge im BIOS zeigt die SATA-Platte an vierter Stelle, mit SuSE auf den Partitionen sdc6, sdc7 und sdc8 - (hd3,6) müßte also stimmen, oder stimmt sdc nicht? Die dritte Platte (IDE) wird als sdd bezeichnet. Vielleicht liegt's daran, daß in der Boot-Reihenfolge nur die SCSI-Card eingetragen ist, an der aber zwei Platten hängen? Die aber werden erst in der HD-Reihenfolge gelistet. Dann müßte es (hd2,6) heißen…
Wie kann ich jetzt die vorhandene menu.lst editieren, ohne das System starten zu können?
Und mein Gedanke, daß irgendein Controller-Defekt vorhanden ist, würde bedeuten, daß ich den unter WinXP ja auch wahrnehmen müßte - was nicht der Fall ist.
Ich fühl' mich leider wie der Ochs' vorm Berg… :???:
Boy
 
A

Anonymous

Gast
Wo steckt also der Wurm?
Mir fällt leider nichts mehr ein. . . . :???:
Und übrigens: Ubuntu 8.04 reagiert genauso, auch trotz Grub auf Floppy etc.
Könnt Ihr mir helfen?

Das ist mir irgendwie ein bisschen Durcheinander und zu wenige genaue Informationen, um dir hier wirklich gezielt zu helfen, desshalb mal nur ein paar wichtige Punkte die es in diesem Falle eventuell zu beachten gäbe.



erstens wenn du von diesem SCSI-Controller booten willst, dann musst du im Kontroller-BIOS-Menu eine oder beide Platten bootbar kennzeichen, und im Rechner-Bios angeben dass er von diesem SCSI-Controller booten soll und nicht vom BIOS des Rechners.

zweitens der Bootloader und das Verzeichnis in dem stage2 und die Grubkonfigurationen liegen, also /boot/grub/... sollten wann immer möglich auf der gleichen Platte sein. Wahrscheinlich müssen sie aber im selben BIOS-Bereich zu finden sein, also entweder bei Platten beides vom SCSI-BIOS erreichbar oder beides vom Rechner-BIOS erreichbar, deshalb ging wohl auch nicht MBR auf IDE und /boot/grub/stage2 auf SCSI. Solche Fehlkonfigurationen bemerkt Grub bei der Installation nicht, da er dort die Platten nicht über die BIOS-Funktionen sondern über Linuxfunktionen anspricht.

drittens die Reihenfolge der Platten wie sie einerseits von Grub während der Installation gesehen und geschrieben wird, und andererseits beim booten von Grub gesehen wird, ändert sich in dem Moment wenn du im Rechnerbios den SCSI-BIOS aktivierst oder deaktivierst, oder wenn du bei der Installation Platten vorsichtshalber mal ausgebaut hast oder ähnliche Dinge mehr. Du mußt also gegebenenfalls eine Umstellung im BIOS auf einen anderen Kontrollerbios oder auf einen andere Bootplatte schon vor der Installation vornehmen und nicht erst nachdem Grub schon den Bootloader konfiguriert hat.

viertens ist mir aus deinen Angaben nicht ganz klar ersichtlich wie die Plattenreihenfolge beim booten nun wirklich aussieht, und somit ist die /boot/menu.lst alleine erst mal hier wenig hilfreich. ( wird von Grub wohl auch gar nicht erst gefunden, sonst hättest du das Menü gesehen und es währe ein anderer Fehler gekommen.) Die /boot/device.map würde uns aber zumindestens zeigen wie grub das bei der Installation gesehen hat. Ist das durch BIOS-Einstellungen beim booten dann jedoch anders, dann findet er sich nicht mehr zurecht wenn nicht alles auf der selben Platte ist. Die Reihenfolge die der BIOS beim Einschalten während des POST und der Aktivierung der Kontroller sieht, muss nicht zwangsläufig die Reihenfolge sein, die dann beim booten von Grub erkannt würde, insbesondere nicht wenn die Geräte an unterschiedlichen Kontrollern hängen, wie das bei dir der Fall ist.

fünftens wohin hast du denn den Bootloader bei deinem SATA Versuch hinschreiben lassen, auf die SATA, und hast du diese dann im Rechner-BIOS auch als erste zu bootende Platte angegeben. Oder hast du das aussuchen der Position des Bootloaders der Installation überlassen und der hat dir den dann auch wieder auf die erste IDE geschrieben?

sechstens Ist absolut unklar wo sich deine Bootloader jetzt überall befinden und von welchem er seine misslungenen Bootversuche startet. Die Ausgabe von /etc/grub.conf würde uns erstmal zeigen wo Suse den zuletzt hingeschrieben hat. Bei mehreren Installationsversuchen, Updates und dem herumexperimentieren mit grub-install ( undedingt mal hier nach grub-install suchen ) hast du eventuell noch mehrere Bootloader quer über das System gestreut. Entsprechend der jeweiligen Bootreihenfolge wird der erste gefundene gestartet und nicht unbedingt der der zuletzt geschrieben wurde. Alle Bootloader solltest du zB mit diesem Script von einer Live-CD oder ähnlichen aus sehen können. (solltest ihr das mal posten wollen, dann bitte überlange Zeilen radikal auf den Konsens kürzen)
Code:
for i in $(awk '/[0-9]/{print $4}' /proc/partitions)
do
  file -s /dev/$i
done

siebentens die Reihenfolge /dev/sda SCSI ; /dev/sdc/ IDE ; /dev/scd SATA usw. muss nicht unbedingt etwas mit deiner beim Booten vom System bereitgestellten Plattenreihenfolge zu tun haben, sondern ist ua. auch davon abhängig in welcher Reihenfolge innerhalb des Systemstarts die entsprechenden Treiber geladen werden.

achtens Du redest von einer großen SATA auf der du dir Platz geschaffen hast, wahrscheinlich in der hintersten Ecke. uU könnte es auch hier ein Probleme geben, das dein BIOS beim booten nicht bis dort hinten hingucken kann. Ist zwar bei aktuellen BIOSen und Rechnern nicht mehr ganz so häufig, aber kommt dennoch immer wieder mal vor. Was hier oft hilft, ist das auslagern des /boot-Verzeichnisses als eigene Partition weit an den Anfang der Platte.

neuntens hoffe ich, dich nicht zusehr verunsichert zu haben. :roll: Deshalb hier noch mal auch für alle anderen zum mitlesen.

Um bei solchen komplexen Grubproblemen weiterhelfen zu können würden wir genaue Angaben und einige Daten aus dem Rechner benötigen. Insbesondere bei Bootproblemen auf etwas komplizierten Rechnern sind möglichst genaue Informationen unerläßlich, und alles bitte aus einer einzigen Konfiguration heraus und nicht zwischendrin den Rechner noch 3 mal umbauen oder umkonfigurieren oder Fehlermeldungen aus 5 Installationsversuchen mit unterschiedlichen Betriebssytemen untereinander vermischen. Solche Informationen könnten je nach Komplexitat des Problems bei Grub zB, eine Teilmenge von folgendem hier sein.

Code:
fdisk -l
cat /etc/fstab
cat /etc/boot.conf
cat /boot/grub/menu.lst
cat /boot/grub/device.map #(nach Rechnerumkonfigurationen auch die Konfiguration die Grub jetzt anlegen würde, siehe Wikibeitrag)
* Bootreihenfolge im BIOS
* BIOS-Einstellungen von SCSI-Kontroller (oder anderen Kontrollern mit eigenem BIOS)
* genaue Fehlerausgaben beim boot
* wie, und von was wurde der Rechner gestartet, um diese Ausgaben erhalten zu können
* Was hat zum Bootproblem geführt, zB Platteneinbau, Update, Rechnerabsturz, Installation anders BS, keine Ahnung, hat noch nie funktioniert
* in einigen Fällen auch noch Angaben zur Hardware und zu Besonderheiten wie zB Raid mehrere Linuxe oder Versionen,
* besondere Einstellungen bei Installation oder andere Besonderheiten
* was wurde schon probiert und getestet mit welchem Ergebnis moglichst genaue Fehlerausgabe


Je genauer und passender die Informationen zu euerem Fehlerbild , um so weniger Nachfragen von uns, und um so schneller und zielsicherer können wir euch eventuell auch weiterhelfen.



robi
 
OP
boyherre

boyherre

Member
. . . für diese unglaublich ausführliche und instruktive wie lehrreiche Antwort erst mal großen Respekt und ebenso großen Dank!
Schon beim Lesen hab' ich viel gelernt - und nein, es verunsichert mich nicht!
Jetzt muß ich das erst mal verarbeiten und sauber abarbeiten, vielleicht ist die Lösung schon darin enthalten!
Sobald sich daraus was Berichtenswertes ergibt, melde ich mich. . .
Bis dahin erst mal danke - und ein gefälliges Wochenende!
Boy :eek:ps:

Nach diesem Wochenende - Montag/Dienstag-Nacht - nun sehr schöne Neuigkeiten: Das Problem ist Dank der o. a. Hinweise und Erklärungen endlich und nach sehr langer Zeit gelöst.
Dazu habe ich nun folgende Strategie angewendet:
Unter WindowsXP mithilfe der Partitionier-Software von Paragon die Bootpartition von der 1. SCSI-Platte verschoben auf die für Linux vorgesehene 1. IDE-Platte (Laufwerk C primär nur für den MBR und die boot.ini ), mitsamt MBR, die Partition nur zwei GB groß. Die restlichen netto 74 GB dieser 80-GB-Platte als erweiterte Partition mit Ext3 formatiert. Meine eigentliche WindowsXP-Installation (seit jeher auf der 2. IDE-Platte auf Laufwerk U:) mithilfe der Rettungs-Installation an die neue Boot-Partition angebunden und so die Gesamt-Windows-Konfiguration gerettet. Natürlich im BIOS die Plattenreihenfolge zum Booten entsprechend geändert. Nun hatte ich also, wie empfohlen, den MBR und die vorgesehene Linux-Installation auf derselben Platte geplant. Dann brauchte ich nur noch die SuSE-Installation durchlaufen zu lassen - und voila! Der neue MBR wurde sauber geschrieben, und Linux und Windows starten nun jeweils sauber per GRUB parallel. Auf Anhieb und ohne weitere Verrenkungen. Eine ziemliche Erleichterung, kannste glauben! Deine Erläuterungen waren also eine große Hilfe! Dafür einen ebenso großen Dank!
Herzlichst, Boy :D
 
Oben