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