Hallo, habe das GRUB-Manual jetzt mal diagonal gelesen, in einzelnen Punkten etwas tiefer, weshalb es mit meiner Antwort etwas gedauert hat. David Haller schrieb:
Hallo,
Am Sat, 09 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Am Thu, 07 Apr 2011, Thomas Michalka schrieb:
David Haller schrieb:
Lies auch mal 'info grub' ;) Da steht genau drin, was wie gebooted wird. Und -- wenn du nicht per "aktiver Partition" zur FAT umschalten willst: schreib GRUB einfach in den MBR. Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom BIOS starten lassen kann, indem man das Aktiv-Flag der Partition, in der der BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR? Nein. Das BIOS liest immer schlicht den ersten Sektor des Gerätes, das in der Bootreihenfolge "vorne" ist (abhängig von den BIOS Einstellungen und evtl. manueller Wahl via Boot-Menü), in den Speicher und startet den Code dann. Wenn dann aber erst noch ein Boot-Menü kommt, wird i.Ggs. zu Deinem folgenden Text das ausgewählte gebootet.
Das Boot-Menü des BIOS (meist ne F-Taste, hier F12). Kein Grub, Lilo oder sonst ein Bootmanager.
Aha, bei mir ist's F8.
Der generische MBR-Bootsektor macht dann das gleiche mit dem ersten Sektor der aktiven Partition der ersten Platte. Wenn man nichts im Boot-Menü auswählt und kein Eintrag als "default" markiert ist?
Mißverständnis. "generische MBR-Bootcode" ist der, der sich wie der von DOS verhält, nämlich eben schlicht die aktive Partition zu starten.
Ok, "again what learned" (Zitat aus den Lothar-Matthäus-Sketchen in BR3), ich dachte mit "generischem Boot-Code" sei der MBR-GRUB (stage 1) gemeint. Ist der generische Boot-Code dann ein Code der schon vom Hersteller im ersten Sektor untergebracht wird, oder woher stammt der (vom Himmel fällt er wohl nicht)?
Startet GRUB ohne Auswahl dann nicht das System, das im ersten Eintrag steht (muss vielleicht nochmal nachlesen, aber ich glaube mich daran zu erinnern)?
Andere Baustelle. Default bei Grub ist der erste Eintrag, falls kein anderer per 'default' definiert wird. Das ist aber eben Grub und nicht der generische Bootcode.
Ok, alles klar.
Noch eine Frage, anknüpfend an die Diskussion, die wir kürzlich hatten, mit einer kurzen Vorbemerkung: Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte immer an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeutig als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selben System wird die Platte auch immer an der selben Stelle angezeigt, egal ob sie schon beim Booten drin war oder erst später eingeschoben wurde:
# lsscsi [3:0:0:0] disk ATA WDC WD5000BEVT-0 01.0 /dev/sdg [4:0:0:0] disk ATA OCZ-VERTEX2 3.5 1.22 /dev/sda [5:0:0:0] disk ATA ST3500630AS 3.AA /dev/sdb
Also immer [3:0:0:0], mal als /dev/sda (beim Booten schon drin; unter den ATA-Geräten sogar das erste, hat aber nichts mir der Einreihung durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingesteckt). Das hängt davon ab, in welcher Reihenfolge die SATA-Controller vom Kernel erkannt werden. Guck dir mal deine /var/log/boot.msg an. Dort wirst du in dem Fall den Controller, an der die Western Digital hängt, erst beim Anschließen erkannt wird. Wenn du mit angeschlossener WD bootest wird der Controller wohl vor den anderen erkannt. So ist es: Booten mit eSATA ==> [3:0:0:0] ... ... WDC ... /dev/sda ^ eSATA nachträgl. ==> [3:0:0:0] ... ... WDC ... /dev/sdg ^
Da wird eben wohl mit eSATA die WDC bzw. der Treiber für den Controller zuerst geladen. Und 'nachträglich' eben erst dann.
Wenn auch sehr interessant, ist das wohl etwas akademisch, denn da wurde ja schon gebootet. Bei mir war aber immer die Frage, warum beim Booten mit eingesteckter eSATA-Platte die Systeme der zweiten internen Platte nicht mehr startfähig sind.
Startet Grub noch mit korrektem Menü?
Jo, ich kann auch bei dem betreffenden Eintrag x noch mit der Taste "e" (GRUB-Shell) die Zeile "root (hd1,x)" auf "root (hd2,x)" abändern, so dass dann die Boot-Sektor-GRUBs korrekt geladen werden. Ist aber so reichlich 'unelegant'.
Die Erklärung, zugegebenermaßen nicht in erschöpfender Tiefe, scheint zu sein, was ich oben in meiner "Vorbemerkung" schrieb.
Guck mal, welcher Treiber für den zuständig ist, wenn das nicht der gleiche ist wie für den Onboard, dann kannst du das Problem lösen in dem du das Modul generell nach dem für Onboard lädst.
Aber nicht das Boot-Problem, sondern das der Device-Reihenfolge. Ich müsste letzteres zwar nicht vordringlich lösen, aber mich würde natürlich interessieren, wie man die Reihenfolge des Ladens der Module bestimmt. Wie also bekomme ich ahci _nach_ sata_nv geladen?
name@rechner> lsmod | grep "ata\|ahci\|micron" pata_amd 33284 0 sata_nv 46860 13 ahci 51080 1 pata_jmicron 23808 0 libata 195232 4 pata_amd,sata_nv,ahci,pata_jmicron scsi_mod 195160 5 sr_mod,usb_storage,sg,sd_mod,libata dock 29344 1 libata
Sind jetzt sata_nv für die eSATA-Platte (WDC) und ahci für die anderen (internen) SATA-Geräte zuständig? Und pata_jmicron scheint für den IDE-Port zuständig zu sein.
Eher andesrum, sata_nv für den Onboard-Controller (nForce, zeig ggfs. mal "lspci | grep 'IDE\|SATA'" nVidia .. MCP ist nForce). Und ahci wäre dann für eSATA.
Wenn ich also meine SSD mit sata_nv anspreche, dann bremse ich sie unnötig aus, da ohne ahci kein NCQ (wenn ich mich recht erinnere). Das wird durch folgendes Zitat aus der neuesten c't 09/2011, S. 124 (Systembeschleunigung mit SSD) gestützt: "Man sollte darauf achten, dass die Ports [Anm.: die direkt am Chipsatz angebundenen SATA-Schnittstellen] im AHCI-Modus konfiguriert sind (manchmal heißt er RAID-Modus), weil SSDs nur dann das Performance-steigernde Native Command Queuing (NCQ) nutzen können." Kann ich den ahci-Treiber ausschließlich (kein sata_nv mehr!), also auch für den Onboard-Controller verwenden? Passiert das sogar automatisch, wenn es mir gelingt im BIOS-Setup den AHCI-Modus für den nVidia Corporation MCP55 SATA Controller (siehe unter lspci) einzustellen? Wäre es eine Lösung, mir einen neuen Kernel 2.6.37 oder .38 zu bauen, in dem ahci fest drin ist, oder ist das für die Performance unbedeutend, ob AHCI im Kernel oder als Modul arbeitet? name@rechner> lspci | grep 'IDE\|SATA' 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)
name@rechner> uname -r 2.6.25.20-0.1-default
N.B. War da ahci auch schon im Kernel?
Da's bei dir mit lsmod gelistet wird: nein. Du könntest ahci aus der initrd rauswerfen, wenn der Onboard-Controller tatsächlich ein nForce ist.
Wie geht das Rauswerfen aus der initrd?
Dann bekämst du ne stabile Reihenfolge (immer erst sata_nv, dann ahci).
(N.B.: Was aber, wie gesagt, nicht direkt etwas mit dem Boot-Problem zu tun hat.) Wenn ich beim Booten schon die eSATA-Platte drin habe, muss ich dann das Modul ahci erst manuell nachladen, wenn ich sie nutzen will?
Du kannst natürlich auch weiter in die /-Partition installieren:
grub> setup --stage2=/boot/grub/stage2 (hd0,0) (hd0,0)
Wobei da die /boot/grub/device.map den passenden Eintrag haben muß, daß (hd0) == CF-Karte. Wieso, Du verwendest doch auch für die Root-Partition nur GRUB-Gerätebezeichner.
Ich war bisher der Meinung, dass die device.map nur von grub-install[.unsupported] gebraucht wird, weil als Argumente für dieses Skript Linux-Gerätebezeichner (/dev/sdXy) übergeben werden können. Und was meinst du, woher Grub weiß, as hd0 und was hd1 .. sein soll?
Gute Frage, siehe unten die Folge der testweisen Änderung an der device.map.
Das BIOS lädt den MBR mit GRUB darin und übergibt die Reihenfolge der Platten, und GRUB nimmt die Zuordnung vor: die erste (Bootplatte) --> (hd0) die zweite --> (hd1) die dritte --> (hd2) ...
Stimmt schon für den GRUB-Code im MBR, aber die GRUB-Shell scheint nichts zu wissen von BIOS-Gerätenummern.
Wenn GRUB aber doch die device.map nach seinem Start durch das BIOS auswertet,
Tut er nicht. Die device.map wird nur bei der Installation von Grub (in den MBR oder sonstwo) verwendet.
Ok, dann lag ich da richtig. [Update:] Nicht nur von grub-install, sondern auch von der GRUB-Shell, wie ein eben gemachter Versuch mit zwei verschiedenen Device Identifier Mappings beweist: name@rechner> cat /boot/grub/device.map (hd0) /dev/sdb (hd1) /dev/sda grub> find /boot/grub/device.map (hd0,4) (hd0,6) (hd0,7) (hd0,8) Jetzt: name@rechner> cat /boot/grub/device.map (hd0) /dev/sda (hd1) /dev/sdb grub> find /boot/grub/device.map (hd1,4) (hd1,6) (hd1,7) (hd1,8) Das bestätigt doch, dass die GRUB-Shell auch die device.map verwendet, was mich einigermaßen erschüttert, denn ich ging bisher davon aus, dass die GRUB-Gerätebezeichner (hdX) fix an die BIOS-Gerätenummern (abhängig von der vorher gewählten Boot-Geräte-Reihenfolge) gebunden sind. Das passt auch dazu, dass im GRUB-Manual von der GRUB-Shell als "Emulator" die Rede ist: 1.1 Overview ============ [...] Zitat: "Besides the GRUB boot loader itself, there is a "grub shell" `grub' (*note Invoking the grub shell::) which can be run when you are in your operating system. It *emulates* the boot loader and can be used for installing the boot loader." Das verstehe ich so, dass von der GRUB-Shell, die man im laufenden OS starten kann, nicht zu erwarten ist, dass sie die Zuordnung zwischen BIOS-Gerätenummern (0x8Y) und GRUB-Devices (hdY) herstellen kann. Wenn man nun ein System von CD/DVD gestartet hat, wie soll man da bei zwei oder gar mehreren Platten herausfinden, wie diese den (hdY) zugeordnet sind, wenn keine davon die Boot-Platte ist und sich sogar die GRUB-Shell nur an die device.map hält? Anders gefragt: wenn man mit der device.map sogar die GRUB-Shell täuschen kann, wie kriegt man im laufenden OS heraus, welches Linux-Gerät (/dev/sdY) welche BIOS-Gerätenummer hat? Oder habe ich die Frage falsch gestellt? Kann die device.map ein (nahezu) beliebiges Mapping enthalten, weil der stage 1 auf das entsprechende *Linux-Gerät* /dev/sdY (MBR) oder /dev/sdYz geschrieben wird? Wenn das stimmt, und man (hdY) oder (hdY,z) in der GRUB-Shell verwendet, wird halt in device.map nachgesehen, welches Linux-Gerät das sein soll, oder? In einem laufenden Linux hat man ja eine eindeutige Zuordnung.
Achso, und normal rät Grub, welches Device (/dev/sdX) zu welchem BIOS-Device (0x80, 0x81 ...) gehört.
Ist das auch so, wenn man GRUB "nativ" (ohne emulierende Shell) verwendet, d.h. GRUB beispielsweise von einer CD bootet, oder kennt dieser GRUB dann die Zuordnung zwischen (hdY) und (0x8Y)? Ist das der Grund dafür, dass das GRUB-Manual in "3.2 Installing GRUB natively" das Anfertigen einer "GRUB boot disk" empfiehlt?
Und BTW: wenn du '(hd0)' verwendest, verwendet Grub beim booten dann eben die Platte 0x80 via INT13, siehe http://en.wikipedia.org/wiki/INT_13
Ich mußte dann auch per find die richtige Platte finden. Und im neuen System an Onboard SATA0 gehängt war sie dann eben /dev/sda. Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der Linux-Gerätebezeichner doch erst durch den Kernel nach dem Laden der Treiber-Module erfolgt, wenn ich Dich weiter oben richtig verstanden habe.
Naja, der Onboard wird halt per ahci angesprochen und das ist hier fest im Kernel (sonst müßte es in die initrd) und Onboard ist halt der erste Controller vom BIOS aus gesehen.
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] 00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller 02:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03) 03:00.0 SATA controller: Device 1b4b:9128 (rev 11
00:11.0 ist der Onboard-Controller der AMD SB710, 00:14.1 ist der Onboard-IDE-Controller, 02:00.0 ist Onboard-eSATA, 02:00.1 liegt brach, 03:00.0 ist der Onboard-SATA Marvell-9128 Zusatzcontroller.
Installiert man GRUB aus einem z.B. von DVD gestarteten externen System für ein auf Platte installiertes System, dann sollte man das IMHO am besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man muss sich dann nur klar über die Reihenfolge der Laufwerke sein, die das BIOS an den GRUB das gerade laufenden Systems gemeldet hat. Vielmehr: melden wird, wenn man von der Platte startet. Nö, das ist ja immer das erste Gerät, also für GRUB immer (hd0). Zum Zeitpunkt der GRUB-Installation (des setup-Kommandos) muss setup dem Kommando install das GRUB-Device mitteilen, wo install den GRUB-CODE hinschreiben soll, nicht welches GRUB-Device es beim späteren Start sein wird.
Grub muß aber auch wissen, wo es stage2 findet.
Aber dann mußt du AFAIK explizit '--stage2=' angeben, sonst wird das nicht klappen. Ja, das muss der Pfad sein, wo stage2 zum Zeitpunkt der GRUB-Installation zu finden ist. Ich glaube, man kann sogar
grub> setup --stage2=(hd1)/boot/grub/stage2 (hd1)
schreiben, also GRUB-Notation und Pfad-Notation mischen. Wenn die jetzige (hd1) später als Boot-Platte die (hd0) werden soll, könnte so eine explizite Angabe nötig sein.
Nein, --stage2= ist der Pfad dort, wo grub bei der Installation gerade läuft.
Wir haben hier keinen Dissens. Die Angabe (hd1) im obigen Pfad ist redundant, wenn -- und so war's gemeint -- die zweite Stufe von GRUB unter /boot/grub/stage2 des aktuell laufenden Systems zu finden ist. Das zweite (hd1) im Setup-Kommando lässt den GRUB im MBR der aktuell zweiten Platte installieren. Wenn man danach im BIOS die Boot-Reihenfolge so ändert, dass die eben beschriebene Platte die erste wird, dann sollte das nach meiner Erfahrung funktionieren. Es ist nur zu beachten, dass in der menu.lst für die zu startenden Systeme auf derselben Platte (hd0,x) als Partition angegeben ist -- wenn man nicht immer erst mit "e" manuell editieren möchte ;-)
Grub wird 2-3teilig installiert:
stage1 -> 512Byte in den BR (z.B. MBR) stage1.5 -> 512Byte (1 Sektor von Stage2) in BR+1 stage2 -> ~116KB Dateisystem.
Aus 'info grub':
`stage1' [..] All `stage1' must do is to load Stage 2 or Stage 1.5 from a local disk. Because of the size restriction, `stage1' encodes the location of Stage 2 (or Stage 1.5) in a block list format, so it never understand any filesystem structure.
`stage2' This is the core image of GRUB. It does everything but booting up itself. Usually, this is put in a filesystem, but that is not required.
`e2fs_stage1_5' [..] These are called "Stage 1.5", because they serve as a bridge between `stage1' and `stage2', that is to say, Stage 1.5 is loaded by Stage 1 and Stage 1.5 loads Stage 2. The difference between `stage1' and `*_stage1_5' is that the former doesn't understand any filesystem while the latter understands one filesystem (e.g. `e2fs_stage1_5' understands ext2fs). So you can move the Stage 2 image to another location safely, even after GRUB has been installed.
While Stage 2 cannot generally be embedded in a fixed area as the size is so large, Stage 1.5 can be installed into the area right after an MBR, or the boot loader area of a ReiserFS or a FFS.
und in stage2/builtins.c findet man in setup_func und install_func, daß die Nummer der Disk auf der stage2 liegt wenn nötig
Dann nötig, wenn es nicht dieselbe Disk ist?
mit in stage1 geschrieben (und stage1 dann in den MBR) wird. Stage1 enthält also:
- ggfs. BIOS-Nummer der Disk auf der stage2 ist - LBA-Flag - Sektornummer von Stage2
Die Partitionsnummer sollte doch genügen, da durch stage1.5 jetzt ein Dateisystem gelesen werden kann. Im Dateisystem der angegebenen Partition braucht stage1.5 nur nach dem Pfad boot/grub/ "zu suchen". Andernfalls dürfte man stage2 nicht an einen anderen Ort (innerhalb desselben Dateisystempfades) verschieben.
(Siehe info grub -> Internals -> Embedded data).
MBR-Grub: Sektornummer Stage1.5: 01 00 00 00 /-Grub: Sektornummer Stage2: ad e0 07 00
Und Stage1.5/Stage2 laden dann via Dateisystem, die Partitionsnummer steht in stage2 mit drin.
Verstehe ich auch nicht, denn in der menu.lst, die im selben Pfad, wie stage2 steht, kann doch alles weitere vom GRUB core gelesen werden. Gruß, Tom -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org