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.
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.
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.
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ü?
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.
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.
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. Dann bekämst du ne stabile Reihenfolge (immer erst sata_nv, dann ahci).
Nun die Frage: kann es sein, dass ein Aktiv-Flag in einer Partition auf der eSATA-Platte dazu führt, dass sie vom BIOS an die zweite Stelle eingereiht wird?
Nö.
Kann das BIOS nicht das zuständige Byte lesen, bzw. tut es das sicher nicht?
Ja. Das macht eben der generische Bootcode. Das BIOS startet nur den MBR.
Das könnte eine erschöpfende Erklärung für das Phänomen sein, dass bei eingeschobener eSATA-Platte beim Booten selbige immer an die zweite Stelle in der Reihenfolge tritt, anstatt sich an die von mir vorgegebene Reihenfolge zu halten (also an dritter Stelle zu bleiben).
s.o.
Ändere es eben. Bei mir ist gar keine Partition aktiv ;P
Genau, schon um meine obige Vermutung zu prüfen. Allerdings eine aktive brauche ich (wirklich?), um ab und zu ein Windows zu starten :-(
Dann sollte aber (nur) die Windows-Partition aktiv sein. [..]
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?
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) ...
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. Achso, und normal rät Grub, welches Device (/dev/sdX) zu welchem BIOS-Device (0x80, 0x81 ...) gehört. 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
dann wäre das _die_ Lösung für mich. Aber ich habe keinerlei Hinweis darauf. Im Gegenteil: wenn ich mit "F8" das BIOS-Boot-Menü (noch vor GRUB) aufrufe, dann kann ich alles starten, obwohl die device.map für den MBR-GRUB derzeit völlig 'gaga' ist:
name@rechner> cat /grub/boot/grub/device.map (fd0) /dev/fd0 (hd0) /dev/sde (hd1) /dev/sdf
Das galt für ein Rettungssystem, in dem die SSD eben /dev/sde und die HDD /dev/sdf (hier ohne eSATA-Platte) war.
Die device.map wird wohl nur für die Installation verwendet.
Den Versuch, die Zuordnung zwischen Linux- und GRUB-Gerätebezeichnern für die device.map mit der Option --recheck 'erraten' zu lassen, halte ich inzwischen sogar nur dann für sinnvoll, wenn man das genau in dem laufenden System macht, für das man GRUB gerade installieren möchte.
Sowieso. Ich hab das System hier im neuen Rechner vorinstalliert -- und zwar auf ne externe Platte am anderen. Dort war meine jetztige /dev/sda eben /dev/sdk. Und wenn ich dann (im BIOS-Bootmenü die Platte ausgewählt hab) war sie dann /dev/sdg und Grub fand sich nicht weil's eben nimmer hd0 sondern hd6 oder so war.
Bei mir ist das genau nicht so: Wenn ich im BIOS-Boot-Menü meine zweite Platte (HDD) als Boot-Gerät auswähle, dann kann ich im MBR-Boot-Menü (ja, auch bei der HDD habe ich für diesen Fall den MBR mit einem GRUB ausgestattet) alle mit (hd0,x) eingetragenen Boot-Sektor-GRUBs starten. Wenn diese mir dann bei einer Distri die verschiedenen Kernel anbieten, dann muss ich nach der Auswahl sogar (hd1,x) auf (hd0,x) umeditieren, weil (hd1,x) nur gilt für die HDD als zweite Platte (der Normalfall), wenn ich von der SSD (dann hd0) gebootet habe! Jetzt war ausnahmsweise aber die HDD die erste, so dass für jeden Kernel einer Distri ein "root (hd0,x)" für erfolgreiches Finden durch GRUB eingetragen sein müsste.
Jo. Dein BIOS scheint das per-BIOS-Menü-geänderte Boot-Device zu hd0 (BIOS: 0x80) zu machen.
Dieses (sehr seltene) umeditieren könnte ich mir wahrscheinlich sparen, wenn ich in der menu.lst des HDD-MBR-GRUB in jedem Eintrag (hd0) <--> (hd1) ummappen würde, was ja dann nur vorkäme, wenn ich von der HDD gebootet habe.
Oder je einen Eintrag mit hd0 und einen mit hd1 ;)
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. 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 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 (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. -dnh -- 189: Linux-Deathmatch CDs der alten Suse-Distributionen werden am Rand angeschliffen und per Pressluftwerfer wird versucht, damit die Gurgel des entsprechenden Delinquenten zu treffen. (Urs Traenkner) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org