Re: Bootsector nach Partitionierung herstellen

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,
>=20
> 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 umschalt=
en
>>>>> willst: schreib GRUB einfach in den MBR.
>>>> Bedeutet das, dass man einen Boot-Sektor-GRUB (BS-GRUB) direkt vom B=
IOS
>>>> 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=C3=A4te=
s, das
>>> in der Bootreihenfolge "vorne" ist (abh=C3=A4ngig von den BIOS
>>> Einstellungen und evtl. manueller Wahl via Boot-Men=C3=BC), in den Sp=
eicher
>>> und startet den Code dann.
>> Wenn dann aber erst noch ein Boot-Men=C3=BC kommt, wird i.Ggs. zu Dein=
em
>> folgenden Text das ausgew=C3=A4hlte gebootet.
>=20
> Das Boot-Men=C3=BC des BIOS (meist ne F-Taste, hier F12). Kein Grub, Li=
lo
> 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=C3=BC ausw=C3=A4hlt und kein Eintrag als "=
default"
>> markiert ist?
>=20
> Mi=C3=9Fverst=C3=A4ndnis. "generische MBR-Bootcode" ist der, der sich w=
ie der
> von DOS verh=C3=A4lt, n=C3=A4mlich eben schlicht die aktive Partition z=
u starten.

Ok, "again what learned" (Zitat aus den Lothar-Matth=C3=A4us-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=C3=A4llt 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 z=
u
>> erinnern)?
>=20
> 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=C3=BCpfend an die Diskussion, die wir k=C3=BCr=
zlich hatten,
>>>> mit einer kurzen Vorbemerkung:
>>>> Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte im=
mer
>>>> an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeu=
tig
>>>> als dritte Platte im BIOS-Setup eingereiht ist. Durch lsscsi im selb=
en
>>>> System wird die Platte auch immer an der selben Stelle angezeigt, eg=
al
>>>> ob sie schon beim Booten drin war oder erst sp=C3=A4ter 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; unte=
r
>>>> den ATA-Ger=C3=A4ten sogar das erste, hat aber nichts mir der Einrei=
hung
>>>> durch das BIOS zu tun), mal als /dev/sdg (ins laufende System einges=
teckt).
>>> Das h=C3=A4ngt davon ab, in welcher Reihenfolge die SATA-Controller v=
om
>>> 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=C3=A4=
ngt,
>>> erst beim Anschlie=C3=9Fen 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=C3=A4gl. =3D=3D> [3:0:0:0] ... ... WDC ... /dev/sdg
>                                                        ^
>=20
> Da wird eben wohl mit eSATA die WDC bzw. der Treiber f=C3=BCr den
> Controller zuerst geladen. Und 'nachtr=C3=A4glich' eben erst dann.
>=20
>> Wenn auch sehr interessant, ist das wohl etwas akademisch, denn da wur=
de
>> 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=C3=A4hig sind.
>=20
> Startet Grub noch mit korrektem Men=C3=BC?

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=C3=A4ndern, =
so
dass dann die Boot-Sektor-GRUBs korrekt geladen werden. Ist aber so
reichlich 'unelegant'.


>> Die Erkl=C3=A4rung, zugegebenerma=C3=9Fen nicht in ersch=C3=B6pfender =
Tiefe, scheint
>> zu sein, was ich oben in meiner "Vorbemerkung" schrieb.
>=20
>>> Guck mal,
>>> welcher Treiber f=C3=BCr den zust=C3=A4ndig ist, wenn das nicht der g=
leiche ist
>>> wie f=C3=BCr den Onboard, dann kannst du das Problem l=C3=B6sen in de=
m du das
>>> Modul generell nach dem f=C3=BCr Onboard l=C3=A4dst.

Aber nicht das Boot-Problem, sondern das der Device-Reihenfolge. Ich
m=C3=BCsste letzteres zwar nicht vordringlich l=C3=B6sen, aber mich w=C3=BC=
rde
nat=C3=BCrlich interessieren, wie man die Reihenfolge des Ladens der Modu=
le
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=C3=BCr die eSATA-Platte (WDC) und ahci f=C3=BCr d=
ie anderen
>> (internen) SATA-Ger=C3=A4te zust=C3=A4ndig? Und pata_jmicron scheint f=
=C3=BCr den
>> IDE-Port zust=C3=A4ndig zu sein.
>=20
> Eher andesrum, sata_nv f=C3=BCr den Onboard-Controller (nForce, zeig
> ggfs. mal "lspci | grep 'IDE\|SATA'" nVidia .. MCP ist nForce). Und
> ahci w=C3=A4re dann f=C3=BCr eSATA.

