Hallo David, David Haller schrieb:
Hallo,
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.
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? Startet GRUB ohne Auswahl dann nicht das System, das im ersten Eintrag steht (muss vielleicht nochmal nachlesen, aber ich glaube mich daran zu erinnern)?
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 ^ 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. 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. name@rechner> uname -r 2.6.25.20-0.1-default N.B. War da ahci auch schon im Kernel?
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? 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).
# fdisk -l /dev/sdg
Disk /dev/sdg: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x0005df91
Device Boot Start End Blocks Id System /dev/sdg1 * 1 523 4200966 82 Linux swap / ... /dev/sdg2 524 536 104422+ 83 Linux /dev/sdg3 537 3147 20972857+ 83 Linux /dev/sdg4 3148 60801 463105755 83 Linux
Verstehe eh nicht, wieso die Swap-Partition als aktiv markiert ist, ist doch überflüssig.
Ä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 :-(
# grub grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0) grub> quit
grub> help setup setup: setup [--prefix=DIR] [--stage2=STAGE2_FILE] [--force-lba[=off]] INSTALL_ DEVICE [IMAGE_DEVICE] Set up the installation of GRUB automatically. This command uses the more flexible command "install" in the backend and installs GRUB into the device INSTALL_DEVICE. If IMAGE_DEVICE is specified, then find the GRUB images in the device IMAGE_DEVICE, otherwise use the current "root device", which can be set by the command "root".
-> Das "IMAGE_DEVICE" ist, wo GRUB dann stage2 und die menu.lst sucht.
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, 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.
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. 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.
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.
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.
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. Auch von mir nochmal ein großes Dankeschön für Deine große Beitrags- und Hilfsbereitschaft! Gruß, Tom P.S.: Hier sind wir ja doch schon ganz schön vom "programming" abgekommen, aber mei, wenn's hilft -- und man muss ja nicht päpstlicher als der Papst sein ;-) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org