Hallo Roman, Roman Fietze schrieb:
Hallo Thomas,
On Saturday, December 11, 2010 05:45:04 pm Thomas Michalka wrote:
Beim Booten sieht man kurz die Meldungen "GRUB loading Stage1.5" und "GRUB loading, wait ..." (sinngemäße Wiedergabe aus der Erinnerung) aufblitzen. Danach startet das System von selber neu mit den üblichen BIOS-Meldungen (Laufwerkserkennung u.s.w.) ==> Endlos-Boot-Schleife.
Genau das habe ich hier jetzt wieder auf einem IBM eServer e326 mit einem LSI RAID 1 und einem RaidServe M6 mit einem RAID5 und einer nicht-RAID-Platte, also insgesamt drei logischen Platten.
Ein Problem ist z.B., dass die OS 11.3 im Rescue-System die Platten in einer anderen Reihenfolge einhaengt (sda, sdb, sdc)
Das passiert auch, wenn man ab und zu eine externe Platte an einem eSATA-Anschluss eingeschoben hat. Dann ist bei mir diese Platte sda und die Hauptplatte sdb. Warum können sda, sdb, ... nicht einfach fix den SATA-Anschlussnummern des BIOS zugeordnet sein?
Ein weiteres Problem koennte sein, dass das BIOS evt. einen Hund hat. Aber auf solch einer Gurke das BIOS auf den aktuellen Stand zu bringen ist mit viel Aufwand verbunden.
Ja, z.B. erscheint ein USB-Stick im Boot-Menü (<F8>) ohne Bezeichnung, also man sieht nur einen weiteren Eintrag, aber man kann nur raten, ob der jetzt da ist, weil da ein Removable-Device eingesteckt ist und erkannt wurde. Wähle ich den 'leeren' Eintrag aus, konnte ich wirklich die SuperGrubDisk booten.
Momentan kann ich das System (wieder mal) nur per kexec booten, also DVD->Rescue, mount /boot nach /mnt und ein kexec hinterherschieben.
Ich finde unter http://de.opensuse.org/Kexec den Hinweis auf das Paket kexec-tools. Werde es mir installieren, mal sehen ...
Kann man eigentlich ein installiertes System von außen (z.B. mit einer DVD) booten, wenn dort überhaupt kein Boot-Loader installiert ist? Z.B., indem man die Lage des Kernels und andere Informationen mitteilt?
Ich habe ein kleines Script nach /boot gelegt mit folgendem Inhalt:
--- snippety-snip --- #!/bin/bash
REV='2.6.34.7-0.5'
kexec \ --command-line="root=/dev/vgr10/lvroot showopts noresume powersaved=off vga=0x317" \ --initrd=/mnt/initrd-${REV}-default \ /mnt/vmlinuz-${REV}-default --- snappety-snap ---
Unter welcher Bedingung startet es? Wenn man einen Kernel in Ermangelung eines funktionierenden grub gar nicht erst laden und starten kann :-( Ich verstehe die Paketbeschreibung so, dass vorher schon ein Kernel laufen musste.
Ich habe noch nicht herausgefunden was schief laeuft. Vermutlich werde ich wenn ich Zeit habe mal die ersten 446 Bytes jeden MBRs mit Nullen ueberschreiben und schauen, was das BIOS dann sagt.
Sind das die erste 446 Bytes der Platte überhaupt? Danach kommt die Partitionstabelle, oder?
Dann werde ich eins nach dem Anderen den MBR mit stage1 von grub beschreiben, um erst mal herauszufinden welche logische HD das BIOS ueberhaupt dahernimmt um stage1 zu laden. Erst wenn ich das weiss, versuche ich einen Schritt weiterzudenken.
Eine solche RAID-Situation ist sicher die schwierigere. Aber bei meinem Desktop-Rechner sollte das BIOS doch einfach den MBR der als erstes Gerät eingetragenen HDD laden und starten (Boot-Priorität auf HDD vorausgesetzt). Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org