Wenn ich also meine SSD mit sata_nv anspreche, dann bremse ich sie
unn=C3=B6tig 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=C3=BCtzt:
"Man sollte darauf achten, dass die Ports [Anm.: die direkt am Chipsatz
angebundenen SATA-Schnittstellen] im AHCI-Modus konfiguriert sind
(manchmal hei=C3=9Ft er RAID-Modus), weil SSDs nur dann das
Performance-steigernde Native Command Queuing (NCQ) nutzen k=C3=B6nnen."

Kann ich den ahci-Treiber ausschlie=C3=9Flich (kein sata_nv mehr!), also =
auch
f=C3=BCr den Onboard-Controller verwenden?
Passiert das sogar automatisch, wenn es mir gelingt im BIOS-Setup den
AHCI-Modus f=C3=BCr den nVidia Corporation MCP55 SATA Controller (siehe u=
nter
lspci) einzustellen?

W=C3=A4re es eine L=C3=B6sung, mir einen neuen Kernel 2.6.37 oder .38 zu =
bauen, in
dem ahci fest drin ist, oder ist das f=C3=BCr 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?
>=20
> Da's bei dir mit lsmod gelistet wird: nein. Du k=C3=B6nntest ahci aus d=
er
> initrd rauswerfen, wenn der Onboard-Controller tats=C3=A4chlich ein nFo=
rce
> ist.

Wie geht das Rauswerfen aus der initrd?

> Dann bek=C3=A4mst 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=C3=BCrlich auch weiter in die /-Partition installiere=
n:
>>>>>
>>>>> grub> setup --stage2=3D/boot/grub/stage2 (hd0,0) (hd0,0)
>>>>>
>>>>> Wobei da die /boot/grub/device.map den passenden Eintrag haben mu=C3=
=9F,
>>>>> da=C3=9F (hd0) =3D=3D CF-Karte.
>>>> Wieso, Du verwendest doch auch f=C3=BCr die Root-Partition nur
>>>> GRUB-Ger=C3=A4tebezeichner.
>>>>
>>>> Ich war bisher der Meinung, dass die device.map nur von
>>>> grub-install[.unsupported] gebraucht wird, weil als Argumente f=C3=BC=
r dieses
>>>> Skript Linux-Ger=C3=A4tebezeichner (/dev/sdXy) =C3=BCbergeben werden=
 k=C3=B6nnen.
>>> Und was meinst du, woher Grub wei=C3=9F, as hd0 und was hd1 .. sein s=
oll?

Gute Frage, siehe unten die Folge der testweisen =C3=84nderung an der dev=
ice.map.

>> Das BIOS l=C3=A4dt den MBR mit GRUB darin und =C3=BCbergibt die Reihen=
folge der
>> Platten, und GRUB nimmt die Zuordnung vor:
>> die erste (Bootplatte) --> (hd0)
>> die zweite             --> (hd1)
>> die dritte             --> (hd2)
>> ...

Stimmt schon f=C3=BCr den GRUB-Code im MBR, aber die GRUB-Shell scheint
nichts zu wissen von BIOS-Ger=C3=A4tenummern.

>> Wenn GRUB aber doch die device.map nach seinem Start durch das BIOS
>> auswertet,
>=20
> 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=C3=A4tigt doch, dass die GRUB-Shell auch die device.map verwende=
t,
was mich einigerma=C3=9Fen ersch=C3=BCttert, denn ich ging bisher davon a=
us, dass
die  GRUB-Ger=C3=A4tebezeichner (hdX) fix an die BIOS-Ger=C3=A4tenummern =
(abh=C3=A4ngig
von der vorher gew=C3=A4hlten Boot-Ger=C3=A4te-Reihenfolge) gebunden sind=
.

Das passt auch dazu, dass im GRUB-Manual von der GRUB-Shell als
"Emulator" die Rede ist:

