Re: Bootsector nach Partitionierung herstellen

Hallo David,


David Haller schrieb:
> Hallo,
>=20
> 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 BIO=
S
>> starten lassen kann, indem man das Aktiv-Flag der Partition, in der de=
r
>> BS-GRUB installiert ist, setzt? Also ohne Boot-Code im MBR?
>=20
> Nein. Das BIOS liest immer schlicht den ersten Sektor des Ger=C3=A4tes,=
 das
> in der Bootreihenfolge "vorne" ist (abh=C3=A4ngig von den BIOS
> Einstellungen und evtl. manueller Wahl via Boot-Men=C3=BC), in den Spei=
cher
> und startet den Code dann.

Wenn dann aber erst noch ein Boot-Men=C3=BC kommt, wird i.Ggs. zu Deinem
folgenden Text das ausgew=C3=A4hlte 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=C3=BC ausw=C3=A4hlt und kein Eintrag als "def=
ault"
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=C3=BCpfend an die Diskussion, die wir k=C3=BCrzl=
ich hatten,
>> mit einer kurzen Vorbemerkung:
>> Es scheint wirklich so zu sein, dass mein BIOS meine eSATA-Platte imme=
r
>> an die zweite Stelle hinter der Boot-Platte setzt, obwohl sie eindeuti=
g
>> 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=C3=A4ter eingeschoben w=
urde:
>>
>> # 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=C3=A4ten sogar das erste, hat aber nichts mir der Einreihu=
ng
>> durch das BIOS zu tun), mal als /dev/sdg (ins laufende System eingeste=
ckt).
>=20
> Das h=C3=A4ngt 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=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
                                                      ^
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=C3=A4hig sind. Die Erkl=C3=A4rung, zugegebenerma=C3=9Fe=
n nicht in
ersch=C3=B6pfender Tiefe, scheint zu sein, was ich oben in meiner
"Vorbemerkung" schrieb.

> Guck mal,
> welcher Treiber f=C3=BCr den zust=C3=A4ndig ist, wenn das nicht der gle=
iche ist
> wie f=C3=BCr den Onboard, dann kannst du das Problem l=C3=B6sen in dem =
du das
> Modul generell nach dem f=C3=BCr Onboard l=C3=A4dst.

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 die =
anderen
(internen) SATA-Ger=C3=A4te zust=C3=A4ndig? Und pata_jmicron scheint f=C3=
=BCr den
IDE-Port zust=C3=A4ndig 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 au=
f
>> der eSATA-Platte dazu f=C3=BChrt, dass sie vom BIOS an die zweite Stel=
le
>> eingereiht wird?
>=20
> N=C3=B6.

Kann das BIOS nicht das zust=C3=A4ndige Byte lesen, bzw. tut es das siche=
r
nicht? Das k=C3=B6nnte eine ersch=C3=B6pfende Erkl=C3=A4rung f=C3=BCr das=
 Ph=C3=A4nomen 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 =3D cylinders of 16065 * 512 =3D 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, is=
t
>> doch =C3=BCberfl=C3=BCssig.
>=20
> =C3=84ndere es eben. Bei mir ist gar keine Partition aktiv ;P

Genau, schon um meine obige Vermutung zu pr=C3=BCfen. Allerdings eine akt=
ive
brauche ich (wirklich?), um ab und zu ein Windows zu starten :-(

>>> # grub
>>> grub> setup --stage2=3D/boot/grub/stage2 (hd0) (hd0,0)
>>> grub> quit
>>>
>>> grub> help setup =20
>>> setup: setup [--prefix=3DDIR] [--stage2=3DSTAGE2_FILE] [--force-lba[=3D=
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=C3=BCrlich 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=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=BCr=
 dieses
>> Skript Linux-Ger=C3=A4tebezeichner (/dev/sdXy) =C3=BCbergeben werden k=
=C3=B6nnen.
>=20
> Und was meinst du, woher Grub wei=C3=9F, as hd0 und was hd1 .. sein sol=
l?

Das BIOS l=C3=A4dt den MBR mit GRUB darin und =C3=BCbergibt die Reihenfol=
ge 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=C3=A4re das _die_ L=C3=B6sung f=C3=BCr mich. Aber ich h=
abe keinerlei
Hinweis darauf. Im Gegenteil: wenn ich mit "F8" das BIOS-Boot-Men=C3=BC (=
noch
vor GRUB) aufrufe, dann kann ich alles starten, obwohl die device.map
f=C3=BCr den MBR-GRUB derzeit v=C3=B6llig 'gaga' ist:

name@rechner> cat /grub/boot/grub/device.map
(fd0)   /dev/fd0
(hd0)   /dev/sde
(hd1)   /dev/sdf

Das galt f=C3=BCr ein Rettungssystem, in dem die SSD eben /dev/sde und di=
e
HDD /dev/sdf (hier ohne eSATA-Platte) war.

>> Den Versuch, die Zuordnung zwischen Linux- und GRUB-Ger=C3=A4tebezeich=
nern
>> f=C3=BCr die device.map mit der Option --recheck 'erraten' zu lassen, =
halte
>> ich inzwischen sogar nur dann f=C3=BCr sinnvoll, wenn man das genau in=
 dem
>> laufenden System macht, f=C3=BCr das man GRUB gerade installieren m=C3=
=B6chte.
>=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=C3=BC die Pl=
atte
> ausgew=C3=A4hlt hab) war sie dann /dev/sdg und Grub fand sich nicht wei=
l's
> eben nimmer hd0 sondern hd6 oder so war.

Bei mir ist das genau nicht so: Wenn ich im BIOS-Boot-Men=C3=BC meine zwe=
ite
Platte (HDD) als Boot-Ger=C3=A4t ausw=C3=A4hle, dann kann ich im MBR-Boot=
-Men=C3=BC
(ja, auch bei der HDD habe ich f=C3=BCr diesen Fall den MBR mit einem GRU=
B
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=C3=BCr 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=C3=BCr jeden Kernel einer Distri ein "r=
oot
(hd0,x)" f=C3=BCr erfolgreiches Finden durch GRUB eingetragen sein m=C3=BC=
sste.
Dieses (sehr seltene) umeditieren k=C3=B6nnte ich mir wahrscheinlich spar=
en,
wenn ich in der menu.lst des HDD-MBR-GRUB in jedem Eintrag (hd0) <-->
(hd1) ummappen w=C3=BCrde, was ja dann nur vork=C3=A4me, wenn ich von der=
 HDD
gebootet habe.

> 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 habe=
.

>> Installiert man GRUB aus einem z.B. von DVD gestarteten externen Syste=
m
>> f=C3=BCr 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 =C3=BCber 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=C3=B6, das ist ja immer das erste Ger=C3=A4t, also f=C3=BCr 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=C3=A4teren Start =
sein
wird.

> 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 soll,
k=C3=B6nnte so eine explizite Angabe n=C3=B6tig sein.


Auch von mir nochmal ein gro=C3=9Fes Dankesch=C3=B6n f=C3=BCr Deine gro=C3=
=9Fe Beitrags- und
Hilfsbereitschaft!


Gru=C3=9F, Tom


P.S.: Hier sind wir ja doch schon ganz sch=C3=B6n vom "programming"
abgekommen, aber mei, wenn's hilft -- und man muss ja nicht p=C3=A4pstlic=
her
als der Papst sein ;-)
--=20
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]=
g