Hallo, Am Thu, 17 Feb 2011, Thomas Michalka schrieb:
David Haller schrieb:
Guck im BIOS nach der Bootreihenfolge der SATA-Controller.
Die habe ich so eingestellt, dass der MBR der SSD geladen und gestartet wird. Dieser GRUB startet dann je nach Auswahl einen weiteren GRUB in einem Boot-Sektor, der wiederum dann einen Kernel startet.
Und die Controller-Reihenfolge? Welches MoBo? Und an welchem Controller hängt die SSD und die externe Platte?
Ansonsten schau, durch welche Module/Treiber die Controller angesteuert werden. Ich hab hier den Onboard-Controller immer als /dev/sda-/dev/sdf.
Das ist doch erst relevant, wenn der Kernel schon läuft.
Aber die Reihenfolge von sda-sdk wird gemäß SCSI-ID vergeben, und die wiederum hängt von der Reihenfolge der Controller (und Module) ab. Onboard1 (SB710): [0:0:0:0] disk ATA /dev/sda [1:0:0:0] disk ATA /dev/sdb [2:0:0:0] disk ATA /dev/sdc [3:0:0:0] disk ATA /dev/sdd [4:0:0:0] disk ATA /dev/sde [5:0:0:0] disk ATA /dev/sdf Onboard2 (Marvell 9128): [8:0:0:0] disk ATA /dev/sdg [9:0:0:0] disk ATA /dev/sdh [15:0:0:0] process Marvell 91xx Config 1.01 - Onboard3 (JMB362): 2x eSATA, grad nix dran Onboard-IDE (SB710): [17:0:0:0] cd/dvd HL-DT-ST /dev/sr0 [17:0:1:0] disk ATA /dev/sdi Und ich kann eben im Bios die Reihenfolge einstellen (Advanced -> Hard Disk Boot Priority).
Bei mir verhindert aber eine eingeschobene eSATA-Platte, dass der MBR-GRUB die ausgewählte HDD-Partition mit dem zweiten GRUB im Boot-Sektor findet (erst dieser zweite GRUB sollte dann einen Kernel laden und starten).
Wenn der eSATA-Controller ein Extra-Chip ist, dann ist der im BIOS eben vor dem internen. Wie gesagt, schreib mal Details zur HW. Achso, lspci | grep 'ATA\|IDE' bitte auch zeigen.
Das Problem scheint zu sein, dass diese eSATA-Platte die von mir als fix eingestellt geglaubte Boot-Reihenfolge durcheinander bringt (zum Glück verdrängt die nicht die erste Platte, weshalb man alles auf der SSD starten kann).
Eben.
ich habe Deinen langen Beitrrag nicht ganz gelesen, aber die Lösung liegt wahrscheinlich darin, dass Du fstab und grub auf UUIDs umstellst. Glaub ich nicht, denn es geht ja ums Booten, nicht ums Mounten Und was macht der grub? Booten oder mounten?
Booten.
Das ist die eigentliche Aufgabe von GRUB. Aber er "mountet" vorher die Boot-Partition (wohl aber nicht im Sinne des Programms "mount"), um nämlich die menu.lst zu lesen. Zumindest wird das Mounten im GRUB-Manual bei der Beschreibung des root-Kommandos genannt: "Set the current "root device" to the device DEVICE, then attempt to mount it to get the partition size".
Korrekt. Grub schreibt bei der Installation von Grub selber mit in den MBR (bzw. in stage1.5 dahinter) auf welcher Platte und Partition die menu.lst und der Rest vom Grub zu finden sind.
Wenn Du noch eine menu.lst hast, musst Du diese umstellen, glaub' es!
Beim googlen finde ich keine einzige Stelle, wo UUIDs als Ersatz für die GRUB-eigene Notation (hdX) für Geräte und (hdX,Y) für Partitionen beschrieben werden.
Hätte mich auch gewundert.
Die Frage ist, was grub1 dann letztlich daraus macht, d.h. was er als zu verwendendendes (BIOS-(!))Device in den MBR schreibt, wenn man per device.map die devices nach UUID (oder Label oder ID) definiert. Ich glaube nicht, daß grub da z.B. die UUID reinschreibt und beim Booten dann die Platten nach dieser UUID abklappert.
Natürlich nicht, denn wozu bräuchte GRUB dann ein Mapping von den Unix- auf die GRUB-Gerätebezeichner in der "device.map"? Im GRUB-Manual finde ich auch nichts, was auf die Verwendbarkeit von /dev/by-ID/
oder /dev/<UUID-Bezeichner> hindeutet.
Korrekt.
Was grub2 damit macht ... Keine Ahnung.
Wenn er das machen würde, was Du darüber beschreibst (evtl. auch unter Verwendung von Geräte-IDs), dann wäre das ein echter Fortschritt, weil dann nur noch eine Platte als "First Boot Device", von dem GRUB den MBR laden soll, in der BIOS-Konfiguration eingetragen werden müsste. Die anderen Geräte/Partitionen könnte GRUB2 dann aufgrund ihres 'absoluten' Namens finden. In dem Fall hätte ich wohl mein Problem nicht, vielleicht ist also GRUB2 meine Lösung.
Nein: http://www.gnu.org/software/grub/manual/grub.html#Device-map Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map denn eigentlich aus? -dnh -- So Linus, what are we doing tonight? The same thing we do every night Tux. Try to take over the world! -- 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