1.1 Overview
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[...] 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=C3=A4tenummern (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=C3=A4lt?

Anders gefragt: wenn man mit der device.map sogar die GRUB-Shell
t=C3=A4uschen kann, wie kriegt man im laufenden OS heraus, welches
Linux-Ger=C3=A4t (/dev/sdY) welche BIOS-Ger=C3=A4tenummer 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=C3=A4t* /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=C3=A4t das sein so=
ll,
oder? In einem laufenden Linux hat man ja eine eindeutige Zuordnung.

> Achso, und normal r=C3=A4t Grub, welches Device (/dev/sdX) zu welchem
> BIOS-Device (0x80, 0x81 ...) geh=C3=B6rt.

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=C3=BCr, dass das GRUB-Manual in "3.2 Installing GRU=
B
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=C3=9Fte dann auch per find
>>> die richtige Platte finden. Und im neuen System an Onboard SATA0
>>> geh=C3=A4ngt war sie dann eben /dev/sda.
>> Da werde ich deshalb nicht schlau daraus, weil die Zuteilung der
>> Linux-Ger=C3=A4tebezeichner doch erst durch den Kernel nach dem Laden =
der
>> Treiber-Module erfolgt, wenn ich Dich weiter oben richtig verstanden h=
abe.
>=20
> Naja, der Onboard wird halt per ahci angesprochen und das ist hier
> fest im Kernel (sonst m=C3=BC=C3=9Fte es in die initrd) und Onboard ist=
 halt der
> erste Controller vom BIOS aus gesehen.
>=20
> 00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controll=
er [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 Co=
ntroller (rev 03)
> 02:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Cont=
roller (rev 03)
> 03:00.0 SATA controller: Device 1b4b:9128 (rev 11
>=20
> 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.
>=20
>>>> Installiert man GRUB aus einem z.B. von DVD gestarteten externen Sys=
tem
>>>> f=C3=BCr ein auf Platte installiertes System, dann sollte man das IM=
HO am
>>>> besten in einer GRUB-shell, wie Du es oben gezeigt hast, machen. Man
>>>> muss sich dann nur klar =C3=BCber 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=C3=B6, das ist ja immer das erste Ger=C3=A4t, also f=C3=BCr GRUB imm=
er (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=C3=A4teren Sta=
rt sein
>> wird.
>=20
> Grub mu=C3=9F aber auch wissen, wo es stage2 findet.
>=20
>>> Aber dann mu=C3=9Ft
>>> 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=C3=A4ter als Boot-Platte die (hd0) werden so=
ll,
>> k=C3=B6nnte so eine explizite Angabe n=C3=B6tig sein.
>=20
> Nein, --stage2=3D ist der Pfad dort, wo grub bei der Installation gerad=
e
> l=C3=A4uft.

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=C3=A4sst den GRUB im MBR der aktuell zwe=
iten
Platte installieren. Wenn man danach im BIOS die Boot-Reihenfolge so
=C3=A4ndert, dass die eben beschriebene Platte die erste wird, dann sollt=
e
das nach meiner Erfahrung funktionieren. Es ist nur zu beachten, dass in
der menu.lst f=C3=BCr die zu startenden Systeme auf derselben Platte (hd0=
,x)
als Partition angegeben ist -- wenn man nicht immer erst mit "e" manuell
editieren m=C3=B6chte ;-)

> Grub wird 2-3teilig installiert:
>=20
> stage1   -> 512Byte in den BR (z.B. MBR)
> stage1.5 -> 512Byte (1 Sektor von Stage2) in BR+1
> stage2   -> ~116KB Dateisystem.
>=20
> Aus 'info grub':
>=20
> `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.
>=20
> `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.
>=20
> `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.
>=20
>      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.
>=20
> und in stage2/builtins.c findet man in setup_func und install_func,
> da=C3=9F die Nummer der Disk auf der stage2 liegt wenn n=C3=B6tig

Dann n=C3=B6tig, wenn es nicht dieselbe Disk ist?

> mit in stage1
> geschrieben (und stage1 dann in den MBR) wird. Stage1 enth=C3=A4lt also=
:
>=20
>     - ggfs. BIOS-Nummer der Disk auf der stage2 ist
>     - LBA-Flag
>     - Sektornummer von Stage2

Die Partitionsnummer sollte doch gen=C3=BCgen, da durch stage1.5 jetzt ei=
n
Dateisystem gelesen werden kann. Im Dateisystem der angegebenen
Partition braucht stage1.5 nur nach dem Pfad boot/grub/ "zu suchen".
Andernfalls d=C3=BCrfte man stage2 nicht an einen anderen Ort (innerhalb
desselben Dateisystempfades) verschieben.

> (Siehe info grub -> Internals -> Embedded data).
>=20
> MBR-Grub: Sektornummer Stage1.5: 01 00 00 00
>   /-Grub: Sektornummer Stage2: ad e0 07 00
>=20
> 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=C3=9F, Tom
--=20
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]=
g