Wie greift Grub Stage1 genau auf Stufe 2 zu / lädt sie?


9

Dies ist meine allererste Frage. Ich habe diese Frage vor Red Hat Instructors gestellt, aber keine zufriedenstellenden Antworten gefunden.

Ich verwende RHEL / CENTOS6, GRUB Legacy 0.97, und habe jede Menge Dokumentation konsultiert, in der der Linux-Startvorgang erläutert wird.

Fast alle Blogs, Dokumentationen usw. erklären erfolgreich die Schritte und den gesamten Prozess, scheitern jedoch einstimmig daran, was tatsächlich beim Laden von Grub Stage2 geschieht.

Hier ist mein Verständnis des Prozesses und ich habe auch ein bisschen getestet;

  1. Das BIOS (ohne EFI) liest MBR, findet die Partitionstabelle und lädt GRUB stage1 (die ersten 446 Bytes) in den Speicher
  2. Ich habe / boot Partition unter 1024 Zylindern, und die Idee, die ich aus einer Reihe von Dokumentationen extrahiert habe, ist, dass GRUB Stage1 Stage2 direkt laden kann, wenn es sich an einer Stelle unter 1024 Zylindern befindet. In einigen von mir konsultierten Dokumentationen wird erwähnt, dass sich Stage1.5 direkt nach MBR vor Sektor 63 befindet, während andere darauf hinweisen, dass es sich irgendwo in den ersten 1 MB der Festplatte befinden kann, und eine weitere Gruppe behauptete, dass Stage1.5 nur eine GRUB v2-Sache ist und dies nicht tut auf GRUB Legacy anwenden.
  3. GRUB stage2 verfügt über alle erforderlichen Treiber / Module zum Lesen von Dateisystemen und lädt so den Kernel und die Ramdisk sowie die Handover-Steuerung in den Kernel.
  4. Der Kernel startet init unter RHEL / CENTOS 6 und systemd unter RHEL / CENTOS 7.

Ich habe alle Daten vom 1. MB der Festplatte ausgegeben und kann bestätigen, dass es außer MBR nichts gibt. Ich bin verwirrt darüber, wie 446 Byte GRUB stage1 stage2 aus einem Dateisystem laden kann. Laut einigen Bildern auf Wikipedia und einigen Dokumenten enthält Stage1 bei der Installation von GRUB einen LBA48, der auf Stage2 verweist.

Ich habe versucht zu testen, ob Systeme gestartet werden, wenn Stage2 aus dem Verzeichnis / boot / grub / entfernt oder umbenannt wurde. Das System war auch dann noch bootfähig, wenn im Dateisystem keine Stufe 2 vorhanden war.

1. MB von / dev / sda

[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C
00000000  eb 48 90 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |.H..............|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 03 02  |.........|...t..|
00000040  80 00 00 80 fc 49 08 00  00 08 fa 90 90 f6 c2 80  |.....I..........|
00000050  75 02 b2 80 ea 59 7c 00  00 31 c0 8e d8 8e d0 bc  |u....Y|..1......|
00000060  00 20 fb a0 40 7c 3c ff  74 02 88 c2 52 f6 c2 80  |. ..@|<.t...R...|
00000070  74 54 b4 41 bb aa 55 cd  13 5a 52 72 49 81 fb 55  |tT.A..U..ZRrI..U|
00000080  aa 75 43 a0 41 7c 84 c0  75 05 83 e1 01 74 37 66  |.uC.A|..u....t7f|
00000090  8b 4c 10 be 05 7c c6 44  ff 01 66 8b 1e 44 7c c7  |.L...|.D..f..D|.|
000000a0  04 10 00 c7 44 02 01 00  66 89 5c 08 c7 44 06 00  |....D...f.\..D..|
000000b0  70 66 31 c0 89 44 04 66  89 44 0c b4 42 cd 13 72  |pf1..D.f.D..B..r|
000000c0  05 bb 00 70 eb 7d b4 08  cd 13 73 0a f6 c2 80 0f  |...p.}....s.....|
000000d0  84 f0 00 e9 8d 00 be 05  7c c6 44 ff 00 66 31 c0  |........|.D..f1.|
000000e0  88 f0 40 66 89 44 04 31  d2 88 ca c1 e2 02 88 e8  |..@f.D.1........|
000000f0  88 f4 40 89 44 08 31 c0  88 d0 c0 e8 02 66 89 04  |..@.D.1......f..|
00000100  66 a1 44 7c 66 31 d2 66  f7 34 88 54 0a 66 31 d2  |f.D|f1.f.4.T.f1.|
00000110  66 f7 74 04 88 54 0b 89  44 0c 3b 44 08 7d 3c 8a  |f.t..T..D.;D.}<.|
00000120  54 0d c0 e2 06 8a 4c 0a  fe c1 08 d1 8a 6c 0c 5a  |T.....L......l.Z|
00000130  8a 74 0b bb 00 70 8e c3  31 db b8 01 02 cd 13 72  |.t...p..1......r|
00000140  2a 8c c3 8e 06 48 7c 60  1e b9 00 01 8e db 31 f6  |*....H|.......1.|
00000150  31 ff fc f3 a5 1f 61 ff  26 42 7c be 7f 7d e8 40  |1.....a.&B|..}.@|
00000160  00 eb 0e be 84 7d e8 38  00 eb 06 be 8e 7d e8 30  |.....}.8.....}.0|
00000170  00 be 93 7d e8 2a 00 eb  fe 47 52 55 42 20 00 47  |...}.*...GRUB .G|
00000180  65 6f 6d 00 48 61 72 64  20 44 69 73 6b 00 52 65  |eom.Hard Disk.Re|
00000190  61 64 00 20 45 72 72 6f  72 00 bb 01 00 b4 0e cd  |ad. Error.......|
000001a0  10 ac 3c 00 75 f4 c3 00  00 00 00 00 00 00 00 00  |..<.u...........|
000001b0  00 00 00 00 00 00 00 00  19 aa 09 00 00 00 80 20  |............... |
000001c0  21 00 83 dd 1e 3f 00 08  00 00 00 a0 0f 00 00 dd  |!....?..........|
000001d0  1f 3f 8e fe ff ff 00 a8  0f 00 00 58 f0 04 00 00  |.?.........X....|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s

