-----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