Re: Bootsector nach Partitionierung herstellen

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?
>>=20
>> Nein. Das BIOS liest immer schlicht den ersten Sektor des Ger=E4tes, das
>> in der Bootreihenfolge "vorne" ist (abh=E4ngig von den BIOS
>> Einstellungen und evtl. manueller Wahl via Boot-Men=FC), in den Speicher
>> und startet den Code dann.
>
>Wenn dann aber erst noch ein Boot-Men=FC kommt, wird i.Ggs. zu Deinem
>folgenden Text das ausgew=E4hlte gebootet.

Das Boot-Men=FC 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=FC ausw=E4hlt und kein Eintrag als "default"
>markiert ist?

Mi=DFverst=E4ndnis. "generische MBR-Bootcode" ist der, der sich wie der
von DOS verh=E4lt, n=E4mlich 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=FCpfend an die Diskussion, die wir k=FCrzlich hat=
ten,
>>> 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=E4ter 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=E4ten sogar das erste, hat aber nichts mir der Einreihung
>>> durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingestec=
kt).
>>=20
>> Das h=E4ngt 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=E4ngt,
>> erst beim Anschlie=DFen erkannt wird. Wenn du mit angeschlossener WD
>> bootest wird der Controller wohl vor den anderen erkannt.
>
>So ist es:
>Booten mit eSATA =3D=3D> [3:0:0:0] ... ... WDC ... /dev/sda
>                                                      ^
>eSATA nachtr=E4gl. =3D=3D> [3:0:0:0] ... ... WDC ... /dev/sdg
                                                       ^

Da wird eben wohl mit eSATA die WDC bzw. der Treiber f=FCr den
Controller zuerst geladen. Und 'nachtr=E4glich' 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=E4hig sind.

Startet Grub noch mit korrektem Men=FC?

>Die Erkl=E4rung, zugegebenerma=DFen nicht in ersch=F6pfender Tiefe, scheint
>zu sein, was ich oben in meiner "Vorbemerkung" schrieb.

>> Guck mal,
>> welcher Treiber f=FCr den zust=E4ndig ist, wenn das nicht der gleiche ist
>> wie f=FCr den Onboard, dann kannst du das Problem l=F6sen in dem du das
>> Modul generell nach dem f=FCr Onboard l=E4dst.
>
>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=FCr die eSATA-Platte (WDC) und ahci f=FCr die anderen
>(internen) SATA-Ger=E4te zust=E4ndig? Und pata_jmicron scheint f=FCr den
>IDE-Port zust=E4ndig zu sein.

Eher andesrum, sata_nv f=FCr den Onboard-Controller (nForce, zeig
ggfs. mal "lspci | grep 'IDE\|SATA'" nVidia .. MCP ist nForce). Und
ahci w=E4re dann f=FCr 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=F6nntest ahci aus der
initrd rauswerfen, wenn der Onboard-Controller tats=E4chlich ein nForce
ist. Dann bek=E4mst 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=FChrt, dass sie vom BIOS an die zweite Stelle
>>> eingereiht wird?
>>=20
>> N=F6.
>
>Kann das BIOS nicht das zust=E4ndige Byte lesen, bzw. tut es das sicher
>nicht?

Ja. Das macht eben der generische Bootcode. Das BIOS startet nur den
MBR.

>Das k=F6nnte eine ersch=F6pfende Erkl=E4rung f=FCr das Ph=E4nomen 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.

