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