Nach meinem Verständnis ist ein MBR 512 Byte groß.erste 440 Bytes(gebenodernehmenAwenige Bytes, je nach Implementierung) enthalten den Bootloader/Bootstrap-Codebereich. Die restlichen Bytes enthalten Informationen zur Partitionstabelle.
Wenn ich den MBR einer Festplatte auf Null setze ...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Verwenden Sie es dann, fdiskum eine Partitionstabelle in /dev/sdX... zu schreiben.
# 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 alle Null. fdiskHabe sie nicht angerührt, was aufgrund der Links, die ich oben gepostet habe, Sinn macht. fdiskSchreibt Partitionsinformationen, also sollte/müsste es die ersten nicht anrühren 440.
Die nächsten 6Bytes sind ungleich Null. Ich gehe davon aus, dass diese Bytes Teil desFestplattensignatur eines modernen Standard-MBR.
$ dd if=/dev/sdX bs=1 count=6 skip=440 | hexdump -e '4/1 "%02x " "\n"'
9a 29 97 e7
Soweit ich weiß, wie der MBR aufgebaut ist, ergibt das Sinn. Diese ersten 440Bytes werden ignoriert, fdiskda sie die Domäne des Bootloaders sind und fdisksich nur mit Partitionstabellen befassen.
partedEs bringt mich jedoch völlig aus der Fassung.
Wenn ich den MBR derselben Festplatte erneut auf Null setze ...
# Zero out the MBR
dd if=/dev/zero of=/dev/sdX bs=1 count=512
Verwenden Sie dann parted, um eine Datenträgerbezeichnung zu erstellen (was fdiskbei mir oben anscheinend automatisch geschah) …
parted /dev/sdX mklabel msdos
440Und dann die ersten Bytes 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 sind Bytes ungleich Null vorhanden!Das scheint keinen Sinn zu ergeben, wenn ich verstehe, wie der MBR aufgebaut sein sollte und was GNU parted ist.erreichen soll.
GNU Parted ist ein Programm zum Erstellen und Bearbeiten von Partitionstabellen.
Warum werden partedDaten in diese ersten 440Bytes geschrieben? Sind diese Bytes nicht für einen Bootloader gedacht? Sollte parted diese Bytes nicht in Ruhe lassen, wie fdiskes getan hat?
Antwort1
Es scheint, als wäre ichnichtDienureins zubeachtendieses Verhalten. Es scheint insbesondere in einigen armUmgebungen ein Problem zu sein, in denen ein Bootloader auf der Festplatte Probleme verursachen kann.
Das Problem besteht darin, dass parted den Code selbst (und stillschweigend) dort ablegt und das eingebettete System daher denkt, dass ein gültiger Bootloader-Code vorhanden ist und fröhlich hängen bleibt.
...Und...
Gibt es für Parted eine Option, um das Hinzufügen dieses Codes zu vermeiden (und sich wie fdisk zu verhalten)?
Es scheint, dass dieses Verhalten partedvonvorsätzlich. Wie ein Benutzer der partedMailingliste fragt:
Das Problem besteht darin, dass parted vom Anfang des MBR an folgenden Code generiert:
...
Was ist der Zweck dieses Codes? Warum wurde er dort eingefügt?
Und die Antwort scheint zu sein:
Dies ist der MBR-Bootcode, der normalerweise zum Booten eines BIOS-Systems verwendet wird. Wenn er auf einem Nicht-x86-System Probleme verursacht, sollten Sie ihn auf Null setzen (oder den System-Bootloader nach der Partitionierung schreiben).
Es scheint, dass mklabeles dafür ausgelegt ist, einen generischen Bootloader auf die Festplatte zu schreiben. Zumindest, wenn ein Label von msdosverwendet wird. Ichvermutendas macht Sinn, aber wenn man von fdiskund kommt syslinux, scheint es für einen Partitionsmanager etwas ungewöhnlich, Bootloader-Sektoren zu ändern.
Esscheintwie partedsolltenichtdiese Sektoren überschreiben, wenn Daten ungleich Null vorhanden sind.
Nein, es wird nur dann nicht geschrieben, wenn dort bereits etwas vorhanden ist (z. B. nicht 0x00). Wenn Sie also das SDK dazu bringen könnten, zuerst seinen Bootloader zu schreiben und ihn dann zu partitionieren, lässt parted ihn unberührt.
Das ist jedochnichtdas Verhalten, das ich sehe. Wenn ich Müll schreibe /dev/urandomund dann ausführe parted mklabel, werden meine Daten ungleich Null definitiv überschrieben.
Wenn ich die mbr.sDatei libpartedaus demgeteiltes Repo, ich kann sehen, woher diese Bytes kommen.
$ 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 istgenaudie Bytefolge, die partedauf meiner Festplatte zu generieren scheint.