Multiboot-Vorgang beeinträchtigt durch eSATA-Platte
Hallo zusammen, ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet: 1) Boot des MBR (GRUB) von der SSD --> Auswahl eines Bootsektors (GRUB) auf der SSD oder auf der HDD mittels "chainloader +1" 2) Laden & Starten des unter 1) ausgewählten Bootsektors --> der Bootsektor bietet ggf. eine Auswahl eines Kernels an 3) Laden & Starten des unter 2) ausgewählten Kernels 4) System läuft hoch So, wie es von Punkt 1) bis 4) beschrieben ist, funktioniert das für alle Systeme, die auf den Massenspeichern liegen, einwandfrei. Aber nur solange keine weitere HDD am eSATA-Port hängt. Ist das der Fall, kann ich nur noch das System auf der SSD hochfahren. NB: Läuft das OS, dann erhalte ich durch fdisk -l folgende Aufstellung: --- Die eSATA-Wechsel-HDD --- Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0005df91 <Partitionierung> --- Die eingebaute SSD --- Disk /dev/sdb: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0009d2af <Partitionierung> --- Die eingebaute HDD --- Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x988baa5f <Partitionierung> Die Partitionierung tut nichts zu Sache. Ohne die eSATA-HDD rutschen die eingebauten Geräte auf /dev/sda (SSD) und /dev/sdb (HDD), wie sie auch im BIOS eingetragen sind. Wenn beim Booten die eSATA-HDD eingesteckt ist, dann steht sie in der BIOS-Boot- Konfiguration auch schön an der dritten Stelle der Platten (herausnehmen kann man sie hier nicht). Ich glaube aber, dass die Geräte-Buchstaben X in /dev/sdX nichts mit der BIOS-Plattenreihenfolge oder Boot-Reihenfolge zu tun haben, da diese wohl erst vom laufenden Kernel vergeben werden. Die eSATA-Ports sind aber anscheinend an einen eigenen Controller angebunden und nicht an den Chipsatz, so meine Vermutung, denn die eSATA-HDD wird nach dem BIOS-Start nicht unmittelbar in der Liste der vom BIOS erkannten Platten angezeigt, sondern bei einem Controller auf der 'zweiten' Anzeige (nach der Löschung der ersten Start-Anzeige). Jedenfalls funkt die eSATA-HDD gehörig dazwischen, denn GRUB meldet bei einer Auswahl eines Systems auf der eingebauten HDD, dass es entweder eine solche Partition nicht gibt (Error 22; klar, wenn durch meine Auswahl der Bootsektor auf (hd1,8) geladen werden müsste, aber nur vier Partitionen auf der eSATA-HDD sind), oder dass er im Fall von (hd1,0) bis (hd1,3) keinen gültigen Boot-Code finden konnte (Error 13; auch klar, da die eSATA-HDD nur Daten-Partitionen für lokale Backups enthält). Das Problem ist also klar: die eSATA-HDD verändert die Gerätereihenfolge, weshalb dann die menu.lst für den GRUB im MBR die falschen root-Angaben (root (hd1,8) z.B.) enthält, die für die zwei fest eingebauten Geräte alleine aber stimmen. Lösung? 1) Kann oder sollte man dem BIOS beibringen, dass es eine eingesteckte eSATA-HDD nicht erkennt? Das Booten müsste dann funktionieren, denn man kann diese Platte auch erst bei laufendem System einstecken. Wenn ja, wie manipuliert man das BIOS richtig (den Controller auszuschalten wäre wohl nicht sinnvoll, weil es dann vielleicht keine eSATA-Ports mehr gibt)? 2) Kann man GRUB beibringen, diese eSATA-HDD zu 'übersehen' oder auszublenden? Wenn ja, wie geht das? Vielen Dank schon mal fürs Mitdenken! 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
Thomas Michalka schrieb:
Hallo zusammen,
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung?
Moin Thomas, ich habe Deinen langen Beitrrag nicht ganz gelesen, aber die Lösung liegt wahrscheinlich darin, dass Du fstab und grub auf UUIDs umstellst. Viel Erfolg, Boris -- 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
Hallo Boris, Boris schrieb:
Thomas Michalka schrieb:
Hallo zusammen,
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung?
Moin Thomas,
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 (ein Kernel läuft da noch gar nicht). Und der GRUB kann zwar Dateisysteme lesen, kann aber nur mit _seiner_ Notation der Partitionen (hdX,Y) darauf zugreifen, um die Datei "menu.lst" einzulesen, um dort wiederum Angaben, wie root (hdX,Y) zu lesen und verarbeiten. Danke trotzdem! Gruß, Thomas -- 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
Am Sonntag, 13. Februar 2011 15:32 schrieb Thomas Michalka:
Glaub ich nicht, denn es geht ja ums Booten, nicht ums Mounten (ein Kernel läuft da noch gar nicht). Und der GRUB kann zwar Dateisysteme lesen, kann aber nur mit _seiner_ Notation der Partitionen (hdX,Y) darauf zugreifen...
Wenn ich einige andere Threads richtig interpretiere ist in GRUB die Datei /boot/grub/device.lst für die Umsetzung UUID -> hdn zuständig. Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listpm (@) arndt-de (.) eu -- 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
Hallo Ralf, Ralf Arndt schrieb:
Am Sonntag, 13. Februar 2011 15:32 schrieb Thomas Michalka:
Glaub ich nicht, denn es geht ja ums Booten, nicht ums Mounten (ein Kernel läuft da noch gar nicht). Und der GRUB kann zwar Dateisysteme lesen, kann aber nur mit _seiner_ Notation der Partitionen (hdX,Y) darauf zugreifen...
Wenn ich einige andere Threads richtig interpretiere ist in GRUB die Datei /boot/grub/device.lst für die Umsetzung UUID -> hdn zuständig.
Ich kenne nur die /boot/grub/device.map Nach intensiver Lektüre das GRUB-Manuals denke ich, dass diese Datei nur für das Skript grub-install, dem man als Argument Geräte in der Schreibweise /dev/sdX übergeben kann, gebraucht wird. In allen anderen Fällen sehe ich immer nur die GRUB-eigene Schreibweise (hdX,Y). 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
Thomas Michalka schrieb:
Hallo Boris,
Boris schrieb:
Thomas Michalka schrieb:
Hallo zusammen,
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung? Moin Thomas,
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? (ein
Kernel läuft da noch gar nicht). Und der GRUB kann zwar Dateisysteme lesen, kann aber nur mit _seiner_ Notation der Partitionen (hdX,Y) darauf zugreifen, um die Datei "menu.lst"
Ich weiß ja nicht, wie es in SuSE ist, aber in Debian heißt die menu.lst inzwischen grub.cfg. Darin sind die Platten mit UUIDs spezifizert = zukunftsweisend. Wenn Du noch eine menu.lst hast, musst Du diese umstellen, glaub' es! http://lmgtfy.com/?q=grub+menu.lst+uuid Boris -- 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
Hallo, Am Tue, 15 Feb 2011, Boris schrieb:
Thomas Michalka schrieb:
Boris schrieb:
Thomas Michalka schrieb:
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung?
Guck im BIOS nach der Bootreihenfolge der SATA-Controller. Ansonsten schau, durch welche Module/Treiber die Controller angesteuert werden. Ich hab hier den Onboard-Controller immer als /dev/sda-/dev/sdf.
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.
(ein
Kernel läuft da noch gar nicht). Und der GRUB kann zwar Dateisysteme lesen, kann aber nur mit _seiner_ Notation der Partitionen (hdX,Y) darauf zugreifen, um die Datei "menu.lst"
Ich weiß ja nicht, wie es in SuSE ist, aber in Debian heißt die menu.lst inzwischen grub.cfg. Darin sind die Platten mit UUIDs spezifizert = zukunftsweisend.
Das ist allerdings grub2. Um den wird man aber eh nimmer lange rumkommen, denn spätestens mit Platten >4 TB braucht man GPT Partitionstabellen (für ein Linux-Only System aber kein UEFI).
Wenn Du noch eine menu.lst hast, musst Du diese umstellen, glaub' es!
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. Was grub2 damit macht ... Keine Ahnung. HTH, -dnh -- Turne bis zur Urne! -- Hagen Rether -- 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
Hallo David, David Haller schrieb:
Hallo,
Am Tue, 15 Feb 2011, Boris schrieb:
Thomas Michalka schrieb:
Boris schrieb:
Thomas Michalka schrieb:
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung?
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.
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. 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). 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).
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".
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.
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/
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. 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
Thomas Michalka schrieb:
Hallo David,
David Haller schrieb:
Hallo,
Am Tue, 15 Feb 2011, Boris schrieb:
Thomas Michalka schrieb:
Boris schrieb:
Thomas Michalka schrieb:
ein Rechner soll abwechselnd Systeme von einer SSD oder einer HDD booten können. Konkret ist das folgendermaßen eingerichtet:
Lösung? 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.
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. 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). 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).
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".
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.
Grub braucht zunächst auch nur wissen, wo er den Kern (und die initrd) findet. Ein typischer Eintrag sieht so aus: title Ubuntu, kernel 2.6.20-15-generic root (hd0,0) kernel /vmlinuz-2.6.20-15-generic root=UUID=d8483377-ed86-4dad-8f44-50e45f53f979 ro quiet splash initrd /initrd.img-2.6.20-15-generic quiet savedefault Gruß, Boris -- 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
Hallo Boris, Boris schrieb:
Am Tue, 15 Feb 2011, Boris schrieb:
Thomas Michalka schrieb:
Boris schrieb: [...]
Wenn Du noch eine menu.lst hast, musst Du diese umstellen, glaub' es!
http://lmgtfy.com/?q=grub+menu.lst+uuid 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.
Grub braucht zunächst auch nur wissen, wo er den Kern (und die initrd) findet. Ein typischer Eintrag sieht so aus:
title Ubuntu, kernel 2.6.20-15-generic root (hd0,0) kernel /vmlinuz-2.6.20-15-generic root=UUID=d8483377-ed86-4dad-8f44-50e45f53f979 ro quiet splash initrd /initrd.img-2.6.20-15-generic quiet savedefault
Siehst Du, die UUID des Root-Dateisystems schreibst Du hinter "root=". Das ist aber ein Parameter, den GRUB an den Kernel, den er startet, übergibt (dieses "root=" steht hinter dem GRUB-Befehl "kernel", ist hier also kein GRUB-Befehl i.Ggs. zu dem "root (hd0,0)"; GRUB 0.97 kennt m.E. weder UUIDs noch Geräte-IDs, bei GRUB2 mag das anders sein). Ich habe aber folgende Situation (die ich, wie auch den Boot-Ablauf, in Worten in meinem ersten Posting ausführlich beschrieben habe): Mein GRUB im MBR des ersten Bot Device (SSD) liest folgende menu.lst (hier ein Auszug) ein: title openSuSE 11.0 on >>> SSD <<< (/dev/sdX3) root (hd0,2) chainloader +1 savedefault title Knoppix 5.3.1 on HDD (/dev/sdX7) root (hd1,6) chainloader (hd1,6)+1 title Ubuntu 8.04 on HDD (/dev/sdX8) root (hd1,7) chainloader (hd1,7)+1 title openSuSE 11.0 on HDD (dev/sdX9) root (hd1,8) chainloader (hd1,8)+1 Wenn beim Booten schon die eSATA-Platte im Rechner steckt, dann kann ich durch Auswahl das erste eingetragene System (hd0,2) von der SSD booten, nicht aber die Systeme von der HDD (hd1,X). Ohne die eSATA-Platte geht das aber! Die GRUB-Fehlermeldung lautet ungefähr so: "(hd1,8) Error 22: Partition not found" Ich habe inzwischen das BIOS-Setup durchsucht, aber keine Möglichkeit gefunden, die eSATA-Platte bzw. den JMicron-Chipsatz in der Plattenreihenfolge nach hinten auf eine Fixposition zu schieben, so dass die Platte sich beim Booten nicht mehr vordrängelt. Hier scheint es kein Weiterkommen zu geben. Deshalb frage ich nochmal: Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben. Danke nochmal für's Mitdenken und jegliche Anregung! 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
Hallo Thomas,
Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben.
Danke nochmal für's Mitdenken und jegliche Anregung!
ich habe leider keine Lösung sondern hatte mich auch mal mit der Materie beschäftigt. Zum ersten, kann Grub in dem Status wohl nicht erkennen, was eine eSATA-Platte ist und was nicht. eSATA ist das gleiche wie internes Sata, nur ist das Kabel nach aussen geführt. Desweiteren habe ich in Erinnerung, dass die Reihenfolge wie man die Platten in der device.map bei Grub 1 pflegt immer die Reihenfolge entsprechen soll, wie das Bios die Platten sortiert. Also, das eingestellt Boot-Device im Bios sollte hd0 entsprechen. Wenn Du das Primary Boot Device im Bios nicht konfigurieren kannst, sehe ich momentan keine direkte Lösung. Das ging damals bei meinem Mainboard mit Onboard Raid und normale HD-Anschluss, war allerdings noch PATA. Gruss Patrick -- 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
Hallo, Am Fri, 18 Feb 2011, Thomas Michalka schrieb:
Boris schrieb:
Am Tue, 15 Feb 2011, Boris schrieb:
Thomas Michalka schrieb:
Boris schrieb: [...]
Wenn Du noch eine menu.lst hast, musst Du diese umstellen, glaub' es!
http://lmgtfy.com/?q=grub+menu.lst+uuid 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.
Grub braucht zunächst auch nur wissen, wo er den Kern (und die initrd) findet. Ein typischer Eintrag sieht so aus:
title Ubuntu, kernel 2.6.20-15-generic root (hd0,0) kernel /vmlinuz-2.6.20-15-generic root=UUID=d8483377-ed86-4dad-8f44-50e45f53f979 ro quiet splash initrd /initrd.img-2.6.20-15-generic quiet savedefault
Siehst Du, die UUID des Root-Dateisystems schreibst Du hinter "root=". Das ist aber ein Parameter, den GRUB an den Kernel, den er startet, übergibt (dieses "root=" steht hinter dem GRUB-Befehl "kernel", ist hier also kein GRUB-Befehl i.Ggs. zu dem "root (hd0,0)"; GRUB 0.97 kennt m.E. weder UUIDs noch Geräte-IDs, bei GRUB2 mag das anders sein).
Korrekt. Grub interessiert hier nur die Angabe 'root'. Obiges kann man übrigens auch direkt angeben: title Ubuntu, kernel 2.6.20-15-generic kernel (hd0,0)/vmlinuz-2.6.20-15-generic root=... initrd (hd0,0)/initrd.img-2.6.20-15-generic
Ich habe aber folgende Situation (die ich, wie auch den Boot-Ablauf, in Worten in meinem ersten Posting ausführlich beschrieben habe): Mein GRUB im MBR des ersten Bot Device (SSD) liest folgende menu.lst (hier ein Auszug) ein:
title openSuSE 11.0 on >>> SSD <<< (/dev/sdX3) root (hd0,2) chainloader +1 savedefault
title Knoppix 5.3.1 on HDD (/dev/sdX7) root (hd1,6) chainloader (hd1,6)+1
Wenn du bei chainloader das Grub-Device angibst kannst du 'root' weglassen. Also title Knoppix 5.3.1 on HDD (/dev/sdX7) chainloader (hd1,6)+1 [..]
Wenn beim Booten schon die eSATA-Platte im Rechner steckt, dann kann ich durch Auswahl das erste eingetragene System (hd0,2) von der SSD booten, nicht aber die Systeme von der HDD (hd1,X). Ohne die eSATA-Platte geht das aber! Die GRUB-Fehlermeldung lautet ungefähr so:
"(hd1,8) Error 22: Partition not found"
Ich habe inzwischen das BIOS-Setup durchsucht, aber keine Möglichkeit gefunden, die eSATA-Platte bzw. den JMicron-Chipsatz in der Plattenreihenfolge nach hinten auf eine Fixposition zu schieben, so dass die Platte sich beim Booten nicht mehr vordrängelt. Hier scheint es kein Weiterkommen zu geben. Deshalb frage ich nochmal:
Siehe dazu meine andere Mail.
Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben.
Nein. Du könntest aber '(hd2,N)' Einträge ergänzen. Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten. -dnh -- Wenn Windows 98 die Antwort ist, wie blöd ist dann die Frage gewesen? -- 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
Hallo David, David Haller schrieb:
Hallo,
Am Fri, 18 Feb 2011, Thomas Michalka schrieb:
Boris schrieb:
title Ubuntu, kernel 2.6.20-15-generic root (hd0,0) kernel /vmlinuz-2.6.20-15-generic root=UUID=d8483377-ed86-4dad-8f44-50e45f53f979 ro quiet splash initrd /initrd.img-2.6.20-15-generic quiet savedefault
Siehst Du, die UUID des Root-Dateisystems schreibst Du hinter "root=". Das ist aber ein Parameter, den GRUB an den Kernel, den er startet, übergibt (dieses "root=" steht hinter dem GRUB-Befehl "kernel", ist hier also kein GRUB-Befehl i.Ggs. zu dem "root (hd0,0)"; GRUB 0.97 kennt m.E. weder UUIDs noch Geräte-IDs, bei GRUB2 mag das anders sein).
Korrekt. Grub interessiert hier nur die Angabe 'root'. Obiges kann man übrigens auch direkt angeben:
title Ubuntu, kernel 2.6.20-15-generic kernel (hd0,0)/vmlinuz-2.6.20-15-generic root=... initrd (hd0,0)/initrd.img-2.6.20-15-generic
Stimmt. Das wollte ich auch noch ausprobieren, weil ich dazu im GRUB-Manual keinen klaren Hinweis fand.
Ich habe aber folgende Situation (die ich, wie auch den Boot-Ablauf, in Worten in meinem ersten Posting ausführlich beschrieben habe): Mein GRUB im MBR des ersten Bot Device (SSD) liest folgende menu.lst (hier ein Auszug) ein:
title openSuSE 11.0 on >>> SSD <<< (/dev/sdX3) root (hd0,2) chainloader +1 savedefault
title Knoppix 5.3.1 on HDD (/dev/sdX7) root (hd1,6) chainloader (hd1,6)+1
Wenn du bei chainloader das Grub-Device angibst kannst du 'root' weglassen. Also
title Knoppix 5.3.1 on HDD (/dev/sdX7) chainloader (hd1,6)+1
Klar, genau wie oben bei "kernel" und "initrd".
Wenn beim Booten schon die eSATA-Platte im Rechner steckt, dann kann ich durch Auswahl das erste eingetragene System (hd0,2) von der SSD booten, nicht aber die Systeme von der HDD (hd1,X). Ohne die eSATA-Platte geht das aber! Die GRUB-Fehlermeldung lautet ungefähr so:
"(hd1,8) Error 22: Partition not found"
Noch eine kleine Ergänzung: Diese Meldung kommt nur, wenn man ein System auf einer Partition wählt, die es auf der dazwischen gemogelten eSATA-Platte nicht gibt. Im Falle von (hd1,2) habe ich folgende Meldung: "(hd1,2) Error 13: Invalid or unsupported executable format" Einfache Erklärung: Auf dieser _existierenden_ dritten Partition der eSATA-Platte gibt es keinen GRUB im Boot-Sektor, weshalb der ladende GRUB kein ausführbares Format erkennt. Im Grunde die gleiche Ursache.
Ich habe inzwischen das BIOS-Setup durchsucht, aber keine Möglichkeit gefunden, die eSATA-Platte bzw. den JMicron-Chipsatz in der Plattenreihenfolge nach hinten auf eine Fixposition zu schieben, so dass die Platte sich beim Booten nicht mehr vordrängelt. Hier scheint es kein Weiterkommen zu geben. Deshalb frage ich nochmal:
Siehe dazu meine andere Mail.
Worauf ich auch gleich antworte.
Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben.
Nein. Du könntest aber '(hd2,N)' Einträge ergänzen.
Habe ich auch schon daran gedacht, und für den Falle der eingesteckten eSATA-Platte funktioniert das als Workaround auch, aber es kommt eben auch vor, dass die eSATA-Platte beim Booten nicht eingesteckt ist. In dem Fall findet GRUB keine Partitionen (hd2,N), weil dann (hd1) die höchste Gerätenummer ist.
Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten.
Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen kannst. Wenn ich also einen bestimmten Kernel einer Distri sowieso bevorzugt starte, könnte ich den also auch in die menu.lst des MBR-GRUB schreiben und somit in der Regel einen Auswahlvorgang sparen. Hmmm, wenn nur alle Distris auf der SSD Platz hätten (wollte ihr deswegen nur die zwei wichtigsten aufladen), dann hätte ich dieses Problem nicht (aber auch nix Neues gelernt). Ein Workaround dafür wäre natürlich auch, nach der GRUB-Fehlermeldung den Affengriff machen und inzwischen die eSATA-Platte rausziehen. Könnte nur ein bisschen arg verschleißend auf die Stecker wirken. 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
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
Hallo David, David Haller schrieb:
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?
Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber nicht, nur als Meldung beim Booten.
Welches MoBo?
Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa speziell angefertigt für Targa).
Und an welchem Controller hängt die SSD und die externe Platte?
SSD: SATA-1, HDD: SATA-2, beide onboard am NVIDIA nForce 550 MCP. eSATA: JMicron JMB 363 Extra-Chip, aber auch onboard.
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
Wie bekomme ich dieses schöne Listing gleich wieder?
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'
user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 05:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03) 05:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03)
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
Leider heißt es: "Unfortunately, even OS device names are not always stable. Modern versions of the Linux kernel may probe drives in a different order from boot to boot, [...]. As a result, the device map file required frequent editing on some systems." Letzteres wohl nur, wenn man einen GRUB installieren will. Aber immerhin: "GRUB avoids this problem nowadays by using UUIDs or file system labels when generating grub.cfg, and we advise that you do the same for any custom menu entries you write." Das hat Boris wohl gemeint, das ich tun soll, gilt aber für GRUB 1.99. Nur schade, dass /dev/disk/by-id/... nicht erwähnt werden.
Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map denn eigentlich aus?
(fd0) /dev/fd0 (Controller gibt es wohl, aber kein Lw) (hd0) /dev/sda (war die eSATA-Platte !!!) (hd1) /dev/sdb (war die SDD !!!) (hd2) /dev/sdg (war die HDD !!!) Allerdings hat und musste sie so aussehen, als ich mittels SysRescueCD den GRUB im MBR und den Boot-Sektoren installiert habe, denn SysRescueCD hatte anscheinend eigene Vorstellungen von der Zuordnung der Geräte zu /dev/sdX (hier besonders für die HDD als 2. SATA-Platte). 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
Hallo, Ich fasse die Mails mal wieder zusammen ... Am Sat, 19 Feb 2011, Thomas Michalka schrieb:
David Haller schrieb:
Am Fri, 18 Feb 2011, Thomas Michalka schrieb: [..]
Wenn beim Booten schon die eSATA-Platte im Rechner steckt, dann kann ich durch Auswahl das erste eingetragene System (hd0,2) von der SSD booten, nicht aber die Systeme von der HDD (hd1,X). Ohne die eSATA-Platte geht das aber! Die GRUB-Fehlermeldung lautet ungefähr so:
"(hd1,8) Error 22: Partition not found"
Noch eine kleine Ergänzung: Diese Meldung kommt nur, wenn man ein System auf einer Partition wählt, die es auf der dazwischen gemogelten eSATA-Platte nicht gibt. Im Falle von (hd1,2) habe ich folgende Meldung:
"(hd1,2) Error 13: Invalid or unsupported executable format"
Einfache Erklärung: Auf dieser _existierenden_ dritten Partition der eSATA-Platte gibt es keinen GRUB im Boot-Sektor, weshalb der ladende GRUB kein ausführbares Format erkennt. Im Grunde die gleiche Ursache.
Korrekt erkannt :)
Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben.
Nein. Du könntest aber '(hd2,N)' Einträge ergänzen.
Habe ich auch schon daran gedacht, und für den Falle der eingesteckten eSATA-Platte funktioniert das als Workaround auch, aber es kommt eben auch vor, dass die eSATA-Platte beim Booten nicht eingesteckt ist. In dem Fall findet GRUB keine Partitionen (hd2,N), weil dann (hd1) die höchste Gerätenummer ist.
Ich meinte folgendes, wenn du z.B. meist ohne eSATA bootest: SSD-Eintrag hd1,6 Eintrag hd1,7 Eintrag hd2,6 Eintrag hd2,7 Eintrag D.h. im selteneren Fall mußt du halt weiter nach unten, aber es sollten sich alle booten lassen. Siehe dazu auch unten bzgl. device.map. Für die 'root=' Kernel-Parameter solltest du von sdXY unabhängige Varianten wählen, also /dev/disk/by-{label,id,uuid}.
Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten.
Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen kannst.
Nein, vielmehr, damit ich dann z.B. von DVD booten kann, und "per Hand" und chainloader den Grub in der root-Partition einer Distri starten kann, falls der im MBR mal nicht will. Und den Distri-Grub hab ich z.B. von Yast erstellen lassen, der im MBR wird (nach Vorlage im Distri-Grub) manuell gepflegt. Äh, so die Grundidee. Praktisch ist im Grub jetzt der SUSE-Grub, mit Eintrag für Gentoo, der Gentoo-Grub ist in dessen /-Partition und diente als Vorlage für den Grub im MBR.
Wenn ich also einen bestimmten Kernel einer Distri sowieso bevorzugt starte, könnte ich den also auch in die menu.lst des MBR-GRUB schreiben und somit in der Regel einen Auswahlvorgang sparen.
Genau. Und den "chainloader" Eintrag eben unten noch drinlassen, falls du mal was verbastelst und nicht direkt in der am grub-prompt reparieren kannst.
Hmmm, wenn nur alle Distris auf der SSD Platz hätten (wollte ihr deswegen nur die zwei wichtigsten aufladen), dann hätte ich dieses Problem nicht (aber auch nix Neues gelernt). Ein Workaround dafür wäre natürlich auch, nach der GRUB-Fehlermeldung den Affengriff machen und inzwischen die eSATA-Platte rausziehen. Könnte nur ein bisschen arg verschleißend auf die Stecker wirken.
s.o. Die paar Tastendrücke, um den hd2 statt hd1 Eintrag auszuwählen dürften da nervenschonender sein. [..]
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?
Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber nicht, nur als Meldung beim Booten.
Und sonst irgendwas mit "SATA0/SATA1" o.ä.? Wo man evtl. auch den SATA-Modus umstellen kann (IDE/AHCI)?
Welches MoBo?
Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa speziell angefertigt für Targa).
Kannst du mal auf asus.de gucken, welches Board deinem am ehesten ähnelt? Das M2N-SLI Deluxe sollte zumindest mal die gleichen Controller haben, da guck ich mal ins (engl.) Handbuch ... Guck im Bios unter "Boot" -> "Hard Disk Drives". Im Idealfall kannst du da umsortieren.
Und an welchem Controller hängt die SSD und die externe Platte?
SSD: SATA-1, HDD: SATA-2, beide onboard am NVIDIA nForce 550 MCP. eSATA: JMicron JMB 363 Extra-Chip, aber auch onboard.
Da ahci fest im Kernel ist und du bei eSATA zwingend ahci brauchst könntest du nur die Platten am MCP55 im IDE-Modus mit dem sata_nv Treiber verwenden -- aber gerade bei SSD willst du das nicht! Also, s.o.: BIOS oder Grub.
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 [..] Wie bekomme ich dieses schöne Listing gleich wieder?
Sehr überraschend mit 'lsscsi' ;)
user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
Äh, hast du die Onboard SATA im IDE oder AHCI Modus?
Nein: http://www.gnu.org/software/grub/manual/grub.html#Device-map
Leider heißt es: "Unfortunately, even OS device names are not always stable. Modern versions of the Linux kernel may probe drives in a different order from boot to boot, [...]. As a result, the device map file required frequent editing on some systems."
Letzteres wohl nur, wenn man einen GRUB installieren will.
Eben.
Aber immerhin: "GRUB avoids this problem nowadays by using UUIDs or file system labels when generating grub.cfg, and we advise that you do the same for any custom menu entries you write."
Das hat Boris wohl gemeint, das ich tun soll, gilt aber für GRUB 1.99. Nur schade, dass /dev/disk/by-id/... nicht erwähnt werden.
Bei beiden mappt Grub bei der Installation die /dev/* auf (hdX,Y).
Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map denn eigentlich aus?
(fd0) /dev/fd0 (Controller gibt es wohl, aber kein Lw) (hd0) /dev/sda (war die eSATA-Platte !!!) (hd1) /dev/sdb (war die SDD !!!) (hd2) /dev/sdg (war die HDD !!!)
Hm. Zeig mal (lsscsi, Modellnamen kannst du kürzen/ersetzen) wie's aktuell mit und ohne eSATA aussieht, denn daß die HDD als /dev/sdg auftauchte spräche dafür, daß die an nem anderen Controller hängt. Und dann basteln wir dir ne device.map, mit /dev/disk/by-* statt /dev/sdX. Evtl. klappt es, wenn du manuell dort die eSATA als hd2 definierst.
Allerdings hat und musste sie so aussehen, als ich mittels SysRescueCD den GRUB im MBR und den Boot-Sektoren installiert habe, denn SysRescueCD hatte anscheinend eigene Vorstellungen von der Zuordnung der Geräte zu /dev/sdX (hier besonders für die HDD als 2. SATA-Platte).
Ja, das kann wüst werden, wenn man mal hier und mal dort bootet. Hat mit bei der Installation von Gentoo auf ner externen USB Platte auch einiges an Zeit gekostet, in der SUSE war's /dev/sdk, im BIOS von USB-gebootet war's dann IIRC /dev/sdg, weil die Controller in anderer Reihenfolge auftauchten ... Und wenn man es wie ich zu dem Zeitpunkt im anderen Rechner mit 11 Platten an 3 Controllern (Onboard, Steckkarte, USB) zu tun hat kann die Suche nach dem richtigen Device für Grub einiges an Zeit und Nerven kosten ;) Es hilft, wenn man weiß, wie Grub funktioniert :) -dnh -- BE MAD! IT HELPS! -- 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
David Haller schrieb:
Hallo,
Ich fasse die Mails mal wieder zusammen ...
Kennt jemand eine Möglichkeit, wie man mit GRUB ein Gerät sozusagen ausblenden kann, so dass GRUB es seiner Geräteliste übergeht? GRUB sollte für die eSATA-Platte keine Gerätebezeichnung (hdX) vergeben. Nein. Du könntest aber '(hd2,N)' Einträge ergänzen. Habe ich auch schon daran gedacht, und für den Falle der eingesteckten eSATA-Platte funktioniert das als Workaround auch, aber es kommt eben auch vor, dass die eSATA-Platte beim Booten nicht eingesteckt ist. In dem Fall findet GRUB keine Partitionen (hd2,N), weil dann (hd1) die höchste Gerätenummer ist.
Ich meinte folgendes, wenn du z.B. meist ohne eSATA bootest:
SSD-Eintrag hd1,6 Eintrag hd1,7 Eintrag hd2,6 Eintrag hd2,7 Eintrag
Klick! Zusätzliche Einträge, die man ja auch entsprechend markieren ("plus eSATA" o.ä.) kann.
D.h. im selteneren Fall mußt du halt weiter nach unten, aber es sollten sich alle booten lassen. Siehe dazu auch unten bzgl. device.map. Für die 'root=' Kernel-Parameter solltest du von sdXY unabhängige Varianten wählen, also /dev/disk/by-{label,id,uuid}.
Das war mir schon bei der Installation sympathischer, was dann auch für die /etc/fstab gilt, die somit ebenfalls 'transportabler' ist.
Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten. Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen kannst.
Nein, vielmehr, damit ich dann z.B. von DVD booten kann, und "per Hand" und chainloader den Grub in der root-Partition einer Distri starten kann, falls der im MBR mal nicht will. Und den Distri-Grub hab ich z.B. von Yast erstellen lassen, der im MBR wird (nach Vorlage im Distri-Grub) manuell gepflegt. Äh, so die Grundidee. Praktisch ist im Grub jetzt der SUSE-Grub, mit Eintrag für Gentoo, der Gentoo-Grub ist in dessen /-Partition und diente als Vorlage für den Grub im MBR.
Eine nette Idee.
Wenn ich also einen bestimmten Kernel einer Distri sowieso bevorzugt starte, könnte ich den also auch in die menu.lst des MBR-GRUB schreiben und somit in der Regel einen Auswahlvorgang sparen.
Genau. Und den "chainloader" Eintrag eben unten noch drinlassen, falls du mal was verbastelst und nicht direkt in der am grub-prompt reparieren kannst.
Hmmm, wenn nur alle Distris auf der SSD Platz hätten (wollte ihr deswegen nur die zwei wichtigsten aufladen), dann hätte ich dieses Problem nicht (aber auch nix Neues gelernt). Ein Workaround dafür wäre natürlich auch, nach der GRUB-Fehlermeldung den Affengriff machen und inzwischen die eSATA-Platte rausziehen. Könnte nur ein bisschen arg verschleißend auf die Stecker wirken.
s.o. Die paar Tastendrücke, um den hd2 statt hd1 Eintrag auszuwählen dürften da nervenschonender sein.
Wow, werde wohl im Boot-Menü das erste Mal scrollen müssen ;-)
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? Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber nicht, nur als Meldung beim Booten.
Sorry, da hat mir die mangelhafte Erinnerung einen Streich gespielt, denn man kann ihn aktivieren/deaktivieren mit [DISABLED][IDE], wie mir das Handbuch zur BIOS-Konfiguration eben sagt. Aber mehr leider nicht. Zur Reihenfolge der Controller SATA (Anschlüsse 1 - 4) und JMicron (eSATA) sehe ich im BIOS leider keine Möglichkeit. Für SATA gibt es in der Chipsatz-Konfiguration noch die Option [SPREAD SPECTRUM], was immer das ist, leider nicht erläutert im Handbuch. Hat vielleicht was mit HyperTransport zu tun, weil es in dem Menu ansonsten darum zu gehen scheint.
Und sonst irgendwas mit "SATA0/SATA1" o.ä.? Wo man evtl. auch den SATA-Modus umstellen kann (IDE/AHCI)?
Leider nix. In der "Onboard Device Configuration" gibt es den "IDE Function Setup", der für den PATA-Anschluss (meine beiden IDE-DVD-Lw) zuständig ist. Dann ist da noch die "Serial ATA Configuration", wo ich nur den Controller an- und abschalten und ansonsten nur noch RAID für die einzelnen SATA-Anschlüsse konfigurieren kann.
Welches MoBo? Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa speziell angefertigt für Targa).
Kannst du mal auf asus.de gucken, welches Board deinem am ehesten ähnelt? Das M2N-SLI Deluxe sollte zumindest mal die gleichen Controller haben, da guck ich mal ins (engl.) Handbuch ... Guck im Bios unter "Boot" -> "Hard Disk Drives". Im Idealfall kannst du da umsortieren.
Hier habe ich die SSD an erster und die HDD an zweiter Stelle. Falls ich mich richtig erinnere, steht die eSATA-Platte an dritter Stelle, wenn sie eingebaut ist. Aber vielleicht steht sie auch gar nicht drin. Das sehe ich mir an und liefere die Info noch nach.
Und an welchem Controller hängt die SSD und die externe Platte? SSD: SATA-1, HDD: SATA-2, beide onboard am NVIDIA nForce 550 MCP. eSATA: JMicron JMB 363 Extra-Chip, aber auch onboard.
Da ahci fest im Kernel ist und du bei eSATA zwingend ahci brauchst könntest du nur die Platten am MCP55 im IDE-Modus mit dem sata_nv Treiber verwenden -- aber gerade bei SSD willst du das nicht!
Wenn ich den Wikipedia-Artikel zu AHCI richtig verstehe, ist nur mit AHCI-Treibern NCQ möglich. Was hat das mit der SSD zu tun? Naja, würde wohl elendslangsam werden, wie auch eine moderne SATA-HDD (erinnere mich da an ein c't-Plattenkarussell). NB: hat das auch irgendwas mit ATA-Trim zu tun und mit wiper.sh aus dem hdparm-Paket? (Habe noch Kernel 2.6.25, wohl ohne TRIM Support.) Habe allerdings noch recht viel Platz auf meiner SSD unpartitioniert.
Also, s.o.: BIOS oder Grub.
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 [..] Wie bekomme ich dieses schöne Listing gleich wieder?
Sehr überraschend mit 'lsscsi' ;)
Habe mich dunkel erinnert, aber nicht genau und weil lspci in /sbin steht, nur mit "ls /sbin/ls* nachgesehen. Hier also meine SCSI-Geräte: rechner:~ # lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg (eSATA) [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda (SSD) [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb (HDD) [8:0:0:0] cd/dvd TOSHIBA DVD/HD SD-H802A TS06 - [8:0:1:0] cd/dvd Optiarc DVD RW AD-7191A 1.02 - [10:0:0:0] disk Generic STORAGE DEVICE 9602 /dev/sdc [10:0:0:1] disk Generic STORAGE DEVICE 9602 /dev/sdd [10:0:0:2] disk Generic STORAGE DEVICE 9602 /dev/sde [10:0:0:3] disk Generic STORAGE DEVICE 9602 /dev/sdf Wenn ich die eSATA-Platte entferne fehlt kurz darauf nur der Eintrag [3:0:0:0], um wieder da zu sein, wenn sie wieder drinsteckt. Sie wird also nicht einfach angereiht, sonst würde ich [6:0:0:0] oder [7:0:0:0] erwarten. Kann hier die niedrigste SCSI-Nummer der eSATA-Platte für GRUB bedeuten, dass der JMC 363 immer ganz vorne steht (trotz "Boot Device Priority" für SSD und Hard Disk Drives Reihenfolge SSD, HDD, eSATA-Platte) und daher in der menu.lst für die SSD immer (hd1), für die HDD immer (hd2) einzutragen wäre? Dann verstünde ich allerdings nicht, warum ich mit "chainloader (hd0,2)+1" aus dem MBR der SSD _immer_ die Distri auf der SSD booten kann, egal ob die eSATA-Platte drin ist oder nicht. Nur die Distris auf der HDD kann ich ja mal booten oder nicht.
user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
Äh, hast du die Onboard SATA im IDE oder AHCI Modus?
Da nichts im BIOS einzustellen ist (s.o.), tippe ich auf AHCI.
Das hat Boris wohl gemeint, das ich tun soll, gilt aber für GRUB 1.99. Nur schade, dass /dev/disk/by-id/... nicht erwähnt werden.
Bei beiden mappt Grub bei der Installation die /dev/* auf (hdX,Y).
Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map denn eigentlich aus? (fd0) /dev/fd0 (Controller gibt es wohl, aber kein Lw) (hd0) /dev/sda (war die eSATA-Platte !!!) (hd1) /dev/sdb (war die SDD !!!) (hd2) /dev/sdg (war die HDD !!!)
Hm. Zeig mal (lsscsi, Modellnamen kannst du kürzen/ersetzen) wie's aktuell mit und ohne eSATA aussieht, denn daß die HDD als /dev/sdg auftauchte spräche dafür, daß die an nem anderen Controller hängt.
Ausgabe von lsscsi siehe oben. Es ist aber doch anders und wird auch, wie ich in einem früheren Posting etwas unauffällig erwähnte, durch eine Anzeige des JMicron-Controllers beim Booten erwähnt: da steht ohne eSATA-Platte nix drin, mit der eSATA-Platte wird der Modellname der WDC-Platte blau angezeigt. Warum in der device.map die HDD (!) als /dev/sdg steht, ist mir jetzt auch nicht klar. Vielleicht resultiert das aus einer etwas eigenwilligen Vergabe der Gerätebezeichner unter der SysRescueCD -- muss ich beim nächsten Booten auch noch ausprobieren.
Und dann basteln wir dir ne device.map, mit /dev/disk/by-* statt /dev/sdX. Evtl. klappt es, wenn du manuell dort die eSATA als hd2 definierst.
Das probiere ich beim nächsten Booten auch gleich aus (muss vorher aber ein paar dringende Arbeiten erledigen). Hmm, aber jetzt mal überlegen: das hieße doch, dass beim Schreiben des GRUB in den MBR schon die Gerätenummern (hdX) in den MBR mit eingetragen würden. Wozu muss er dann die menu.lst lesen? Auf dem Lesen der menu.lst beruhte doch Dein Vorschlag der zusätzlichen Einträge (hd2,Y) für den Fall des Bootens mit eSATA-Platte. Liest GRUB vor dem Booten auch die device.map, so dass diese zur Boot-Zeit auch relevant ist (dachte immer, die braucht nur grub-install, wenn man die üblichen Gerätebezeichner /dev/sdXy verwendet)? Noch etwas, worüber ich nichts genaues gefunden habe: wie erhält GRUB eigentlich die Infos über die Geräte? Durch Parameterübergabe beim Start durch das BIOS, oder liest GRUB selber ein BIOS-Register, oder kann GRUB die Gerätereihenfolge gar selber festlegen? Ich denke, das müsste ich mal verstehen.
Allerdings hat und musste sie so aussehen, als ich mittels SysRescueCD den GRUB im MBR und den Boot-Sektoren installiert habe, denn SysRescueCD hatte anscheinend eigene Vorstellungen von der Zuordnung der Geräte zu /dev/sdX (hier besonders für die HDD als 2. SATA-Platte).
Ja, das kann wüst werden, wenn man mal hier und mal dort bootet. Hat mit bei der Installation von Gentoo auf ner externen USB Platte auch einiges an Zeit gekostet, in der SUSE war's /dev/sdk, im BIOS von USB-gebootet war's dann IIRC /dev/sdg, weil die Controller in anderer Reihenfolge auftauchten ... Und wenn man es wie ich zu dem Zeitpunkt im anderen Rechner mit 11 Platten an 3 Controllern (Onboard, Steckkarte, USB) zu tun hat kann die Suche nach dem richtigen Device für Grub einiges an Zeit und Nerven kosten ;) Es hilft, wenn man weiß, wie Grub funktioniert :)
Ja eben, das scheint mir der springende Punkt zu sein! Ich dachte, das hätte ich schon verstanden ... Aber wohl noch nicht tief genug, siehe dazu meine Fragen oben. Kurz zu grub-install[.unsupported] ([] bei oS): die Option --recheck braucht man ja, damit man als Schreibziel für GRUB den _aktuell_richtigen_ MBR (/dev/sdX) bzw. den _aktuell_richtigen_ Boot-Sektor (/dev/sdXy) angibt. Selbst wenn man später ein System von (hd0,2) starten will, kann beim Schreiben des MBR das Ziel (hd1 <--> /dev/sdb) sein. Dann wäre aber die device.map später für's Booten egal. Also, ich glaube, dass für eine Lösung das Verständnis die 'Laufwerkswahrnehmung' durch GRUB (absichtlich etwas unbestimmt) entscheidend ist, und wie diese evtl. mit den SCSI-Gerätenummern zusammenhängt. 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
Hallo, Am Mon, 21 Feb 2011, Thomas Michalka schrieb:
David Haller schrieb: [..]
Ich meinte folgendes, wenn du z.B. meist ohne eSATA bootest:
SSD-Eintrag hd1,6 Eintrag hd1,7 Eintrag hd2,6 Eintrag hd2,7 Eintrag
Klick! Zusätzliche Einträge, die man ja auch entsprechend markieren ("plus eSATA" o.ä.) kann.
Genau ;) Ob das klappt kann ich nicht vorhersagen. Es erstmal zu probieren braucht ja nur einen Reboot ;)
D.h. im selteneren Fall mußt du halt weiter nach unten, aber es sollten sich alle booten lassen. Siehe dazu auch unten bzgl. device.map. Für die 'root=' Kernel-Parameter solltest du von sdXY unabhängige Varianten wählen, also /dev/disk/by-{label,id,uuid}.
Das war mir schon bei der Installation sympathischer, was dann auch für die /etc/fstab gilt, die somit ebenfalls 'transportabler' ist.
Achso, by-path hab ich noch vergessen, das ist evtl. grad für die Systemplatte interessant, ich hab hier z.B. alles _außer_ der Systemplatte "by-label", die Systemplatte als /dev/sda (menu.lst, root= Kernel-Parameter, fstab). Grund (hat sich schon bewährt): Ich kann die Installation(en) einfach auf ne neue Festplatte umziehen, und muß nur dafür sorgen, das die Systemplatte eben am SATA0 des ersten Controllers hängt, mit SATA ist umkabeln ja kein Problem mehr.
Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten. Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen kannst.
Nein, vielmehr, damit ich dann z.B. von DVD booten kann, und "per Hand" und chainloader den Grub in der root-Partition einer Distri starten kann, falls der im MBR mal nicht will. Und den Distri-Grub hab ich z.B. von Yast erstellen lassen, der im MBR wird (nach Vorlage im Distri-Grub) manuell gepflegt. Äh, so die Grundidee. Praktisch ist im Grub jetzt der SUSE-Grub, mit Eintrag für Gentoo, der Gentoo-Grub ist in dessen /-Partition und diente als Vorlage für den Grub im MBR.
Eine nette Idee.
Jep :) Z.Z. hier halt in der Variante daß MBR-Grub == SUSE-Grub, wobei letzterer aber zusätzlich auch in der SUSE-/-Partition installiert ist (und im Gentoo-Grub hab ich da wiederum einen chainloader): ==== /boot/grub/menu.lst für SUSE/MBR-Grub === default 0 timeout 8 title openSUSE 11.2 - 2.6.31.14-0.6 root (hd0,5) kernel /boot/vmlinuz-2.6.31.14-0.6-default root=/dev/sda6 noresume splash=native showopts edd=off pcsp=enable=1 elevator=anticipatory vga=normal initrd /boot/initrd-2.6.31.14-0.6-default title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd] root (hd0,2) kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 init=/linuxrc ramdisk=8192 initrd /boot/initrd-2.6.31-dnh2.cpio.gz title Gentoo GRUB chainloader (hd0,2)+1 [.. diverse failsafe / backup Einträge ..] ==== /Gentoo/boot/grub/menu.lst (Gentoo-GRUB in /dev/sda3 ==== default 0 timeout 8 title openSUSE root (hd0,5) kernel /boot/vmlinuz root=/dev/disk/by-label/SUSE_ROOT noresume splash=native showopts edd=off vga=795 initrd /boot/initrd title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd] root (hd0,2) kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 init=/linuxrc ramdisk=8192 initrd /boot/initrd-2.6.31-dnh2.cpio.gz title openSUSE GRUB chainloader (hd0,5)+1 [.. diverse failsafe / backup Einträge ..] ==== Ich denke, so wird die Idee noch klarer ;)
Wow, werde wohl im Boot-Menü das erste Mal scrollen müssen ;-)
*hihi* Achso, ich hab da keinerlei Grafikgedöns (wozu??), nur Schwarz auf Weiß (s.o.), da passen locker 8 Einträge hin.
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? Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber nicht, nur als Meldung beim Booten.
Sorry, da hat mir die mangelhafte Erinnerung einen Streich gespielt, denn man kann ihn aktivieren/deaktivieren mit [DISABLED][IDE], wie mir das Handbuch zur BIOS-Konfiguration eben sagt. Aber mehr leider nicht.
Seltsam (daß es da kein [AHCI] oder [RAID] gibt).
Zur Reihenfolge der Controller SATA (Anschlüsse 1 - 4) und JMicron (eSATA) sehe ich im BIOS leider keine Möglichkeit.
s.u.
Für SATA gibt es in der Chipsatz-Konfiguration noch die Option [SPREAD SPECTRUM], was immer das ist, leider nicht erläutert im Handbuch. Hat vielleicht was mit HyperTransport zu tun, weil es in dem Menu ansonsten darum zu gehen scheint.
Das "Spread Spectrum" bezieht sich AFAIK auf die Art, wie die SATA-Übertragung auf die Frequenzen verteilt wird um Störungen zu vermindern. Siehe http://en.wikipedia.org/wiki/Spread_Spectrum.
Und sonst irgendwas mit "SATA0/SATA1" o.ä.? Wo man evtl. auch den SATA-Modus umstellen kann (IDE/AHCI)?
Leider nix. In der "Onboard Device Configuration" gibt es den "IDE Function Setup", der für den PATA-Anschluss (meine beiden IDE-DVD-Lw) zuständig ist. Dann ist da noch die "Serial ATA Configuration", wo ich nur den Controller an- und abschalten und ansonsten nur noch RAID für die einzelnen SATA-Anschlüsse konfigurieren kann.
Ok.
Welches MoBo? Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa speziell angefertigt für Targa).
Kannst du mal auf asus.de gucken, welches Board deinem am ehesten ähnelt? Das M2N-SLI Deluxe sollte zumindest mal die gleichen Controller haben, da guck ich mal ins (engl.) Handbuch ... Guck im Bios unter "Boot" -> "Hard Disk Drives". Im Idealfall kannst du da umsortieren.
Hier habe ich die SSD an erster und die HDD an zweiter Stelle. Falls ich mich richtig erinnere, steht die eSATA-Platte an dritter Stelle, wenn sie eingebaut ist. Aber vielleicht steht sie auch gar nicht drin. Das sehe ich mir an und liefere die Info noch nach.
Teste das mal wenn du mit eSATA dran bootest und ins BIOS gehst. Ah, könnte evtl. auch als "Removable Device" o.ä. in ner anderen Rubrik (also nicht unter "Hard Disk Drives") auftauchen. Jedenfalls müßte daß die Stelle sein, an der du drehen kannst.
Und an welchem Controller hängt die SSD und die externe Platte? SSD: SATA-1, HDD: SATA-2, beide onboard am NVIDIA nForce 550 MCP. eSATA: JMicron JMB 363 Extra-Chip, aber auch onboard.
Da ahci fest im Kernel ist und du bei eSATA zwingend ahci brauchst könntest du nur die Platten am MCP55 im IDE-Modus mit dem sata_nv Treiber verwenden -- aber gerade bei SSD willst du das nicht!
Wenn ich den Wikipedia-Artikel zu AHCI richtig verstehe, ist nur mit AHCI-Treibern NCQ möglich.
Genau.
Was hat das mit der SSD zu tun? Naja, würde wohl elendslangsam werden, wie auch eine moderne SATA-HDD (erinnere mich da an ein c't-Plattenkarussell).
Naja, nicht elendslahm. Und ja, ...
NB: hat das auch irgendwas mit ATA-Trim zu tun und mit wiper.sh aus dem hdparm-Paket? (Habe noch Kernel 2.6.25, wohl ohne TRIM Support.) Habe allerdings noch recht viel Platz auf meiner SSD unpartitioniert.
AFAIR war da mal was in nem Plattenkarusell ;)
Habe mich dunkel erinnert, aber nicht genau und weil lspci in /sbin steht, nur mit "ls /sbin/ls* nachgesehen. Hier also meine SCSI-Geräte:
rechner:~ # lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg (eSATA) [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda (SSD) [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb (HDD) [8:0:0:0] cd/dvd TOSHIBA DVD/HD SD-H802A TS06 - [8:0:1:0] cd/dvd Optiarc DVD RW AD-7191A 1.02 - [10:0:0:0] disk Generic STORAGE DEVICE 9602 /dev/sdc [10:0:0:1] disk Generic STORAGE DEVICE 9602 /dev/sdd [10:0:0:2] disk Generic STORAGE DEVICE 9602 /dev/sde [10:0:0:3] disk Generic STORAGE DEVICE 9602 /dev/sdf
Hast du hier mit eSATA dran gebootet oder erst anschließen angestöpselt?
Wenn ich die eSATA-Platte entferne fehlt kurz darauf nur der Eintrag [3:0:0:0], um wieder da zu sein, wenn sie wieder drinsteckt. Sie wird also nicht einfach angereiht, sonst würde ich [6:0:0:0] oder [7:0:0:0] erwarten.
Das sieht hingegen wiederum so aus, als würde es nicht am BIOS liegen, denn dann müßte die eSATA /dev/sda bekommen. Zeig mal (per PM / paste.opensuse.org), ein 'lsmod' mit eSATA, im Idealfall auch mal wenn du die eSATA erst nach dem booten anschließt.
Kann hier die niedrigste SCSI-Nummer der eSATA-Platte für GRUB bedeuten, dass der JMC 363 immer ganz vorne steht (trotz "Boot Device Priority" für SSD und Hard Disk Drives Reihenfolge SSD, HDD, eSATA-Platte) und daher in der menu.lst für die SSD immer (hd1), für die HDD immer (hd2) einzutragen wäre?
Ich glaube eher leider nicht. Probier's aber (bzw. vergleiche lsscsi wenn du mit eSATA bootest mit nachträglich angesteckt).
Dann verstünde ich allerdings nicht, warum ich mit "chainloader (hd0,2)+1" aus dem MBR der SSD _immer_ die Distri auf der SSD booten kann, egal ob die eSATA-Platte drin ist oder nicht. Nur die Distris auf der HDD kann ich ja mal booten oder nicht.
Liegt vermutlich an der device.map, mit der dein Grub installiert wurde. Und daran, daß du von SSD bootest (-> BIOS Bootreihenfolge!) und üblicherweise macht das BIOS das Boot-Device zum BIOS-INT13 Gerät 0x80 was eben genau '(hd0)' beim Grub entspricht. Hab ich zuletzt gemerkt, als ich mal von ner USB-Platte gebootet habe (da war die dann auf einmal /dev/sda). Wie das BIOS dann die restlichen Sachen durcheinanderwürfelt mußt du schauen ...
user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
Äh, hast du die Onboard SATA im IDE oder AHCI Modus?
Da nichts im BIOS einzustellen ist (s.o.), tippe ich auf AHCI.
lsmod ;) Wenn da nix auftaucht ist's ahci (der ist fest im Kernel, sata_nv aber nicht).
Das hat Boris wohl gemeint, das ich tun soll, gilt aber für GRUB 1.99. Nur schade, dass /dev/disk/by-id/... nicht erwähnt werden.
Bei beiden mappt Grub bei der Installation die /dev/* auf (hdX,Y).
Auch Grub2 braucht erstmal noch das BIOS. Wie schaut deine device.map denn eigentlich aus? (fd0) /dev/fd0 (Controller gibt es wohl, aber kein Lw) (hd0) /dev/sda (war die eSATA-Platte !!!) (hd1) /dev/sdb (war die SDD !!!) (hd2) /dev/sdg (war die HDD !!!) [..] Und dann basteln wir dir ne device.map, mit /dev/disk/by-* statt /dev/sdX. Evtl. klappt es, wenn du manuell dort die eSATA als hd2 definierst.
Das probiere ich beim nächsten Booten auch gleich aus (muss vorher aber ein paar dringende Arbeiten erledigen). Hmm, aber jetzt mal überlegen: das hieße doch, dass beim Schreiben des GRUB in den MBR schon die Gerätenummern (hdX) in den MBR mit eingetragen würden. Wozu muss er dann die menu.lst lesen? Auf dem Lesen der menu.lst beruhte doch Dein Vorschlag der zusätzlichen Einträge (hd2,Y) für den Fall des Bootens mit eSATA-Platte. Liest GRUB vor dem Booten auch die device.map, so dass diese zur Boot-Zeit auch relevant ist (dachte immer, die braucht nur grub-install, wenn man die üblichen Gerätebezeichner /dev/sdXy verwendet)?
Nein. Grub liest bei der Installation die device.map und nimmt so ein Mapping von /dev/sd* auf BIOS-Devices (hdX) vor. AFAIK wird nur dieses Mapping (BIOS- zu Grub-Device) und auf welcher Platte+Partition die menu.lst liegt mit "installiert", d.h. in den (M)BR bzw. den darauffolgenden Teil von Grub (stage1.5 mit den Dateisystemtreibern) geschrieben. Den ganzen Rest (kernel, Parameter, initrd usw.) liest Grub dann schon aus der menu.lst, deswegen muß man Grub ja auch nicht installieren, wenn man die menu.lst ändert. Aber wenn sich der Ort der menu.lst ändert (z.B. weil man /boot auf ne eigene Partition auslagern will oder von so einer auf die /-Partition holt).
Noch etwas, worüber ich nichts genaues gefunden habe: wie erhält GRUB eigentlich die Infos über die Geräte? Durch Parameterübergabe beim Start durch das BIOS, oder liest GRUB selber ein BIOS-Register, oder kann GRUB die Gerätereihenfolge gar selber festlegen? Ich denke, das müsste ich mal verstehen.
s.o. AFAIK verwendet Grub im Stage 1 und 1.5 den BIOS INT13(e) Befehl, d.h. die Platten werden über feste Nummern (Diskette: 0x00 und 0x01, Festplatten 0x80 ..) angesprochen. In Assembler sieht das in DOS debug.com so aus: C:> debug -a100 ## DEBUG: assemble ab Adr. 0x0100 [SEG]:0100 mov ax,0201 ## 0x02 = read, 0x01 = Anz. Sektoren [SEG]:0103 mov bx,1000 ## Zieladresse im Speicher für Sektor [SEG]:0106 mov cx,0001 ## CS der CHS Adresse (10+6 bit!) [SEG]:0109 mov dx,0080 ## 0x00 = Head (CHS), 0x80 = erste Festplatte! [SEG]:010C int 13 ## INT13 BIOS-Funktion aufrufen [SEG]:010E ## -g100,10e ## DEBUG: :0100 bis :010e ausführen [..] -d11be l42 ## DEBUG: display 0x42 Bytes ab Adr. 0x11be Das würde z.B. den MBR lesen und die Partitionstabelle (DOS-Schema, nicht GPT) anzeigen. Quelle: c't 5/97, Seite 188. Hm. Muß ich mal in ner VM wieder ausprobieren ;)
Ja, das kann wüst werden, wenn man mal hier und mal dort bootet. Hat mit bei der Installation von Gentoo auf ner externen USB Platte auch einiges an Zeit gekostet, in der SUSE war's /dev/sdk, im BIOS von USB-gebootet war's dann IIRC /dev/sdg, weil die Controller in anderer Reihenfolge auftauchten ... Und wenn man es wie ich zu dem Zeitpunkt im anderen Rechner mit 11 Platten an 3 Controllern (Onboard, Steckkarte, USB) zu tun hat kann die Suche nach dem richtigen Device für Grub einiges an Zeit und Nerven kosten ;) Es hilft, wenn man weiß, wie Grub funktioniert :)
Ja eben, das scheint mir der springende Punkt zu sein! Ich dachte, das hätte ich schon verstanden ... Aber wohl noch nicht tief genug, siehe dazu meine Fragen oben.
Es ist auch nicht einfach, und je nach BIOS ...
Kurz zu grub-install[.unsupported] ([] bei oS): die Option --recheck braucht man ja, damit man als Schreibziel für GRUB den _aktuell_richtigen_ MBR (/dev/sdX) bzw. den _aktuell_richtigen_ Boot-Sektor (/dev/sdXy) angibt.
Nein. --recheck erzeugt nur erst die device.map neu. Kannst du machen, wenn du grub-install.unsupported --recheck /dev/sda verwendest. Und dann die device.map angucken / korrigieren und dann nochmal grub-install ohne --recheck aufrufen.
Selbst wenn man später ein System von (hd0,2) starten will, kann beim Schreiben des MBR das Ziel (hd1 <--> /dev/sdb) sein. Dann wäre aber die device.map später für's Booten egal.
Ist sie immer :)
Also, ich glaube, dass für eine Lösung das Verständnis die 'Laufwerkswahrnehmung' durch GRUB (absichtlich etwas unbestimmt) entscheidend ist, und wie diese evtl. mit den SCSI-Gerätenummern zusammenhängt.
Eher damit, wie grub die Devices vom BIOS serviert bekommt und ob das dann zur device.map _bei der Installation von Grub_ in den BR noch zusammenpasst. Eigentlich sollte sich die eSATA nicht zwischen SSD und HDD drängeln, wenn du immer von SSD bootest. Kannst du nochmal die Boot-Reihenfolge im BIOS angucken? -dnh -- Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo David, David Haller schrieb:
Hallo,
Am Mon, 21 Feb 2011, Thomas Michalka schrieb:
David Haller schrieb: [..]
Ich meinte folgendes, wenn du z.B. meist ohne eSATA bootest:
SSD-Eintrag hd1,6 Eintrag hd1,7 Eintrag hd2,6 Eintrag hd2,7 Eintrag Klick! Zusätzliche Einträge, die man ja auch entsprechend markieren ("plus eSATA" o.ä.) kann.
Genau ;) Ob das klappt kann ich nicht vorhersagen. Es erstmal zu probieren braucht ja nur einen Reboot ;)
Einen Versuch ist es wert :-)
D.h. im selteneren Fall mußt du halt weiter nach unten, aber es sollten sich alle booten lassen. Siehe dazu auch unten bzgl. device.map. Für die 'root=' Kernel-Parameter solltest du von sdXY unabhängige Varianten wählen, also /dev/disk/by-{label,id,uuid}. Das war mir schon bei der Installation sympathischer, was dann auch für die /etc/fstab gilt, die somit ebenfalls 'transportabler' ist.
Achso, by-path hab ich noch vergessen, das ist evtl. grad für die Systemplatte interessant, ich hab hier z.B. alles _außer_ der Systemplatte "by-label", die Systemplatte als /dev/sda (menu.lst, root= Kernel-Parameter, fstab). Grund (hat sich schon bewährt): Ich kann die Installation(en) einfach auf ne neue Festplatte umziehen, und muß nur dafür sorgen, das die Systemplatte eben am SATA0 des ersten Controllers hängt, mit SATA ist umkabeln ja kein Problem mehr.
Das geht aber auch mit "by-id" als absolute und immer gültige Angabe. Ich habe bei mir jetzt mal folgendes festgestellt: SSD einmal an SATA-1 (Zählung fängt bei meinem BIOS bei 1 an), das andere Mal an SATA-3 (HDD jeweils +1). Sofern die SSD im Boot-Menü des BIOS als erste unter den "Hard Disk Drives" eingetragen ist (und die Boot Device Priority auf [Hard Disk] steht), ist es egal an welchen Anschlüssen die SSD und die HDD sitzen. Wenn dazu noch die HDD mit den anderen Distris als zweite unter "Hard Disk Drives" steht, kann ich beiden Fällen alle Distris booten. Was ich jetzt nicht weiß, ob ich dazwischen GRUB neu installiert habe. Jedenfalls übermittelt das BIOS dem GRUB anscheinend die 'richtige' Laufwerkskonstellation (auch wenn es mit eSATA für mich leider nicht die richtige ist).
Ich hab übrigens hier auch die Distri-Grubs drin, aber im MBR erst die Einträge um die jew. Distri direkt zu starten (aus den Distri-menu.lst kopiert) und danach noch die Chainloader Einträge um ggfs. den Distri-Grub zu starten. Damit du hin- und wieder doch noch einen anderen Distri-Kernel auswählen kannst. Nein, vielmehr, damit ich dann z.B. von DVD booten kann, und "per Hand" und chainloader den Grub in der root-Partition einer Distri starten kann, falls der im MBR mal nicht will. Und den Distri-Grub hab ich z.B. von Yast erstellen lassen, der im MBR wird (nach Vorlage im Distri-Grub) manuell gepflegt. Äh, so die Grundidee. Praktisch ist im Grub jetzt der SUSE-Grub, mit Eintrag für Gentoo, der Gentoo-Grub ist in dessen /-Partition und diente als Vorlage für den Grub im MBR. Eine nette Idee.
Jep :) Z.Z. hier halt in der Variante daß MBR-Grub == SUSE-Grub, wobei letzterer aber zusätzlich auch in der SUSE-/-Partition installiert ist (und im Gentoo-Grub hab ich da wiederum einen chainloader):
==== /boot/grub/menu.lst für SUSE/MBR-Grub === default 0 timeout 8
title openSUSE 11.2 - 2.6.31.14-0.6 root (hd0,5) kernel /boot/vmlinuz-2.6.31.14-0.6-default root=/dev/sda6 noresume splash=native showopts edd=off pcsp=enable=1 elevator=anticipatory vga=normal initrd /boot/initrd-2.6.31.14-0.6-default
title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd] root (hd0,2) kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 init=/linuxrc ramdisk=8192 initrd /boot/initrd-2.6.31-dnh2.cpio.gz
title Gentoo GRUB chainloader (hd0,2)+1
[.. diverse failsafe / backup Einträge ..] ==== /Gentoo/boot/grub/menu.lst (Gentoo-GRUB in /dev/sda3 ==== default 0 timeout 8
title openSUSE root (hd0,5) kernel /boot/vmlinuz root=/dev/disk/by-label/SUSE_ROOT noresume splash=native showopts edd=off vga=795 initrd /boot/initrd
title=Gentoo Linux (2.6.31-gentoo-r10) [own initrd] root (hd0,2) kernel /boot/kernel root=/dev/ram0 real_root=/dev/sda3 splash=native vga=791 init=/linuxrc ramdisk=8192 initrd /boot/initrd-2.6.31-dnh2.cpio.gz
title openSUSE GRUB chainloader (hd0,5)+1
[.. diverse failsafe / backup Einträge ..] ====
Ich denke, so wird die Idee noch klarer ;)
Yeah!
Wow, werde wohl im Boot-Menü das erste Mal scrollen müssen ;-)
*hihi*
Achso, ich hab da keinerlei Grafikgedöns (wozu??), nur Schwarz auf Weiß (s.o.), da passen locker 8 Einträge hin.
Klar, das sehe ich ja an meiner Kernelauswahl bei openSuSE: drei für normalen Betrieb, drei für eine Failsafe-Situation und noch zwei, an die ich mich -- bei der Gesamtmenge wohl verständlich ;-) -- nicht erinnere. Weiß auch nicht, wozu ich soviele Failsafe-Einträge brauche ... muss bald mal aufräumen ;-)
> 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? Seltsamerweise sehe ich den JMicron-Controller im BIOS-Setup selber nicht, nur als Meldung beim Booten. Sorry, da hat mir die mangelhafte Erinnerung einen Streich gespielt, denn man kann ihn aktivieren/deaktivieren mit [DISABLED][IDE], wie mir das Handbuch zur BIOS-Konfiguration eben sagt. Aber mehr leider nicht.
Seltsam (daß es da kein [AHCI] oder [RAID] gibt).
Dass es keine Einstellung [AHCI/DISBLED] gibt, liegt wohl an der abgespeckten Spezial-Firmware für Targa. Aber bei "Serial-ATA Configuration" kann man schon RAID einschalten und dann wiederum jeden einzelnen SATA-Anschluss, nicht aber beim JMicron JMB363 Controller, den man nur ein-/ausschalten kann [DISABLED/IDE] -- trotz der Behauptung des MB-Manual, es sei ein Serial ATA *RAID* Controller (wohl richtig für SATA-Port-Multiplier, aber das Handbuch stimmt in einigen Details nicht so ganz).
Zur Reihenfolge der Controller SATA (Anschlüsse 1 - 4) und JMicron (eSATA) sehe ich im BIOS leider keine Möglichkeit.
Das war ein Missverständnis meinerseits: natürlich kann ich nicht die Reihenfolge der SATA-Anschlüsse verändern, aber im Menü "Boot" in "Hard Disk Drives" die Reihenfolge der Drives (siehe auch in meinem nächsten Absatz).
Welches MoBo? Ein Asus M2N-TE (hat es frei zu kaufen wohl nie gegeben, da laut Targa speziell angefertigt für Targa). Kannst du mal auf asus.de gucken, welches Board deinem am ehesten ähnelt? Das M2N-SLI Deluxe sollte zumindest mal die gleichen Controller haben, da guck ich mal ins (engl.) Handbuch ... Guck im Bios unter "Boot" -> "Hard Disk Drives". Im Idealfall kannst du da umsortieren. Hier habe ich die SSD an erster und die HDD an zweiter Stelle. Falls ich mich richtig erinnere, steht die eSATA-Platte an dritter Stelle, wenn sie eingebaut ist. Aber vielleicht steht sie auch gar nicht drin. Das sehe ich mir an und liefere die Info noch nach.
Teste das mal wenn du mit eSATA dran bootest und ins BIOS gehst. Ah, könnte evtl. auch als "Removable Device" o.ä. in ner anderen Rubrik (also nicht unter "Hard Disk Drives") auftauchen.
Nein, daran erinnere ich mich jetzt: es steht nicht unter den "Removables", wie z.B. USB-Sticks, sondern unter "Hard Disk Drives" im Menü "Boot". Und da habe ich es ganz bewusst an der letzten Stelle einsortiert.
Jedenfalls müßte daß die Stelle sein, an der du drehen kannst.
Wenn ich wieder reboote, sehe ich mir das Menü mit und ohne eSATA-Platte trotz meiner jetzt klaren Erinnerung nochmal ganz genau an. [...]
rechner:~ # lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg (eSATA) [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda (SSD) [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb (HDD) [8:0:0:0] cd/dvd TOSHIBA DVD/HD SD-H802A TS06 - [8:0:1:0] cd/dvd Optiarc DVD RW AD-7191A 1.02 - [10:0:0:0] disk Generic STORAGE DEVICE 9602 /dev/sdc [10:0:0:1] disk Generic STORAGE DEVICE 9602 /dev/sdd [10:0:0:2] disk Generic STORAGE DEVICE 9602 /dev/sde [10:0:0:3] disk Generic STORAGE DEVICE 9602 /dev/sdf
Hast du hier mit eSATA dran gebootet oder erst anschließen angestöpselt?
Ich glaube mit der eSATA-Platte. Muss ich aber noch mal probieren.
Wenn ich die eSATA-Platte entferne fehlt kurz darauf nur der Eintrag [3:0:0:0], um wieder da zu sein, wenn sie wieder drinsteckt. Sie wird also nicht einfach angereiht, sonst würde ich [6:0:0:0] oder [7:0:0:0] erwarten.
Das sieht hingegen wiederum so aus, als würde es nicht am BIOS liegen, denn dann müßte die eSATA /dev/sda bekommen. Zeig mal (per PM / paste.opensuse.org), ein 'lsmod' mit eSATA, im Idealfall auch mal wenn du die eSATA erst nach dem booten anschließt.
Siehe unten, aber momentan nur ohne Reboot.
Kann hier die niedrigste SCSI-Nummer der eSATA-Platte für GRUB bedeuten, dass der JMC 363 immer ganz vorne steht (trotz "Boot Device Priority" für SSD und Hard Disk Drives Reihenfolge SSD, HDD, eSATA-Platte) und daher in der menu.lst für die SSD immer (hd1), für die HDD immer (hd2) einzutragen wäre?
Ich glaube eher leider nicht. Probier's aber (bzw. vergleiche lsscsi wenn du mit eSATA bootest mit nachträglich angesteckt).
Ok.
Dann verstünde ich allerdings nicht, warum ich mit "chainloader (hd0,2)+1" aus dem MBR der SSD _immer_ die Distri auf der SSD booten kann, egal ob die eSATA-Platte drin ist oder nicht. Nur die Distris auf der HDD kann ich ja mal booten oder nicht.
Liegt vermutlich an der device.map, mit der dein Grub installiert wurde. Und daran, daß du von SSD bootest (-> BIOS Bootreihenfolge!)
Ich glaube nur an Letzterem.
und üblicherweise macht das BIOS das Boot-Device zum BIOS-INT13 Gerät 0x80 was eben genau '(hd0)' beim Grub entspricht. Hab ich zuletzt gemerkt, als ich mal von ner USB-Platte gebootet habe (da war die dann auf einmal /dev/sda). Wie das BIOS dann die restlichen Sachen durcheinanderwürfelt mußt du schauen ...
Bei mir ist interessanterweise die eSATA-Platte immer die /dev/sda (wie sie auch immer die SCSI-Nummer 3 erhält, s.o.!), wenn sie schon beim Booten drinsteckt. Das weiß ich genau, weil ich mich bei jedem "fdisk - -l" über dieses vorlaute Ding geärgert habe ;-)
user@rechner:~> sudo /sbin/lspci | grep 'ATA\|IDE' 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) Äh, hast du die Onboard SATA im IDE oder AHCI Modus? Da nichts im BIOS einzustellen ist (s.o.), tippe ich auf AHCI.
lsmod ;) Wenn da nix auftaucht ist's ahci (der ist fest im Kernel, sata_nv aber nicht).
AHCI gibt oder gab es anscheinend auch als Modul: rechner:~ # lsmod | grep "ata\|ahci" pata_amd 33284 0 sata_nv 46860 7 ahci 51080 0 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 usb_storage,sr_mod,sg,sd_mod,libata dock 29344 1 libata Pizza mit allem ... ist halt noch ne oS-11.0 mit Kernel 2.6.25. Und nun ohne eSATA-Platte: rechner:~ # lsmod | grep "ata\|ahci" pata_amd 33284 0 sata_nv 46860 7 ahci 51080 0 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 usb_storage,sr_mod,sg,sd_mod,libata dock 29344 1 libata Dieselbe Pizza. Vielleicht aber deshalb kein Unterschied, weil der JMicron-Chip ja aktiviert ist.
[..]
Und dann basteln wir dir ne device.map, mit /dev/disk/by-* statt /dev/sdX. Evtl. klappt es, wenn du manuell dort die eSATA als hd2 definierst. Das probiere ich beim nächsten Booten auch gleich aus (muss vorher aber ein paar dringende Arbeiten erledigen). Hmm, aber jetzt mal überlegen: das hieße doch, dass beim Schreiben des GRUB in den MBR schon die Gerätenummern (hdX) in den MBR mit eingetragen würden. Wozu muss er dann die menu.lst lesen? Auf dem Lesen der menu.lst beruhte doch Dein Vorschlag der zusätzlichen Einträge (hd2,Y) für den Fall des Bootens mit eSATA-Platte. Liest GRUB vor dem Booten auch die device.map, so dass diese zur Boot-Zeit auch relevant ist (dachte immer, die braucht nur grub-install, wenn man die üblichen Gerätebezeichner /dev/sdXy verwendet)?
Nein. Grub liest bei der Installation die device.map und nimmt so ein Mapping von /dev/sd* auf BIOS-Devices (hdX) vor. AFAIK wird nur dieses Mapping (BIOS- zu Grub-Device) und auf welcher Platte+Partition die menu.lst liegt mit "installiert", d.h. in den (M)BR bzw. den darauffolgenden Teil von Grub (stage1.5 mit den Dateisystemtreibern) geschrieben. Den ganzen Rest (kernel, Parameter, initrd usw.) liest Grub dann schon aus der menu.lst, deswegen muß man Grub ja auch nicht installieren, wenn man die menu.lst ändert. Aber wenn sich der Ort der menu.lst ändert (z.B. weil man /boot auf ne eigene Partition auslagern will oder von so einer auf die /-Partition holt).
Mein Konjunktiv "hieße" und die Klammer am Ende hat schon meinen Zweifel ausgedrückt, denn in dem Fall hätte ich GRUB so gut wie überhaupt noch nicht verstanden. Du bestätigst mir aber, dass ich (das meiste) doch verstanden habe ... aber selbstkritisches Hinterfragen kann auch nicht schaden :-)
Noch etwas, worüber ich nichts genaues gefunden habe: wie erhält GRUB eigentlich die Infos über die Geräte? Durch Parameterübergabe beim Start durch das BIOS, oder liest GRUB selber ein BIOS-Register, oder kann GRUB die Gerätereihenfolge gar selber festlegen? Ich denke, das müsste ich mal verstehen.
s.o. AFAIK verwendet Grub im Stage 1 und 1.5 den BIOS INT13(e) Befehl, d.h. die Platten werden über feste Nummern (Diskette: 0x00 und 0x01, Festplatten 0x80 ..) angesprochen.
Viele simpler, als ich dachte. Und wenn dann das BIOS je nach angesteckter eSATA-Platte eine andere Zuordnung Gerät <--> Nummer vornimmt, sieht GRUB die Geräte halt in der gebotenen Reihenfolge. Vielleicht etwas zu simpel, weshalb es wohl gut wäre, wenn GRUB in stage 1 erstmal alle Geräte-IDs der Platten mithilfe der fixen BIOS-Nummern ausliest (falls das prinzipiell überhaupt geht; wahrscheinlich braucht's dazu eine BIOS-Funktion, weil es ja noch keinen Gerätetreiber gibt; aber das BIOS weiß ja, wie man SATA-Geräte anspricht und kennt zumindest die Modellnamen der angeschlossenen Geräte) und diese auf die fixen BIOS-Nummern mappt. Wie üblich, kann dann nach dem Eintritt in Stage 1.5 aus dem Dateisystem, wo der MBR-GRUB seine Dateien stehen hat, die menu.lst gelesen werden. So kann für das Laden eines weiteren GRUB im Boot-Sektor anhand einer in dieser menu.lst stehenden Geräte-ID die vorher gemappte BIOS-Nummer für den Zugriff verwendet werden.
Kurz zu grub-install[.unsupported] ([] bei oS): die Option --recheck braucht man ja, damit man als Schreibziel für GRUB den _aktuell_richtigen_ MBR (/dev/sdX) bzw. den _aktuell_richtigen_ Boot-Sektor (/dev/sdXy) angibt.
Nein. --recheck erzeugt nur erst die device.map neu.
Ja, das ist mir bekannt. Aber GRUB wird gleich danach, d.h. durch denselben Aufruf von grub-install.unsupported mit /dev/sdb, in den MBR von z.B. (hd1) geschrieben, wenn in der device.map die Zuordnung "(hd1) /dev/sdb" steht.
Kannst du machen, wenn du grub-install.unsupported --recheck /dev/sda verwendest. Und dann die device.map angucken / korrigieren und dann nochmal grub-install ohne --recheck aufrufen.
Aber den zweiten Aufruf nur, falls die device.map nach dem "recheck" nicht i.O. war, d.h. manuell korrigiert werden musste. Sonst geht's AFAIK in einem Aufruf. Hat so jedenfalls mit dem grub-install der SysRescueCD funktioniert.
Selbst wenn man später ein System von (hd0,2) starten will, kann beim Schreiben des MBR das Ziel (hd1 <--> /dev/sdb) sein. Dann wäre aber die device.map später für's Booten egal.
Ist sie immer :)
Dann hatte ich auch das schon richtig verstanden :-D
Also, ich glaube, dass für eine Lösung das Verständnis die 'Laufwerkswahrnehmung' durch GRUB (absichtlich etwas unbestimmt) entscheidend ist, und wie diese evtl. mit den SCSI-Gerätenummern zusammenhängt.
Eher damit, wie grub die Devices vom BIOS serviert bekommt und ob das dann zur device.map _bei der Installation von Grub_ in den BR noch zusammenpasst.
Das meinte ich mit "Laufwerkswahrnehmung". Aber stimmt: mit SCSI-Nummern hat das nichts zu tun, denn zur Laufzeit von GRUB gibt es für GRUB keine SCSI-Geräte, sondern nur BIOS-Nummern. Deshalb merkt GRUB nichts davon, wenn an zweiter Stelle plötzlich eine eSATA-Platte sitzt. Mich würde ja interessieren, ob GRUB die Platten mit verschiedenen Anschlusstechnologien mit 'simplem' Assembler eigentlich selbständig so ansprechen kann, dass er deren Boot-Sektor selbständig laden kann, oder muss GRUB hier tatsächlich nochmal auf BIOS-Funktionen zurückgreifen? Wenn diese BIOS-Nummern die Geräteadressen sind, unter denen GRUB auf die ersten 512 Byte einer Platte zugreifen kann, dann braucht er wohl kein BIOS mehr dazu und kann auch die Partitionstabelle lesen, was ihn wiederum zum Boot-Sektor einer Distri führen müsste. Wenn er andererseits so nur auf die ersten 512 Byte kommt, dann kann er natürlich keine Geräte-ID von der Platte auslesen. Aber die GRUB-Shell könnte diese Geräte-ID für jede Platte vielleicht in deren MBR schreiben -- falls genug Platz dazu da ist. Beim Booten kann er dann mit den BIOS-Geräteadressen die Geräte-IDs wieder auslesen und aufeinander mappen. Ich glaube, dazu muss ich noch einiges googlen -- welch schreckliches Unwort :-(
Eigentlich sollte sich die eSATA nicht zwischen SSD und HDD drängeln, wenn du immer von SSD bootest.
Das ist IMHO das eigentliche Mysterium. Anscheinend ist das das BIOS, das sie dazwischen reinwurschtelt. Deshalb sollte GRUB Geräte-IDs direkt vom Gerät lesen können (s. meine Idee oben).
Kannst du nochmal die Boot-Reihenfolge im BIOS angucken?
Mache ich baldigst. Einstweilen schönen Dank für die anregende Diskussion. Gruß, Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFNZB3+Sd7ldYCwuBURAot2AKCmRXD21q/Mx+Rnpq7HRMQHN4hnkwCeIvLj 0+5gutNtusUVgBors2sVfGM= =wPoI -----END PGP SIGNATURE----- -- 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
participants (5)
-
Boris -
David Haller -
Patrick Klaus -
Ralf Arndt -
Thomas Michalka