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