>> =C4ndere es eben. Bei mir ist gar keine Partition aktiv ;P
>
>Genau, schon um meine obige Vermutung zu pr=FCfen. 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=FCrlich auch weiter in die /-Partition installieren:
>>>>
>>>> grub> setup --stage2=3D/boot/grub/stage2 (hd0,0) (hd0,0)
>>>>
>>>> Wobei da die /boot/grub/device.map den passenden Eintrag haben mu=DF,
>>>> da=DF (hd0) =3D=3D CF-Karte.
>>> Wieso, Du verwendest doch auch f=FCr die Root-Partition nur
>>> GRUB-Ger=E4tebezeichner.
>>>
>>> Ich war bisher der Meinung, dass die device.map nur von
>>> grub-install[.unsupported] gebraucht wird, weil als Argumente f=FCr die=
ses
>>> Skript Linux-Ger=E4tebezeichner (/dev/sdXy) =FCbergeben werden k=F6nnen.
>>=20
>> Und was meinst du, woher Grub wei=DF, as hd0 und was hd1 .. sein soll?
>
>Das BIOS l=E4dt den MBR mit GRUB darin und =FCbergibt 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=E4t Grub,
welches Device (/dev/sdX) zu welchem BIOS-Device (0x80, 0x81 ...)
geh=F6rt. 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=E4re das _die_ L=F6sung f=FCr mich. Aber ich habe keinerlei
>Hinweis darauf. Im Gegenteil: wenn ich mit "F8" das BIOS-Boot-Men=FC (noch
>vor GRUB) aufrufe, dann kann ich alles starten, obwohl die device.map
>f=FCr den MBR-GRUB derzeit v=F6llig 'gaga' ist:
>
>name@rechner> cat /grub/boot/grub/device.map
>(fd0)   /dev/fd0
>(hd0)   /dev/sde
>(hd1)   /dev/sdf
>
>Das galt f=FCr 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=FCr die Installation verwendet.

>>> Den Versuch, die Zuordnung zwischen Linux- und GRUB-Ger=E4tebezeichnern
>>> f=FCr die device.map mit der Option --recheck 'erraten' zu lassen, halte
>>> ich inzwischen sogar nur dann f=FCr sinnvoll, wenn man das genau in dem
>>> laufenden System macht, f=FCr das man GRUB gerade installieren m=F6chte.
>>=20
>> 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=FC die Platte
>> ausgew=E4hlt 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=FC meine zweite
>Platte (HDD) als Boot-Ger=E4t ausw=E4hle, dann kann ich im MBR-Boot-Men=FC
>(ja, auch bei der HDD habe ich f=FCr 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=FCr 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=FCr jeden Kernel einer Distri ein "root
>(hd0,x)" f=FCr erfolgreiches Finden durch GRUB eingetragen sein m=FCsste.

Jo. Dein BIOS scheint das per-BIOS-Men=FC-ge=E4nderte Boot-Device zu hd0
(BIOS: 0x80) zu machen.

>Dieses (sehr seltene) umeditieren k=F6nnte ich mir wahrscheinlich sparen,
>wenn ich in der menu.lst des HDD-MBR-GRUB in jedem Eintrag (hd0) <-->
>(hd1) ummappen w=FCrde, was ja dann nur vork=E4me, wenn ich von der HDD
>gebootet habe.

Oder je einen Eintrag mit hd0 und einen mit hd1 ;)

>> Ich mu=DFte dann auch per find
>> die richtige Platte finden. Und im neuen System an Onboard SATA0
>> geh=E4ngt war sie dann eben /dev/sda.
>
>Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der
>Linux-Ger=E4tebezeichner 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=FC=DFte 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 Contro=
ller (rev 03)
02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controll=
er (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=FCr 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 =FCber die Reihenfolge der Laufwerke sein, die =
das
>>> BIOS an den GRUB das gerade laufenden Systems gemeldet hat.
>>=20
>> Vielmehr: melden wird, wenn man von der Platte startet.
>
>N=F6, das ist ja immer das erste Ger=E4t, also f=FCr 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=E4teren Start sein
>wird.

Grub mu=DF aber auch wissen, wo es stage2 findet.

>> Aber dann mu=DFt
>> du AFAIK explizit '--stage2=3D' 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=3D(hd1)/boot/grub/stage2 (hd1)
>
>schreiben, also GRUB-Notation und Pfad-Notation mischen.
>Wenn die jetzige (hd1) sp=E4ter als Boot-Platte die (hd0) werden soll,
>k=F6nnte so eine explizite Angabe n=F6tig sein.

Nein, --stage2=3D ist der Pfad dort, wo grub bei der Installation gerade
l=E4uft. 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=DF die Nummer der Disk auf der stage2 liegt wenn n=F6tig mit in stage1
geschrieben (und stage1 dann in den MBR) wird. Stage1 enth=E4lt 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

--=20
   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)