Zauberwort 0044-0047h = 0x000849fc

00000040  80 00 00 80 **fc 49 08 00**  00 08 fa 90 90 f6 c2 80  |.....I..........|

[root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00260914 s, 196 kB/s
00000000  52 56 5e bf f8 81 66 8b  2d 83 7d 04 00 0f 84 c4  |RV^...f.-.}.....|
00000010  00 80 7c ff 00 74 3e 66  8b 1d 66 31 c0 b0 7f 39  |..|..t>f..f1...9|
00000020  45 04 7f 03 8b 45 04 29  45 04 66 01 05 c7 04 10  |E....E.)E.f.....|
00000030  00 89 44 02 66 89 5c 08  c7 44 06 00 70 50 66 31  |..D.f.\..D..pPf1|
00000040  c0 89 44 04 66 89 44 0c  b4 42 cd 13 0f 82 93 00  |..D.f.D..B......|
00000050  bb 00 70 eb 56 66 8b 05  66 31 d2 66 f7 34 88 54  |..p.Vf..f1.f.4.T|
00000060  0a 66 31 d2 66 f7 74 04  88 54 0b 89 44 0c 3b 44  |.f1.f.t..T..D.;D|
00000070  08 7d 68 8b 04 2a 44 0a  39 45 04 7f 03 8b 45 04  |.}h..*D.9E....E.|
00000080  29 45 04 66 01 05 8a 54  0d c0 e2 06 8a 4c 0a fe  |)E.f...T.....L..|
00000090  c1 08 d1 8a 6c 0c 5a 52  8a 74 0b 50 bb 00 70 8e  |....l.ZR.t.P..p.|
000000a0  c3 31 db b4 02 cd 13 72  3a 8c c3 8e 45 06 58 c1  |.1.....r:...E.X.|
000000b0  e0 05 01 45 06 60 1e c1  e0 04 89 c1 31 ff 31 f6  |...E........1.1.|
000000c0  8e db fc f3 a4 1f 61 83  7d 04 00 0f 85 42 ff 83  |......a.}....B..|
000000d0  ef 08 e9 34 ff 5a ea 00  82 00 00 be 05 81 e8 3d  |...4.Z.........=|
000000e0  00 eb 06 be 0a 81 e8 35  00 be 0f 81 e8 2f 00 eb  |.......5...../..|
000000f0  fe 4c 6f 61 64 69 6e 67  20 73 74 61 67 65 32 00  |.Loading stage2.|
00000100  2e 00 0d 0a 00 47 65 6f  6d 00 52 65 61 64 00 20  |.....Geom.Read. |
00000110  45 72 72 6f 72 00 bb 01  00 b4 0e cd 10 46 8a 04  |Error........F..|
00000120  3c 00 75 f2 c3 00 00 00  00 00 00 00 00 00 00 00  |<.u.............|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  fd 49 08 00 f6 00 20 08  |.........I.... .|
00000200

(/ boot) beginnt um 2048.

# fdisk -lu /dev/sda

Disk /dev/sda: 42.9 GB, 42949672960 bytes
255 heads, 63 sectors/track, 5221 cylinders, total 83886080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009aa19

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1026047      512000   83  Linux Par...
/dev/sda2         1026048    83886079    41430016   8e  Linux LVM

Ich werde es wirklich schätzen, wenn jemand es erklären kann.


2
Haben Sie die vorhandene Datei auf Null gesetzt? Da beim Löschen die tatsächlichen Daten, auf die sich grub bezieht, wahrscheinlich nicht von der Disc entfernt werden.
Anthon

Das System wurde in den ursprünglichen Zustand zurückversetzt. dd if = / dev / zero von = / boot / grub / stage2 bs = 124k count = 1. Überprüft, ob die gesamte Datei auf Null gesetzt wurde. Neustart. Das System startet immer noch erfolgreich.
Zul K Irshad

Kommentare sind nicht für eine ausführliche Diskussion gedacht. Dieses Gespräch wurde in den Chat verschoben .
Terdon

Antworten:


8

Von https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html

US / Red_Hat_Enterprise_Linux / 3 / html / Reference_Guide / s1-grub-whatis.html

GRUB lädt sich in den folgenden Schritten in den Speicher:

Der Stage 1 oder primäre Bootloader wird vom BIOS vom MBR in den Speicher eingelesen [1]. Der primäre Bootloader befindet sich auf weniger als 512 Byte Speicherplatz im MBR und kann entweder den Stage 1.5- oder den Stage 2-Bootloader laden.

Der Stage 1.5-Bootloader wird bei Bedarf vom Stage 1-Bootloader in den Speicher eingelesen. Einige Hardware erfordert einen Zwischenschritt, um zum Stage 2-Bootloader zu gelangen. Dies ist manchmal der Fall, wenn sich die Datei / boot / partition über dem 1024-Zylinderkopf der Festplatte befindet oder wenn der LBA-Modus verwendet wird. Der Stage 1.5-Bootloader befindet sich entweder auf der / boot / partition oder auf einem kleinen Teil des MBR und der / boot / partition.

Der Stage 2 oder sekundäre Bootloader wird in den Speicher eingelesen. Der sekundäre Bootloader zeigt das GRUB-Menü und die Befehlsumgebung an. Diese Schnittstelle ermöglicht die Auswahl des Kernels oder Betriebssystems zum Booten, Übergeben von Argumenten an den Kernel oder Anzeigen von Systemparametern.

Es scheint ziemlich offensichtlich, dass Stufe 2 die eigentliche Grub-Binärdatei ist. Tatsächlich wird in der Dokumentation angegeben, dass Grub 2 nach Namen geladen wird.

Ich würde versuchen zu tun:

dd if=/dev/zero of=/boot/stage2

Zusätzliche Daten:

Inspektion / Boot / Grub:

Kopie des Stage1-Bootloaders:

stage1

Dateien für stage1_5:

e2fs_stage1_5  
fat_stage1_5  
jfs_stage1_5  
minix_stage1_5  
reiserfs_stage1_5  
xfs_stage1_5

Datei für Stufe 2:

stage2

Link zum Madenbild:

roden


1
Ich habe die Stage2-Datei bereits auf Null gesetzt, dd if = / dev / zero von = / boot / grub / stage2 bs = 124k count = 1. Es hat das System überhaupt nicht beeinflusst.
Zul K Irshad

Bitte machen Sie einen sudo grub-install /dev/sdaund
Rui F Ribeiro

demnach sollte es funktionieren en.wikipedia.org/wiki/GNU_GRUB
Rui F Ribeiro

grub-install / dev / sda hat die Binärdatei / boot / grub / stage2 neu generiert und das System ist weiterhin bootfähig.
Zul K Irshad

Vielleicht erstellt dd tatsächlich eine neue Datei, anstatt die alte zu überschreiben.
Rui F Ribeiro

2

Auf Computern, die der IBM PC-Boot-BIOS-Sequenz entsprechen:

  • Der MBR (absoluter Sektor 0) von der Festplatte wird vom BIOS im Speicher 0000: 7C00 geladen.
  • Dieser Code wird ausgeführt.

Bilden Sie IBM zu W7

Der von IBM PC zum Booten verwendete Code ist hier zu sehen:
Erste Version von MBR unter IBM® Personal Computer ™ DOS 2.00

Dieser Code enthält viele Versionen, die auch auf den Seiten des Starman angezeigt werden.
Ein Ausgangspunkt für diese vielen Versionen könnte diese Seite sein:
von MS-DOS 3.30 bis MS-Windows ™ 95 (A)

Einer der häufigsten MBR-Codes lautet:
MBR für: MS-Windows ™ 95B, 98, 98SE und ME

Die meisten dieser Codeversionen wurden nur zum Laden des nächsten VBR (Volume Boot Record) verwendet. Der VBR der Partition, der in der Partitionstabelle als bootfähig markiert ist, überträgt die Ausführung darauf.
(Bitte haben Sie Verständnis dafür, dass der VBR nicht der absolute Festplattensektor 0 oder W7 MBR ist. )

Suchen Sie auf der W7 MBR- Seite nach diesem Assembler-Hinweis :

;; Der folgende Code verwendet INT 13, Funktion 42h ("Extended Read"), um das zu lesen
; erster Sektor (VBR) der bootfähigen Partition in den Speicher an Position 0x7c00.

Windows ™ 7 (und Vista) VBR (Volume Boot Record)

Es ist interessant, dies von der W7VBR- Seite zu lesen :

;; Der folgende Code verwendet INT 13, Funktion 42h ("Extended Disk Read") zum Lesen; Jeweils 1 Sektor der verbleibenden 15 Sektoren des Boot Record-Bereichs in; Erinnerung; ab Standort 7E00.

Wie Sie bestätigen können, wurde der Startcode am MBR (Festplattensektor 0) gestartet, der VBR (Volume Boot Record) und viele (15 in W7) folgende Sektoren geladen.

RODEN

Aber wir sprechen hier über GRUB, also gehen Sie zur GRUB-Seite :

Und suchen Sie nach diesem Code:

[7C44] -> Note: A very important location for anyone using GRUB!
          This (4-byte) Quad-Word contains the location of GRUB's
          stage2 file in sectors! It's called "stage2_sector" in
          the stage1.S code. If GRUB is installed in the MBR by a
          distro that always includes a number of sectors from
          stage2 immediately following the GRUB MBR, you will see
          the bytes 01 00 00 00 in this location; otherwise, it
          will point to stage2 in the "/boot/grub" directory.

Das ist fast immer 01 00 00 00(oder nur: der nächste Sektor).

Dies bedeutet, dass das BIOS den absoluten Sektor 0 (MBR) lädt. Der im MBR installierte GRUB-Code liest weiterhin die folgenden Sektoren. Bis zur Größe von core.img(GRUB2) in neueren Distributionen (ca. 60 Sektoren oder ~ 30 kB). Bei heutigen Laufwerken bleibt nach dem MBR ein volles Mega-Byte frei, sodass kein Problem besteht. EFI-Festplatten haben eine separate Partition für den gesamten Code, und es gibt noch weniger Probleme (dh für die Größe).

Antworten

Legacy GRUB schreibt Stufe 2 oder in einigen Eckfällen optional Stufe 1.5 in den MBR und mehrere / viele der folgenden 62 Sektoren.

Und das wird auch in Bildern auf der Wikipedia Grub-Seite erklärt .

Von der GNU-Site 10 GRUB-Bilddateien :

stage1
   This is an essential image used for booting up GRUB. Usually, this is
   embedded in an MBR or the boot sector of a partition. Because a PC boot
   sector is 512 bytes, the size of this image is exactly 512 bytes.

   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. 

HINWEIS : Stage2 wird möglicherweise auf eine andere physische Festplatte geschrieben. Von der GRUB-Seite :

[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS
          booting systems, if your Linux installation with GRUB's
 See:     remaining software (stage2, menu file, etc.) is located
 7C5A     somewhere other than on the Primary Master drive, this
          value will be 81, 82, etc. depending upon which drive
          that Linux OS's /boot/grub directory is located. In the
          stage1.S file, it's called the GRUB_INVALID_DRIVE byte
          and commented as: "the disk to load stage2 from." (The
          word INVALID has something to do with the code logic.)

1
Vielen Dank für Ihre Antwort, es ist bei weitem die nächste Antwort, die ich bisher erhalten habe. Ich habe mir gestern schon die GRUB-Seite angesehen und ein bisschen Reverse Engineering gemacht. Das 4-Byte (Quad) -Wort an den Offsets 0044h-0047h brachte mich zum Speicherort von Stage2 auf der Festplatte. Es war ungefähr 256 MB vom Start der Festplatte an (/ boot auf einer Standardpartition). Ich habe den Inode von / boot / grub / stage2 mithilfe von Debugfs nachgeschlagen. Beide waren unterschiedliche Speicherorte. Ich habe Stufe 2 im Dateisystem auf Null gesetzt, aber Quad Word hat mich immer noch zu einer gültigen Stufe 2 geführt. Meine Frage lautet nun: Kann ich mir diese gültige Datei aus dem Dateisystem ansehen?
Zul K Irshad

Ich habe mir die gesamten ersten MB Festplatte angesehen, es gibt nur 512 MB MBR. Als ich mir das magische Quad-Wort ansah, kam ich zu dem Schluss, dass es sich um einen anderen Ort handelt als um / boot / grub / stage2. Was mich stört, ist, dass dieser Ort (auf den Quad Word zeigt) 256 MB tief in der Festplatte liegt.
Zul K Irshad

Die Festplatte wurde im Sektor 2048 ~ 1 MB gestartet. Habe die Frage mit weiteren Details aktualisiert.
Zul K Irshad

@ BinärZebra. Ihre Aussage "Bei weitem die übliche Art, Stage2 auf dem MBR zu installieren" ist absoluter Müll. Ein MBR kann GRUB Legacy Stage2
fpmurphy

Sie sagten, Sie hätten das Löschen stage2aus dem Dateisystem getestet . Wenn bei Ihrem ersten solchen Test die Datei nicht tatsächlich überschrieben wurde, hat das Dateisystem wahrscheinlich einen anderen Speicherort für die stage2Datei gefunden, als Sie sie nach dem Test ersetzt haben. Da die Blöcke jedoch nicht überschrieben wurden, ist der Inhalt von stage2weiterhin in diesen ursprünglichen Blöcken vorhanden, obwohl sie jetzt möglicherweise als freier Speicherplatz in den Metadaten des Dateisystems markiert sind. Wenn Sie nicht neu installieren stage1, funktioniert Ihr GRUB wahrscheinlich nicht mehr, wenn diese "freien" Blöcke durch etwas wiederverwendet und überschrieben werden.
TelcoM

1

GRUB Legacy kann auf verschiedene Arten installiert werden: mit oder ohne Stage 1.5.

Bei der Installation mit Stage 1.5 zeigt der Zeiger im MBR auf den Beginn von Stage 1.5. Der MBR-Code lädt den ersten Block von Stufe 1.5. Der Code in diesem Block enthält eine Liste weiterer zu ladender Blöcke sowie eine BIOS-Partitionsnummer und einen Dateinamen, der angibt, wo sich Stufe 2 befindet.

Im Fall des OP wurde GRUB Legacy jedoch ohne Stufe 1.5 installiert , wie im Text Loading stage2im zweiten Hex-Dump angegeben. In diesem Fall lädt MBR den ersten Block von Stufe 2 direkt, und wie im Fall von Stufe 1.5 enthält der erste Block eine Liste weiterer zu ladender Blöcke.

Die Trennung zwischen Stufe 1.5 und Stufe 2 bestand darin, die Einbettung von Stufe 1.5 zwischen dem MBR und dem Beginn der ersten Partition auch auf Festplatten zu ermöglichen, die die alte DOS-kompatible Konvention zum Starten der ersten Partition am Anfang von Spur 1, Kopf 0, verwendeten , anstatt aus Block Nr. 2048 (dh genau 1 MiB vom Start der Festplatte) wie bei modernen Betriebssystemen. Stufe 2 passt möglicherweise nicht in den Bereich zwischen dem MBR und dem Beginn der Partition, aber Stufe 1.5 ist kleiner, da nur ein Dateisystemtyp gelesen werden muss.

Bei der Installation mit Stage 1.5 kann Stage 2 von GRUB Legacy wie eine normale Datei behandelt werden, da es nach Dateinamen und nicht nach absoluten Blocknummern geladen wird. Bei der Installation ohne Stufe 1.5 kann Stufe 2 jedoch möglicherweise nicht von dem vom Installationsprogramm platzierten Blockspeicherort auf die Festplatte verschoben werden. Dateisystemtypspezifische Aktionen sollten ausgeführt werden, um sicherzustellen, dass die Datei nicht versehentlich verschoben wird: In einem VFAT-Dateisystem sollte die Stage 2-Datei beispielsweise mit den Attributen "system" und "schreibgeschützt" gekennzeichnet sein.

Natürlich kann das Installationsprogramm Stufe 2 zwischen dem MBR und dem Beginn der ersten Partition einbetten, wenn sie in den verfügbaren Speicherplatz passt. In diesem Fall ist der Schutz vor Manipulationen im Dateisystem kein Problem.

Hier ist das hintere Ende des zweiten Hex-Dumps des OP:

000001f0  00 00 00 00 00 00 00 00  fd 49 08 00 f6 00 20 08

Es enthält die Angabe weiterer zu ladender Blöcke als eine Anzahl von 8-Byte-Blocklistenstrukturen. In diesem Fall gibt es nur einen davon: "Laden Sie 0x00f6-Blöcke ab Block # 0x000849fd in die 16-Bit-Segmentadresse 0x0820". Beachten Sie, dass die Blocknummer nur 32-Bit ist und keine vollständige LBA48-Blocknummer: Dies verhindert, dass GRUB Legacy auf die volle Kapazität großer Festplatten zugreifen kann.

  1. Das BIOS (ohne EFI) liest MBR, findet die Partitionstabelle und lädt GRUB stage1 (die ersten 446 Bytes) in den Speicher

Das ist völlig richtig.

  1. Ich habe / boot Partition unter 1024 Zylindern, und die Idee, die ich aus einer Reihe von Dokumentationen extrahiert habe, ist, dass GRUB Stage1 Stage2 direkt laden kann, wenn es sich an einer Stelle unter 1024 Zylindern befindet.

Technisch gesehen "an jedem Ort, der durch eine 32-Bit-LBA-Blocknummer adressierbar ist", aber ansonsten korrekt. Die "unter 1024 Zylinder" würden ins Spiel kommen, wenn das BIOS keinen LBA-Zugriff unterstützen würde und GRUB auf alte BIOS-Aufrufe im C / H / S-Stil zurückgreifen müsste ... aber in jeder Post-Y2K-Hardware sollte dies nicht der Fall sein ein Problem sein.

In einigen von mir konsultierten Unterlagen wird erwähnt, dass sich Stage1.5 direkt nach MBR vor Sektor 63 befindet.

Wenn Stufe 1.5 verwendet wird, endet dies normalerweise dort. Es muss aber nicht da sein. Der "Vor-Sektor 63" stammt aus der alten DOS-Konvention für den Ort des Beginns der ersten Partition, wie ich oben angegeben habe.

während andere vorschlagen, dass es irgendwo in den ersten 1 MB der Festplatte sein kann

Es kann tatsächlich überall sein, wo es durch eine 32-Bit-Blocknummer adressierbar ist, aber auch hier ist die erste 1 MB dort, wo sie normalerweise ist, wenn Stufe 1.5 überhaupt verwendet wird. Die "ersten 1 MB" stammen aus der modernen SSD / SAN-freundlichen Konvention, bei der der Beginn der Partition genau 1 MiB vom Anfang der Festplatte entfernt festgelegt wird. Dies ist eine schöne, gleichmäßige Zweierpotenz, sodass sie ausgerichtet wird gut geeignet für größere Blockgrößen, RAID-Stripe-Größen und / oder andere Ausrichtungseinstellungen, die die Speicherhardware möglicherweise hat.

und noch eine andere Gruppe behauptete, dass Stage1.5 nur eine GRUB v2-Sache sei und nicht für GRUB-Legacy gilt.

Diese Dokumentation wird es genau nach hinten: stage1.5 ist speziell GRUB Legacy - Sache nur .

  1. GRUB stage2 verfügt über alle erforderlichen Treiber / Module zum Lesen von Dateisystemen und lädt so den Kernel und die Ramdisk sowie die Handover-Steuerung in den Kernel.

Richtig.

  1. Der Kernel startet init unter RHEL / CENTOS 6 und systemd unter RHEL / CENTOS 7.

Ein bisschen Vereinfachung, aber im Wesentlichen richtig.

In RHEL / CentOS 6 wird der allererste Userspace-Prozess zunächst /initin der anfänglichen Ramdisk-Datei ausgeführt, bei der es sich tatsächlich um ein Skript handelt, dessen letzte Aktion ausgeführt werden soll exec switch_root <mountpoint_of_real_root_filesystem> /sbin/init <arguments>oder ähnlich.

In RHEL / CentOS 7 ist das /inittatsächlich eine Verknüpfung zu /usr/lib/systemd/systemdden initramfs, wodurch eine spezielle Version gestartet wird systemd, die einige systemd-spezifische Parameter mit einem rd.Präfix erkennt . Wie das /initSkript in älteren Versionen richtet es alles ein, was für den Zugriff auf das Root-Dateisystem erforderlich ist, und ist dann exec()die "Vollversion" des systemdrealen Root-Dateisystems.


Vielen Dank, dass Sie sich die Zeit genommen haben, eine detaillierte Antwort zu geben. Werden Sie so freundlich sein, auch einige Kenntnisse über den Schritt exec switch_root zu teilen? Was mich stört ist, dass wenn / init von ramdisk oder initramfs ausgeführt wird, udev / dev- und proc-Dateisysteme unter / dev & / proc gemountet sind. Wie werden udev / dev und proc in dev- und proc-Verzeichnissen auf real / filesystem erneut bereitgestellt / zugeordnet? Sollte sich der Systemaufruf switch_root nicht beschweren, dass / beschäftigt ist?
Zul K Irshad

Siehe die Manpages des switch_root-Tools und seinen Quellcode - es kapselt alle kritischen Aktionen des Switches in einem einzigen Tool, und das initramfs ist so aufgebaut, dass die Anzahl der zum Zeitpunkt des Switches aktiven Userspace-Prozesse minimiert wird. Nach dem Umschalten löscht das Tool den Inhalt von initramfs. Sobald keine Prozesse mehr daran festhalten, bereinigt der Kernel-initramfs-Treiber sie, bis nichts mehr von den initramfs übrig ist.
TelcoM

0

Ich habe Hirens Boot-CD so konfiguriert und installiert, dass sie mit dem automatisierten Grub-Loader von hiren.info auf ein USB-Flash-Laufwerk geladen wird. Nachdem ich das bootfähige Hiren-USB-Laufwerk hatte, habe ich die Größe der primären Partition auf der Festplatte geändert und eine GB vom Back-End von reduziert das Flash-Laufwerk. Dann habe ich eine ext4-Partition im nicht zugewiesenen Bereich erstellt. Als nächstes habe ich nur den Befehl grub2config in xterm auf RIPLinuX ausgeführt und die Installation war relativ automatisiert. Mit dem Assistenten können Sie die Partition und das Verzeichnis auswählen, in dem grub2 installiert ist. Ich habe den Loader auf mbr auf der primären Partition des Flash-Laufwerks und ext4 / boot / grub als Installationsverzeichnis für die grub2-Dateien festgelegt. Installationshilfe für grub2config

Was passiert, ist, dass grub2 grldr das vorherige grldr im Stammverzeichnis der primären Partition auf dem Flash-Laufwerk ersetzt. Die vorherige Datei menu.lst wird wahrscheinlich gesichert, bevor sie durch die neue Datei menu.lst mit den Startoptionen ersetzt wird, die Sie im automatisierten Assistenten ausgewählt haben. Sobald Sie den 4- oder 5-stufigen Prozess abgeschlossen haben (abhängig von Ihrer Konfigurationspräferenz), starten Sie das System einfach neu und wählen Sie die USB-Festplatte als Startgerät aus. Wenn das Menü grub2.lst mit Ihren Startoptionen geladen wird, geben Sie einfach den Buchstaben "c" ein, um das einzugeben grub2 Befehlsschnittstelle. Jetzt können Sie die tragbare grub2-Umgebung vollständig laden und starten.grub2 befehlsliste1 grub2 befehlsliste2 Befehlsliste grub23

Weitere Screenshots finden Sie hier: https://www.minds.com/groups/profile/924192575922864128


1
Sie haben offensichtlich einige Anstrengungen unternommen, und wir wissen das zu schätzen. Aber ich glaube, dass Sie die Frage möglicherweise falsch verstanden haben. Soweit ich das beurteilen kann, fragt das OP: "Wie funktioniert das Ding?" (dh "Wie wird es implementiert?"), während Sie anscheinend auf ein "Wie mache ich X?" Frage. Bitte schreiben Sie auch das erste Wort jedes Satzes und das Wort „I“ in Großbuchstaben.
G-Man sagt "Reinstate Monica"

Die Frage bezieht sich auf GRUB Legacy und nicht auf GRUB2.
fpmurphy

0

Es gibt viele Möglichkeiten, wie grub ein System booten kann. Es hängt davon ab:

  • Unabhängig davon, ob mehrere Partitionstabellen vorhanden sind (Informationen zu lvm) oder nicht (ein Partitionsbereich kann in mehrere separate Partitionen aufgeteilt werden). Ich werde in diesem Beitrag nur Datenträger mit nur einer Partitionstabelle (und passenden Unterpartitionen) dieses Typs in Betracht ziehen.
  • Der Typ der Partitionstabelle, die die Festplatte verwendet (atari, aix, amiga, bsd, dvh, gpt, mac, msdos (bei PCs üblich), mindestens pc98, sun, loop und GPT). Sie haben ein Beispiel für eine msdos-Partitionstabelle MBR angegeben (ich werde diesen Beitrag weiter auf diesen Partitionstyp beschränken).
  • Der Dateisystemtyp für jede der Partitionen. Nun, hauptsächlich das Dateisystem der Partition, in der GRUB (normalerweise /boot) mehr Code laden muss .
  • Die Größe mehrerer Strukturen ((1) Sollen die Sektoren als nächstes über eine der (vielen) Grenzen ( von 528 MByte bis 137 GByte ) geladen werden , die definiert, welche Werte verwendet werden können und welche nicht. (2) Welche Leerzeichen und relative Größen des "freien" Speicherplatzes (wie die 62 Sektoren nach dem MBR in msdos-Partitionen oder die Sektoren im VBR (im Windows-Sprachgebrauch))
  • Die Größe des Festplattensektors (normalerweise 512 Byte in älteren Systemen, heutzutage normalerweise 2 KB).

Beschränken der Diskussion auf einen MBR-Bootsektor (msdos-Partition) und ein ext {2,3,4} -Dateisystem /dev/sda1(Sie haben keine separate /bootPartition oder, falls vorhanden, haben Sie die Details der LVM-Struktur für eine solche Partition nicht angegeben). .

Selbst in diesem begrenzten Szenario gibt es (zumindest) noch einige Möglichkeiten, wie Grub installiert werden könnte:

  • Die stage1(446 Bytes) werden in den MBR (den ersten Sektor) geschrieben.
  • A stage2kann nach dem MBR in die 62 Sektoren geschrieben werden. Der Zeiger (was Sie nennen: Zauberwort 0044-0047h = 0x000849fc (ein 32-Bit-Wort)) wird 01 00 00 00 (der nächste Sektor)).
  • Beides stage1kann auch auf das VBR geschrieben werden - Booten von mehr als 100 Linux-Systemen von einer Festplatte , was als Kettenladen bezeichnet wird .
  • Es könnte viele Boot-Manager geben, die auf unterschiedliche Weise Ketten laden könnten. Es gibt einfach zu viele, um sie zu erwähnen.
  • Dann muss entweder ein Dateisystemtreiber geladen werden, der für jeden Dateisystemtyp spezifisch ist, und dann mit ihm nach der Datei suchen /boot/stage2und sie laden.

Dies sind jedoch nur Möglichkeiten. In Ihrem Fall zeigt das Zauberwort auf die Mitte der Partition /dev/sda1(im absoluten Sektor (Dez) 543.228 echo $((0x000849fc))). Sie haben den ersten Sektor an dieser Position angegeben. Was Sie vermissen, ist zu erkennen, welche Datei diesen Sektor verwendet:

# tune2fs -l /dev/sdc1 | grep Block\ size       # find FS block size.
Block size:               4096

# echo $(( (0x000849fc - 2048) * 512 / 4096 ))
676647

# debugfs
debugfs 1.41.3 (12-Oct-2008)
debugfs:  open /dev/sda1
testb 676647
debugfs:  testb 676647
Block 676647 marked in use
debugfs:  icheck 676647
Block           Inode number
676647          5869525
debugfs:  ncheck 5869525
Inode           Pathname
5869525         /path/to/FileLoadedByGrub

Beachten Sie, dass sich die Frage speziell auf GRUB Legacy bezog, nicht auf den aktuellen GNU GRUB.
TelcoM

@telcoM Die Antwort wurde mit Blick auf grub0.97 geschrieben: Wo irreführe ich Sie?
Isaac

Ich sehe, Sie haben die Namen der Stufen bearbeitet. Im Gegensatz zum modernen GNU GRUB war der grub0.97 jedoch nur für BIOS-PCs vorgesehen (obwohl es einige Patches gab, die ihn mit UEFI kompatibel machten, wurden sie jedoch nie in offizielle Versionen aufgenommen). Es macht keinen Sinn, über Aix, Amiga, DVH oder Macs zu sprechen: GRUB 0.97 war nicht mit den Firmwares von Systemen kompatibel, die diese Partitionstabellenformate verwenden. Bei Sun-Systemen hatten ältere SPARC-basierte Systeme ein anderes Firmware- und Partitionstabellenformat, was einen anderen Bootloader erforderlich machte. Neuere x86-basierte Sun / Oracle-Hardware verwendet UEFI- und GPT-Partitionierung.
TelcoM

Außerdem handelt es sich um einen Dateisystemtreiber, der für jeden Dateisystemtyp spezifisch ist, der zum Laden verwendet wird stage2. In GRUB 0.97 lautet der Name dieser optionalen Komponente stage1.5. Ein vollständig dateisystemunabhängiger Benutzer stage1lädt entweder einen stage1.5, der einen einzelnen Dateisystemtyp versteht, oder stage2verwendet eine Blockliste, die ich in meiner Antwort beschrieben habe. Wenn stage1.5es verwendet wird, wird es stage2als Datei in einem Dateisystem gelesen . In jedem Fall stage2ist monolithisch: Die darin enthaltenen Dateisystemtreiber können nur zur Kompilierungszeit ausgewählt werden.
TelcoM
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.