Warum schreibt GNU parted Daten in die ersten 440 Bytes des MBR?

431
Will Haley

Ich verstehe, dass ein MBR 512 Bytes ist. Das erste 440 Bytes ( geben oder nehmen ein paar Bytes, abhängig von der Implementierung) enthält die Bootloader / Bootstrap - Code - Bereich. Die verbleibenden Bytes enthalten Informationen zur Partitionstabelle.

Wenn ich den MBR einer Platte auf Null setze ...

# Zero out the MBR dd if=/dev/zero of=/dev/sdX bs=1 count=512

Dann fdiskschreiben Sie eine Partitionstabelle, um /dev/sdX...

# Create a 2GiB partition starting at 2048 (default). fdisk /dev/sdX  ... Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier ... ...  (fdisk) n (fdisk) p (fdisk) 1 (fdisk) 2048 (fdisk) +2G (fdisk) w

Und dann die ersten 440 Bytes zurücklesen ...

dd if=/dev/sdX bs=1 count=440

Die ersten 440Bytes sind immer noch Null. fdiskhabe sie nicht angerührt, was aufgrund der oben genannten Links sinnvoll ist. fdiskschreibt Partitionsinformationen, sollte also nicht zuerst berührt werden 440.

Die nächsten 6Bytes sind nicht Null. Ich gehe davon aus, dass diese Bytes Teil der Datenträgersignatur eines modernen Standard-MBR sind .

$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"' 9a 29 97 e7

Bisher macht das mit meinem Verständnis der Anordnung des MBR Sinn. Diese ersten 440Bytes werden von ignoriert, fdiskda sie die Domäne des Bootloaders sind und fdisksich nur auf Partitionstabellen beziehen.

Allerdings partedwirft ich mich für eine Schleife.

Wenn ich den MBR der gleichen Platte wieder auf Null setze ...

# Zero out the MBR dd if=/dev/zero of=/dev/sdX bs=1 count=512

Dann benutze parted, um ein Plattenlabel zu erstellen (was fdiskfür mich oben automatisch schien) ...

parted /dev/sdX mklabel msdos

Und dann die ersten 440Bytes zurücklesen ...

$ dd if=/dev/sdX bs=1 count=440 | hexdump -e '16/1 "%02x " "\n"' fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Es gibt Bytes ungleich Null! Das scheint mit meinem derzeitigen Verständnis, wie der MBR angelegt werden soll und was GNU geteilt werden soll, keinen Sinn zu machen .

GNU Parted ist ein Programm zum Erstellen und Bearbeiten von Partitionstabellen.

Warum partedschreibt man Daten in diese ersten 440Bytes? Sind diese Bytes nicht für einen Bootloader gedacht? Sollte Parted diese Bytes nicht alleine lassen fdisk?

3
Haben Sie versucht, die mit Parted partitionierte Festplatte zu booten? Melebius vor 6 Jahren 1
Ich hatte das nicht versucht, bis Sie es vorschlugen. Ich bekomme einen schwarzen Bildschirm, wenn ich von dieser Festplatte boote. Es ist interessant, dass ich so etwas wie "Kein bootfähiges Medium gefunden!" Nicht sehe. Das ist der Fehler, den ich bekomme, wenn ich auf eine vollständig leere Festplatte starte. Es scheint also, als würde "parted" einen quasi gültigen Bootloader-Code schreiben, den das BIOS auszuführen versucht, aber es reicht nicht aus. Will Haley vor 6 Jahren 1
Ich vermute, dass dies ein Fehler in Parted ist, der am besten in seinen Foren diskutiert wird, die anscheinend [hier] (http://gparted-forum.surf4.info/) zu sein scheinen. harrymc vor 6 Jahren 0

1 Antwort auf die Frage

0
Will Haley

Es scheint, ich bin nicht der einzig man bemerken dieses Verhalten. Dies scheint vor allem in einigen armUmgebungen ein Problem zu sein, in denen ein Bootloader auf der Festplatte Probleme verursachen kann.

Das Problem ist, dass parted sich selbst (und unbemerkt) den Code dorthin legt, und daher denkt das eingebettete System, dass es einen gültigen Bootloader-Code gibt und glücklich hängt.

...und...

Gibt es eine Option für parted, um das Hinzufügen dieses Codes zu vermeiden (und sich wie fdisk verhalten)?

Es scheint, dass dieses Verhalten durch partedist absichtlich . Als Benutzer auf dem partedMailing-Fenster fragt:

Das Problem ist, dass parted von Anfang an den folgenden Code generiert:

...

Was ist der Zweck dieses Codes? Warum wurde dort hingestellt?

Und die Antwort scheint zu sein:

Dies ist der MBR-Startcode, der normalerweise zum Starten eines BIOS-Systems verwendet wird. Wenn es auf einem Nicht-x86-System Probleme verursacht, sollten Sie es auf Null setzen (oder den System-Bootloader nach der Partitionierung schreiben).

Es scheint, dass mklabelein generischer Bootloader auf die Festplatte geschrieben werden soll. Zumindest wenn ein Label von msdosverwendet wird. Ich denke, das macht Sinn, aber aus fdiskund syslinuxkommt es für einen Partitionsmanager etwas ungewöhnlich vor, Bootloader-Sektoren zu ändern.

Es scheint, als partedsollten diese Sektoren nicht überschrieben werden, wenn Daten ungleich Null vorhanden sind.

Nein, es wird nur dann nicht geschrieben, wenn bereits etwas vorhanden ist (z. B. nicht 0x00). Wenn Sie also das SDK dazu bringen könnten, zuerst seinen Bootloader zu schreiben, dann partitionieren Sie es, und parted lässt es unangetastet.

Dies ist jedoch nicht das Verhalten, das ich sehe. Wenn ich Müll schreibe /dev/urandom, dann laufen parted mklabelmeine nicht-null Daten definitiv.

Wenn ich die mbr.sDatei libpartedaus dem getrennten Repo zusammenstelle, kann ich sehen, woher diese Bytes stammen.

$ as86 -b /dev/stdout mbr.s | hexdump -e '16/1 "%02x " "\n"' fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b 4c 02 cd 13 ea 00 7c 00 00 eb fe

Das ist genau die Bytesequenz, parteddie auf meiner Festplatte zu erzeugen scheint.

Verwandte Probleme