Mailinglist Archive: opensuse-programming-de (55 mails)

< Previous Next >
Re: [opensuse-programming-de] Bootsector nach Partitionierung herstellen
  • From: Thomas Michalka <Thomas.Michalka@xxxxxx>
  • Date: Sat, 09 Apr 2011 23:04:11 +0200
  • Message-id: <4DA0C9CB.1090209@gmx.de>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-programming-de+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups