Diskussion:Master Boot Record/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Master Boot Record/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Master_Boot_Record/Archiv/1#Thema_1

MBR-Signatur 0xAA55

ich habe eine frage bzgl der signatur: was ist das genau und ist es egal, wenn ich es mit zufaelligen daten ueberschreibe (fuer die funktionsweise der festplatte, nicht fuer die daten)? [estel] (nicht signierter Beitrag von 80.81.6.40 (Diskussion | Beiträge) 17:29, 19. Apr. 2004 (CEST))

es bedeutet das du von deiner Festplatte deinen Rechner nicht mehr starten kannst, aber alle Daten unversehert sind - Signatur mein dass es Versichert soll das es so ist... Julian 22:52, 15. Okt 2004 (CEST)

Gibt's deine Antwort auch auf Deutsch? --Orangerider 14:10, 1. Jun. 2007 (CEST)

Sei gnädig mit Julian – er ist offenbar kein deutscher Muttersprachler...

Ich denke, er wollte sagen, er ist sich sicher, daß es so ist (daß nämlich der MBR nicht mehr als solcher erkannt wird und deshalb auch die Partitionen nicht erkannt werden, aber die Daten noch da sind), aber daß das natürlich keine rechtsverbindliche Auskunft ist ;-) --Tobias 13:13, 1. Dez. 2010 (CET)

fdisk /mbr

"Notfalls kann man ihn auch mit dem Befehl "fdisk /mbr" unter DOS (bzw. einer Startdiskette) wiederherstellen." Der Parameter löscht den MBR doch eher? Wiederherstellen hört sich nach "eine Sicherung aufspielen" an. (nicht signierter Beitrag von 85.74.34.14 (Diskussion | Beiträge) 21:51, 21. Apr. 2005 (CEST))

seh ich auch so. (nicht signierter Beitrag von 195.4.0.127 (Diskussion | Beiträge) 09:12, 31. Aug. 2005 (CEST))

Sektor vs. Block

Zitat: "Bootblock (häufig fälschlicherweise auch Bootsektor genannt)" und zwei Zeilen drunter: "Bei einer Diskette ist kein MBR vorhanden, sondern nur ein Bootsektor" Ist das bei einer Diskette jetzt wirklich ein kompletter Sektor (also mehrere Datenblöcke)? --Philip Seeger 07:35, 5. Sep 2005 (CEST)

Sowohl der MBR einer Festplatte, als auch der Bootsektor einer Festplattenpartition und einer Diskette belegt genau einen Sektor (512 Byte). Welche Blockgrößen das Dateisystem anschließend verwendet, ist eine ganz andere Baustelle. --RokerHRO 08:07, 5. Sep 2005 (CEST)

Ich stimme Philipseeger zu, das ist etwas irreführend und sollte deutlicher erklärt werden. --Drccpp 11:59, 31. Okt 2005 (CET)

so auch ich, zumal Sektor in diesem Kontext explizit vom Datenblock abzugrenzen zu sein scheint. (-> Sektor: "in der Computertechnik bezeichnet ein Sektor die Summe aller Datenblöcke, die auf dem gleichen Winkelbereich des Datenträgers gespeichert sind. Insbesondere Dank Microsoft wird der Begriff Sektor häufig fälschlicherweise für einen Datenblock verwendet."). Ein MBR belegt somit auch keinen _Sektor_ sondern einen DatenBLOCK (bzw. Record). Einverstanden? --[84.158.136.191] 00:30, 17. Nov 2005 (CET)

Also dann dürfte es bei heutigen Datenträgern gar keine "Sektoren" mehr geben, da jede Datenspur anders "sektoriert" wird, nach außen werden es mehr Sektoren pro Spur. Dass "Sektor" bei Datenträgern heute synonym für "Kleinster Datenblock, der mit einem Befehl gelesen/geschrieben werden kann" verwendet wird, ist nicht Microsofts schuld, es war auch schon vor MS-DOS-Zeiten so üblich, mit "Sektor" eine 512-Byte-Einheit auf einer Diskette od. ä. zu bezeichnen. (Oder eben 256 oder 128 Bytes, bei antiquierten Diskettenformaten der 1970er). Die geometrische Bezeichnung für Sektor, wie du sie hier vorschlägst, ist in der Informationstechnik mehr als unüblich, da diese Zusammenfassung von Datenblöcken 1.) nicht ihrer logischen Reihenfolge entspricht 2.) für die meisten Datenträger nur sehr schwer zu ermitteln ist, da selbst Blöcke mit "gleicher Sektornummer" nicht notwendigerweise im gleichen "Winkelbereich" liegen. --RokerHRO 07:38, 17. Nov 2005 (CET)

mh verstehe thx, hatte mich hier gutglaeubig auf den Wikipedia-Eintrag 'Sektor' bezogen, alles vor MS-DOS war auch vor meiner Zeit ;) Obendrein erschloss sich auch mir der Sinn und Zweck dieser angeblichen Konvention einer geometrischen Zusammenfassung nicht wirklich, waere dann wohl dienlicher den gn. Unterpunkt bei 'Sektor' rauszunehmen..? --[ehemals 84.158.136.191] 16:55, 17. Nov 2005 (CET)

Ich habe den Artikel Sektor entsprechend geändert und auf der Diskussionsseite diese Änderung begründet. IMHO ist die Meinung von Benutzer:Bodo Tiesen da ein wenig "extrem", vor allem wenn ich mir seine Benutzerseite dazu durchlese. ;-) --RokerHRO 09:15, 18. Nov 2005 (CET)

Unter unixoiden Betriebssystemen werden Dateigrößen in Blöcken angegeben. Ein Block unter Unix/Linux ist das was Windows mit Zuordnungseinheit bzw. Cluster meint. Mit ls - l (dir-Befehl unter DOS) werden Dateigrößen in Böcken angezeigt. Demzufolge kann man 512-Byte-Einheiten unter Unix/Linux nicht auch als Block bezeichnen, sonst wüsste man nicht was gemeint ist. Bleibt der Begriff Sektor.--Datagau 16:45, 27. Jun. 2010 (CEST)

Weitere Bedeutung: Master Of Business Research

Weitere Bedeutung: Die Universität München verleiht einen "Master of Business Research (MBR)" als akademischen Grad. Er schließt das postgraduale Forschungsstudium (Promotionsstudium) an der Fakultät für Betriebswirtschaft ab. Das Forschungsstudium ist von allem Doktoranden der Fakultät zu absolvieren und ersetzt die Disputation im Dissertationsverfahren.

Weitere Infos: BWL-Fakultät der LMU München(nicht signierter Beitrag von 84.154.85.185 (Diskussion) 12:17, 23. Okt. 2005 (CEST))

Stammt dieser Diskussionsbeitrag aus Zeiten vor einer Verschiebung des Artikels? Unter MBR gibt es jedenfalls eine Begriffsklärung mit einem entsprechenden Eintrag. Dieser Diskussionsabschnitt kann m. E. gelöscht werden. --Tobias 10:54, 1. Dez. 2010 (CET)

Tabelle, die den Master Boot Record veranschaulicht

Ich habe unter Benutzer:RokerHRO/Partitionstabelle mal eine Tabelle gebaut, die einen exemplarischen Master Boot Record enthält und die vier (primären) Partitionen farblich hervorgehoben. Was haltet ihr davon, diese mit in den Artikel aufzunehmen? --RokerHRO 10:33, 5. Nov 2005 (CET)

super Idee, finde ich. --[84.158.136.191] 00:30, 17. Nov 2005 (CET)

Mehrere Unkorrektheiten

1. Der erste Absatz zum Thema ist eigentlich falsch, da beispielsweise eine Diskette ein bootfähiges Medium sein kann, aber über keinen MBR verfügt. Die Herkunft des MBR zu erklären wäre jetzt etwas lang.

Warum? Dafür ist ein Enzyklopädie-Artikel doch da, auch längere Erklärungen aufzunehmen, sofern sie zum Verständnis des im Artikel behandelten Gegenstandes dienen. Schreibs einfach rein. :-) --RokerHRO 08:21, 12. Mär 2006 (CET)

2. Die Erklärung "Bei einer Diskette ist kein MBR vorhanden, sondern nur ein Bootsektor, da sich auf einer Diskette keine Partitionen befinden." ist historisch falsch, da zuerst der Bootsektor da war - nämlich an Position 0:0:1 (Kopf 0, Spur 0, Sektor 1) - und für die erst später entwickelten Festplatten wegen ihrer Multi-Betriebssystem-Lademöglichkeit eine andere Lösung gefunden werden musste, um die 0:0:1-Konvention nicht umzustossen. Daher wurde der eigentliche Bootsektor um eine zusätzliche Laderoutine ergänzt, die nunmehr die heute bekannten BS-Ladevorgänge ausführt. Um es auf die Spitze zu treiben: Mit der MBR-Lösung liesse sich sogar eine Diskette partitionieren, was allerdings keinen praktischen Nutzen hat (aber zu Demo-Zwecken mal ein interessantes Projekt).

Prima! Nun hast du ja schon fast die Begründung für die historische Entwicklung zum MBR geschrieben. :-) --RokerHRO 08:21, 12. Mär 2006 (CET)

3. Der Bootloader sucht nicht nach einer aktiven Partition. Vielmehr ist es so, dass die 4 für den Zustand "aktiv/nicht aktiv" zuständigen Bytes daraufhin überprüft werden, ob sie die Werte 80h oder 00h aufweisen (binär: 1000 0000 oder 0000 0000; es geht also eigentlich nur um 1 Bit). Ist genau einer der Werte 80h und die anderen genau 00h, wird die durch den zugehörigen Partitionseintrag lokalisierte Partition als aktive Partition behandelt. Daraus leitet sich dann auch ab, von welcher Position der zugehörige Bootsektor zu laden ist.

Was der Bootloader im MBR macht, mag variieren. Was der Original-Bootloader von IBM, der mit den ersten Festplatten-PCs aufgeliefert wurde, genau macht, weiß ich nicht, da ich diesen Code nicht hier habe. Ob es von IBM eine Spezifikation gibt/gab, was ein "Standardkonformer MBR-Code" zu machen hat, weiß ich auch nicht. Kannst ja gerne mal recherchieren dazu. Heutige Bootloder dagegen machen es mal so, wie von dir beschrieben, mal scheren sie sich nicht um dieses Byte, weil sie ihre eigene Config irgendwo auf der Platte haben. --RokerHRO 08:21, 12. Mär 2006 (CET)

Grundsätzlich Zustimmung. Andererseits muss jeder Bootloader entscheiden können, welche von mehreren "aktiven" Partitionen - und somit das zu startende Betriebssystem - denn nun geladen werden soll. Diese Entscheidung kann selbstverständlich auf unterschiedlichste Weise getroffen werden. --Rouso 02:58, 29. Mär 2006 (CEST)

Eben. Das Bootflag ist eine Konvention, an die sich manche Bootmanager halten, manche nicht. --RokerHRO 08:04, 29. Mär 2006 (CEST)

4. Besonders falsch ist der Begriff "erste aktive Partition", denn es kann nur eine geben. Wären es mehrere, gäbe es eine Fehlermeldung.

Wie gesagt, das mag von Bootmanager zu Bootmanager variieren. Ein primitiver mag einfach die erste "bootfähige/aktive" Partition starten, ein anderer mag nach weiteren aktiven Partitionen suchen, ein dritter macht wieder was anderes. Was der "Standard" macht/vorschreibt, weiß ich nicht, da ich ihn nicht hier habe. --RokerHRO 08:21, 12. Mär 2006 (CET)

s. o. --Rouso 02:58, 29. Mär 2006 (CEST)

5. Hinsichtlich der Bootmanager wird die Bedeutung des MBR deutlich unterschätzt, da das BIOS grundsätzlich zunächst den ersten physikalischen Sektor lädt und den enthaltenen Code ausführt, bei dem es sich auch um einen Bootmanager handeln kann, der dann weitere Optionen zur Verfügung stellen kann.

Meist ist ja ein Teil eines komfortableren Bootmanagers im MBR untergebracht, der den Rest des Bootmanagers nachlädt. --RokerHRO 08:21, 12. Mär 2006 (CET)

Das wollte ich mit obiger Darstellung zum Ausdruck bringen. --Rouso 02:58, 29. Mär 2006 (CEST)

Aha. --RokerHRO 08:04, 29. Mär 2006 (CEST)

6. Intelligente Bootmanager gibt es schlicht und ergreifend nicht.

"intelligent" im Sinne von "tut mehr als einfach die erste aktive Partition starten" oder im Sinne von "interaktiv, mit Auswahlmenü und allem Pipapo". --RokerHRO 08:21, 12. Mär 2006 (CET)

Also "intelligent" nicht im Sinne von "intelligent" ;) --Rouso 02:58, 29. Mär 2006 (CEST)

Definitionssache. Heutzutage werden viele technische Systeme ja als "intelligent" bezeichnet, sobald sie schlicht nicht mehr ganz so primitiv sind wie die Konkurrenz. Wenn dir ein besseres Wort dafür einfällt, bitte, dann ändere es entsprechend. --RokerHRO 08:04, 29. Mär 2006 (CEST)

7. Während die Signatur tatsächlich als ziemlich unantastbar gilt, soll von der Festplatte gebootet werden können, ist es hinsichtlich der Partitionseinträge ein zweischneidiges Schwert: Wer nicht weiss, wo er da was operiert, wird bald Hilfe benötigen. Andererseits sind hier auch Möglichkeiten vorhanden, Festplatten unter ganz bestimmten Bedingungen und in bestimmten Grenzen on-the-fly umzupartitionieren.

Soweit ich weiß, wird die Signatur bereits vom BIOS geprüft (das BIOS sollte dies jedenfalls tun), noch bevor der (vermeintliche) Code im MBR ausgeführt wird. In Zeiten, wo man sich aber ein eigenes (auch Open Source) BIOS flashen kann, ist nicht einmal das mehr garantiert, dass das auf jedem PC auch geschieht. --RokerHRO 08:21, 12. Mär 2006 (CET)

Stimmt: Da das BIOS anhand der Signatur entscheidet, ob der MBR startfähig ist und diesen ggfs. lädt, kann folglich der MBR-Code erst ausgeführt werden, nachdem das BIOS sein OK gegeben hat. In "normalen" MBR-Boot-Loadern wird dann der Boot-Sektor der zu ladenden Partition geladen und geprüft, ob dessen Signatur ebenfalls 0xAA55h und der Sektor somit startfähig ( = bootfähig) ist. --Rouso 02:58, 29. Mär 2006 (CEST)

Ich hab nichts anderes behauptet. :-) Im Übrigen gilt das für fast jedes System: "Wenn man keine Ahnung hat, was man da rumfummelt, kann das System unter Umständen hinterher nicht mehr so funktionieren, wie vorher." Das muss man also nicht extra erwähnen, oder? --RokerHRO 08:04, 29. Mär 2006 (CEST)

8. Der Befehl fdisk /mbr ist sicherlich hilfreich, und er wird inaktive Viren im MBR (und nur dort) entfernen können. Aktive Bootsektor-Viren mit Stealth-Fähigkeiten (Stealth-Viren) leiten den Befehl auf einen anderen Sektor um und spiegeln diesen als vermeintlichen MBR ein (entsprechenden Assemblercode hatte ich in grauer Vorzeit zu Testzwecken mal selbst erstellt; wenn man nicht mit eigenen Augen sieht, zu was solcher Code fähig ist, kann man es kaum glauben).

Richtig.

9. fixmbr ist für den MBR zuständig, fixboot für die Bootsektoren.

10. Die Sektor/Block-Diskussion erscheint müssig, da es wohl um Sektoren und Cluster (die aus Sektoren bestehen) zu gehen scheint.

Da es hier um eine technische Sache geht, sollte man die technischen Begriffe verwenden. In technischen Dokumentationen, z.B. Standards, zum Thema Festplatten finde ich nur den Begriff "Sektor" für eine "512-Byte-Einheit auf einem Speichermedium, die in einem Zuge gelesen/geschrieben werden kann". Blöcke und Cluster sind IMHO Begriffe, die erst auf Dateisystem-Ebene existieren, da diese meist mehrere Sektoren (i.S.v. obiger Definition) zu einer "Verwaltungseinheit" zusammenfassen. --RokerHRO 08:21, 12. Mär 2006 (CET)

Zustimmung. Jedoch ist m. E. bei der technischen Darstellung des Sektors die Beschränkung auf 512 Daten-Bytes zu wenig. Andererseits erscheint es zu diesem Thema ausreichend. --Rouso 02:58, 29. Mär 2006 (CEST)

Es wurden ja schon Festplatten mit größeren Sektoren angekündigt. Wie es da mit Partitionssektoren usw. aussieht, bleibt abzuwarten, so lange man noch nix genaueres weiß. --RokerHRO 08:04, 29. Mär 2006 (CEST)

Das wollte ich jetzt mal zur Diskussion stellen.

Gut so. Diskussionsseiten sind ja zum Diskutieren da. :-) --RokerHRO 08:21, 12. Mär 2006 (CET)

Die Zeile dd if=/dev/null of=/dev/hd[alte] bs=1 count=4 seek=440. alte>=b im Text würde alle Daten auf der Festplatte löschen. Was soll diese Zeil. Es gibt weder eine warnung, noch passt sie in den Kontext.

Zusammenlegen mit Partitionstabelle?

Ich wäre dafür, diesen Artikel mit Partitionstabelle zusammenzulegen, oder aber die Unterschiede deutlicher zu machen. Derzeit behandeln beide Artikel nahezu das gleiche. :-/ Was sagt ihr dazu? --RokerHRO 08:42, 27. Mär 2006 (CEST)

Ich würde nicht zusammenlegen. Für mich war der Artikel, als ich ihn zum ersten Mal gelesen habe, hilfreich. Ich finde es auch nicht so schlimm, wenn es Redundanzen zwischen einzelnen Artikeln gibt. Das ist besser, als wenn man zwischen Artikeln springen muss, um es zu verstehen.

Ganz im Sinne von Unterschiede deutlicher machen habe ich den Artikel ein bisschen überarbeitet. Bin noch nicht ganz zufrieden. ;-)

Wichtig finde ich dass klar wird: MBR = Bootsektor + Partitionstabelle für Speichermedien, die beides sind: partitioniert und bootfähig. --Martin 11:19, 28. Mär 2006 (CEST)

Bei der Zusammensetzung würde ich noch mindestens einen Schritt weiter gehen: MBR = BootLoader + Partitionstabelle + Startkennung. Dies sind m. E. die drei elementaren Bestandteile eines MBR. Zur Abgrenzung: Bootsektor = BootLoader + Startkennung. --Rouso 03:21, 29. Mär 2006 (CEST)

Ich würde auch nicht zusammenlegen. Wer nach "Partitionstabelle" sucht, wird nicht automatisch als Suchbegriff "MBR" eingeben. Im MBR-Artikel sollte die Beschreibung der Partitionstabelle sparsamer ausfallen, dafür dann ein Link zum Partitionstabellen-Artikel enthalten sein. --Rouso 03:21, 29. Mär 2006 (CEST)

Bisher behandeln beide Artikel aber irgendwie beides, mehr oder weniger gut. Gewisse Überschneidungen lassen sich sicher nie vermeiden, aber dass beide Themen jeweils in beiden Artikeln behandelt werden, find ich nicht so gut. Außerdem behandeln beide Artikel nur die Situation auf "IBM-kompatiblen PCs". Wie sieht das denn auf anderen Plattformen aus? --RokerHRO 07:57, 29. Mär 2006 (CEST)

Zu Überschneidungen: Ich habe aus der Tabelle zum MBR die einzelnen Einträge der Partitionstabelle rausgenommen. Die werden ja unter [Partitionstabelle] genauer erläutert.

RokerHRO: Ich finde, dass die Überschneidungen diese Artikels mit Partitionstabelle nun minimalst sind. Oder? Wenn du in dieser Richtung noch Verbesserungsmöglichkeiten siehst, dann wäre es hilfreich, wenn Du evtl. unnötige Redundanzen konkret benennen könntest. Grüße --Martin 15:56, 31. Mär 2006 (CEST)

Okay, so ist das schon viel besser. :-) --RokerHRO 15:52, 14. Jun 2006 (CEST)

Sektor -1 ist hier eher verwirrend

Habe den folgenden Abschnitt aus der Einleitung entfernt und erstmal hierhin verschoben. Ich finde, das ist zu speziell und sollte vielleicht in den Artikel Festplatte.

"Allerdings gibt es auf modernen Festplatten noch vor diesem Bereich einen Sektor, in dem die Festplatten Daten über ihre eigene Organisation gespeichert haben, dieser Sektor ist aber im Normalfall für den Computer(nutzer) nicht erreichbar. "

--Martin 11:19, 28. Mär 2006 (CEST)

Disk-Signatur bei Windows 2000

Vorübergehend stand im Abschnitt folgende Frage:

Wie entsteht diese Signatur? Was soll sie bewirken?

Soweit ich weiß, geht die Disk-Signatur der System-Festplatte auch in die PID(?), die eindeutige Hardwarekennung der Windows-Installation ein. Bin da aber nicht ganz sicher. Kann jemand helfen? --Martin 11:29, 21. Apr 2006 (CEST)

Im Abschnitt Disk-Signatur finde ich, dass der Linux(oder was auch immer das ist)-Befehl ziemlich vom Himmel fällt. Was soll dieser Befehl in diesem Kontext?

Danke für den Hinweis. Ich hab da Kontext zugefügt und auch die Microsoft-Befehle aufgeführt. Bei der Gelegenheit hab ich den Abschnitt ergänzt und versucht es mit dem Beispiel der Laufwerksbuchstaben konkreter zu machen. Der Abschnitt hat jetzt ein bisschen How-to-Charakter, aber aus eigener Erfahrung interessiert man sich für die Disk-Signatur eigentlich erst dann, wenn sie Probleme bereitet, oder :-) Kommentare? Ist das schwer verständlich? ...? --Make 12:39, 28. Jan. 2007 (CET)

Master Boot Record vs. Boot Sector

Ich meine den Unterschied zw. beiden verstanden zu haben und im Zusammenhang mit dem Bootvorgang mag da auch kein Problem auftreten. Mich interessiert jedoch weniger der vorgang des Bootens als mehr das Erkennen des auf dem Medium vorhandenen Dateisystems. Im speziellen geht es um MMC/SD Cards, von denen nicht zwingend gebooted werden soll, aber von denen / auf die Daten filesystemkonform gelesen / geschrieben werden sollen. Die relevanten Informationen um zu erkennen, um welches Dateisystem es sich handelt (zumindes für FAT) sind meines Wissens im Boot Sector (auch als Volume Boot Record bezeichnet) enthalten, der laut dem Artikel ("Speichermedien, die nicht in Partitionen unterteilt sind, z. B. Disketten oder CDs, enthalten keinen MBR. Hier wird der erste Datenblock als Bootsektor oder auch Boot Record bezeichnet.") u.U. in Sector 0 zu finden ist. Handelt es sich jedoch um ein partitioniertes Medium, ist er im Sector 0 der jeweiligen Partition zu finden und an Sector 0 des Mediums liegt ein Master Boot Record, der die Partitionstabelle und damit die Start-Sektoren von bis zu 4 Partitionen enthält. So weit so gut. Woher nehme ich denn aber die Information, ob ein Medium partitioniert ist oder nicht? Bzw. Wer sagt mir denn ob ich auf Sector 0 des Mediums einen MBR oder einen Boot Sector gelesen habe? Gibt es einen eindeutigen Unterschied zw MBR und Boot Sektor, an dem sich sicher erkennen lässt um welchen der beiden es sich handelt? (nicht signierter Beitrag von Dizzyone (Diskussion | Beiträge) 13:21, 15. Apr. 2008 (CEST))

Nein, einen eindeutigen Unterschied gibt es nicht. Man kann nur heuristisch herangehen und den Sektor 0 nacheinander eben erst als Master-Boot-Record und dann als Bootblock bekannter und unterstützter Dateisysteme interpretieren und gucken, was passt.

Die meisten Betriebssysteme machen dies aber nicht, sondern erwarten einfach bei Festplatten und Speicherkarten (und ZIP-Disketten, falls die noch jemand kennt) und USB-Sticks, dass diese stets partitioniert sind und bei Disketten und CDs/DVDs, dass sie nicht partitioniert sind. Wenn man das ändert, wird das Medium vom Betriebssystem nicht mehr korrekt erkannt.

Bei unixoiden Betriebssystemen werden für das Gesamtmedium und die ggf. vorhandenen Partitionen verschiedene Gerätedateien angelegt. So kann man unter Linux auf einen USB-Strick auch direkt auf /dev/sda ein Dateisystem anlegen und dieses mounten, anstatt der 1. Partition (/dev/sda1). --RokerHRO 14:32, 15. Apr. 2008 (CEST)

Ich finde es unglücklich, daß vom Bootsektor direkt zum Master Boot Record umgeleitet wird; wer nach Informationen zu ersterem sucht (weil es ihn z. B. nervt, daß ein bestimmter USB-Stick immer das Hochfahren aus dem Ruhemodus verzögert oder „mangels eines Betriebssystems“ blockiert), steht m. E. hier erstmal ziemlich im Wald.

Kann man den Unterschied wie folgt sehen (Fehler und Ungenauigkeiten bitte ggf. korrigieren):

• Ein Bootsektor ist der erste Sektor eines nicht partitionierten Datenträgers; er enthält Programmcode, der ein Betriebssystem startet oder die Kontrolle an das BIOS zurückgibt
• Der MBR ist der erste Sektor partitionierter Datenträger wie z. B. Festplatten; er enthält in den ersten 440 Bytes den Bootloader, der in diesem Fall die weiter hinten stehende Tabelle der primären (und maximal einer „erweiterten“) Partitionen liest (die ihrerseits Bootsektoren haben) und darüber entscheidet, von welcher der primären Partitionen gestartet wird; der jeweilige Bootsektor wird dann ausgeführt. Die letzten beiden Bytes enthalten einen festen Wert, die MBR-Signatur.

Man könnte also sagen, daß der MBR ein Spezialfall eines Bootsektors ist, der eine Partitionstabelle enthält, speziellen Konventionen folgt und deshalb für den Bootloader weniger Platz hat.

Wenn dem so (oder so ähnlich) ist, bin ich der Meinung, daß beides definitiv unterschiedliche Dinge sind und auch in unterschiedlichen Artikeln behandelt werden sollten. --Tobias 11:58, 1. Dez. 2010 (CET)

Funktionsweise bei Linux-Bootloadern

Wenn man Linux benutzt, muss man doch nicht zwingend eine primäre Partition haben. Kann es sein das dann direkt aus dem MBR raus, die stage1 von GRUB aufgerufen wird (diese wird an einen festen Platz auf der Partition abgelegt)?

Bootmanager wie GRUB benötigen die Markierung von "aktiven" Partitionen nicht. Lilo speichert direkt im MBR die Adresse des Kernelimages, egal wo es liegt. GRUB dagegen versteht sogar das Dateisystem, um entspr. Dateien zu finden. Übrigens können auch logische Partitionen als aktiv/startbar markiert werden.

Leider fehlt im Artikel eine Beschreibung von GRUB gänzlich. LILO gilt heute als überholte Technik. So viel ich weiss wird LILO auch nicht mehr wirklich entwickelt. -- Thomei08 23:55, 7. Sep. 2009 (CEST)

Habe den Abschnitt Linux total überarebeitet. Jetzt ist alles geanu erklärt. -- Thomei08 13:36, 10. Sep. 2009 (CEST)

„intelligenten“ Bootmanager

Mich würde mal interessieren was damit gemeint ist? Sicher nicht die LILO. Auf GRUB könnte das schon eher zutreffen. Grundsätzlich finde ich aber solche Formulierungen total überflüssig. -- Thomei08 00:01, 8. Sep. 2009 (CEST)

Habe den Abschnitt total überabeitet. Die feagwürige Formulierung habe ich entfernt. -- Thomei08 13:33, 10. Sep. 2009 (CEST)

Fehlende Information zu Linux-Bootloadern?

Es wurde markiert, dass weitere Informationen zu den Unix-Systemen und ihrer Bootloader gegeben werden soll. Was genau ist gemeint, eine Info über GRUB?(krenon@web.de <-Konakt wenn gewünscht)

Ich habe die den Abschnitt Linux total überarbeitet. (Ergänzungen und Korrekturen sind willkommen) Das Hauptgewicht liegt jetzt auf GRUB, da andere Bootloder stark an Bedeutung verlohren haben bei Linux. Die LILO wird aber auch erklärt. Zu BSD oder OSX und andern UNIX-Vatianten felen mir die Inforamtionen. Es wäre auch sehr intressant mehr über den MBR von OpenVMS oder anderen nicht UNIX's zu erfahren. -- Thomei08 13:32, 10. Sep. 2009 (CEST)

Etwas zu Windows- und Fehlerbehebungsbezogen

So schön es auch in der Not sein mag, sollte meiner Meinung nach kein Artikel zu einem How-To verkommen. Leider bewegt sich dieser Artikel etwas auf ein "Windows-Bootloader fixen 101" zu und geht nicht genauer auf den technisch MBR ein, und dessen Geschichte. Meiner Meinung nach sollten alle Anleitungen zum reparieren des MBR in einen eigenen Abschnitt/in einen eigenen Artikel/gelöscht werden. Wie ich nun Windows dazu bringe mir meinen MBR zu überschreiben hat leider herzlich wenig mit dem MBR an sich zu tun. -- 84.74.174.177 02:21, 15. Mai 2010 (CEST)

MBR-Signatur 0xAA55, oder 0x55AA?

Moin, so wie ich die Tabelle von "Aufbau des MBR" verstehe, steckt in ihr ein Widerspruch. Es steht dort, dass an Position 0x01FE der Wert 55_hex und an Position 0x01FF der Wert AA_hex steht. Jedoch direkt danach steht (0xAA55), was genau anders herum ist. Ich habe eine leeren ersten Sektor mit fdisk unter Linux neu beschreiben lassen und an die Position 0x01FE geguckt und dort steht aa_hex gefolgt von 55_hex. Oder verstehe ich nur die Tabelle falsch? GGF ist auf der Seite Partitionstabelle der selbe dreher. Gruß -- Liepa 21:31, 4. Aug. 2011 (CEST)

Wie hast du denn dir den Sektor angeguckt? Btw, dein PC ist eine Little Endian-Architektur, wie im Abschnitt Master Boot Record#MBR-Signatur auch erklärt wird. --RokerHRO 22:52, 4. Aug. 2011 (CEST)

# dd if=/dev/sda bs=512 count=1 | hd 1+0 Datensätze ein 1+0 Datensätze aus 512 Bytes (512 B) kopiert, 1,3065e-05 s, 39,2 MB/s 00000000 fc 31 c0 8e d0 31 e4 8e d8 8e c0 be 00 7c bf 00 |.1...1.......|..| 00000010 06 b9 00 01 f3 a5 be ee 07 b0 08 ea 20 06 00 00 |............ ...| 00000020 80 3e b6 07 ff 75 04 88 16 b6 07 80 3c 00 74 04 |.>...u......<.t.| […] 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.|

Also, bei meinem PC steht das genau so drin, wie im Artikel beschrieben. :-) --RokerHRO 22:59, 4. Aug. 2011 (CEST)

Und wieder was gelernt. Es steht richtig da, ich wusste nur nicht wie man es ließt. So sieht es so aus wie bei dir:

# dd if=/dev/sda bs=512 count=1 2>/dev/null | hd | grep 00001f0 000001f0 01 02 83 1f a0 94 00 10 20 01 00 94 b4 e7 55 aa |........ .....U.|

Aber, wenn man so guckt, dann sieht es anders aus:

# dd if=/dev/sda bs=512 count=1 2>/dev/null | hexdump | grep 00001f0 00001f0 0201 1f83 94a0 1000 0120 9400 e7b4 aa55

Also ist ab Position 00001fe der Wert (0xAA55), mit dem Wert 55_hex an Position 00001fe und dem Wert AA_hex an Position 00001ff, oder nicht? -- Liepa 20:26, 5. Aug. 2011 (CEST)

Überschreiben der Windows-Disk-Signatur mittels dd

Im Abschnitt Disk-Signatur steht beschrieben, wie man mittels eines dd-Befehls die Windows-Disk-Signatur im MBR mit Nullen überschreiben kann. Jedoch erschließt sich mir jetzt nicht wirklich, zu was das gut sein soll. Es wäre gut, wenn man den Nutzen noch nennen würde. --GGShinobi (Diskussion) 13:43, 9. Jul. 2012 (CEST)

Vielen Dank an Thomei08 für die schnelle Ergänzung! :-) --GGShinobi (Diskussion) 12:37, 15. Jul. 2012 (CEST)

Bootsektorcode – wann wird er ausgeführt?

Ich hab auf folgende Frage bisher nicht wirklich eine Antwort gefunden ich denke es würde hier z.T. ganz gut passen: Was passiert wenn ich eine externe Festplatte/Stick an den Rechner anschließe (bei gebootetem OS)? Wird bei dem Datenträger dann der ganze MBR ausgelesen oder nur die Partitionstabelle? Wird bspw. im Bootloader liegender Schadcode (also Code der unbedingt ausgeführt werden möchte) ignoriert? Wird die Partitionsabelle direkt angesprungen? Wenn ich das richtig verstanden habe können in der Partitionstabelle nur Partitionierungsanweisungen liegen. Könnte derartiges durch Schadsoftware in irgendeiner Form benutzt werden?

Eine weitere Frage wäre, ob eine -kompromitierte- Festplatte die neben der Bootplatte läuft und vom BIOS nur 'als vorhanden und betriebsbereit' eingelesen aber kein Bootversuch von ihr unternommen wird das System in irgendeinerweise beschädigen kann, z.B. weil dieser 'Betriebsbereitcheck' irgendwie ausgenutzt wird. (gehört evtl. mehr zum Artikel BIOS hat aber auch mit dem MBR zu tun)

Was ich mich dann noch gefragt habe, hier auf der Disku-Seite wird davon gesprochen wie man ein Laufwerk ohne MBR einrichtet, wie macht man sowas und welche Kompatibilitäts- sowie (Un-)Sicherheitsaspekte hat die erstellte Partition bzw. das erstellte Dateisystem.

Gruß (nicht signierter Beitrag von 109.45.0.78 (Diskussion) 18:07, 4. Mär. 2013 (CET))

Eigentlich ist das hier kein Forum. Fragen sollten den Artikel – dessen Inhalt und/oder Qualität – betreffen. Aber gut.

Soweit mir bekannt, führen moderne Betriebssysteme den Code im Bootsektor nicht aus. Das ginge auch schwer, ist der Code doch im 16-Bit-Real-Mode während sich ein modernes Betriebssystem zumindest im 32-Bit-Protected-Mode befindet.

DOS (und damit auch Windows 9x) war das letzte Betriebssystem, unter dem Bootviren eine wesentliche Gefahr darstellten. Damals vergaß man auch schon mal schnell eine Diskette im Laufwerk beim Booten, merkte aber nichts, weil das Virus einfach still und heimlich die Festplatte (den MBR) infizierte und anschließend das Betriebssystem startete.

Diese Gefahr besteht grundsätzlich auch heute noch. Denn auch Windows 7 32-Bit wird noch vom MBR aus gestartet. Das Virus müsste jedoch ziemlich komplex sein damit Windows wirklich beeinträchtig wäre. Unter DOS genügte ja schon das verbiegen der BIOS-Calls – diese nutzt Windows jedoch nicht mehr.

Dies gilt analog für CDs und externe Festplatten.

Genaueres weiß ich aber auch nicht.

Zum Thema „Formatieren ohne Partitionieren“: einfach machen! Unter Windows: C:\Windows\system32\diskmgmt.msc ausführen und sehen ob es möglich ist. Unter Linux/Unix ist es sowieso kein Thema. Unter OS X habe ich es noch nie probiert: mit Disk Utility einfach ausprobieren! Es gibt auch unter Windows und OS X Kommandozeilenwerkzeuge, um ein Speichermedium zu formatieren/partitionieren. Manuell geht es immer irgendwie ohne Partitionstabelle. Andere Betriebssysteme, wie OS/2, BeOS/Haiku, AmigaOS, MorphOS und viele weitere, die ich nicht erwähne, können das vermutlich auch…

DOS bootet übrigens nur von einer primären Partition und duldet nur genau eine Primärpartition: weitere Partitionen müssen in einer erweiterten Partition sein, damit DOS ihnen einen Laufwerksbuchstaben zuweist.

Windows XP bootet nicht von einem Protective MBR aus, der für Windows eine Partition sowohl im MBR als auch GPT eingetragen hat. Das heißt, Windows bootet schon, aber nur bis es diesem Umstand bemerkt: dann kommt ein BSOD.

Windows Vista 64-Bit und neuer (nur 64-Bit) sieht nur noch GPT vor. MBR wird auf 64-Bit-Systemen nur von Windows XP x64 unterstützt. Fehlinformation! Falsch! ‣Andreas•⚖ 20:23, 4. Mär. 2013 (CET)

‣Andreas•⚖ 18:29, 4. Mär. 2013 (CET)

das ist so nicht korrekt ... MBR wird auch unter W7 64Bit unetrstützt ... wenn ich mich recht erinnere habe ich auch w8/64 auf eienr MBR-Partition getestet

--Nobby1805 (Diskussion) 20:10, 4. Mär. 2013 (CET)

Stimmt! Mein Fehler: nur auf EFI/UEFI-Systemen (die eigentlich immer 64-Bit-Systeme sind) wird GPT verwendet. Auf BIOS-Systemen (sowohl 32- als auch 64-Bit) wird MBR verwendet.

Entschuldigung, wenn diese Fehlinformation Verwirrung verursacht haben sollte. ‣Andreas•⚖ 20:23, 4. Mär. 2013 (CET)

UEFI hat einen Kompatibilitätsmodus und kann auch von MBR booten. --MrBurns (Diskussion) 22:03, 4. Mär. 2013 (CET)

Stimmt auch wieder. Das Compatibility Support Module ist als Übergang gedacht, um bestehende Hard- und Software weiter verwenden zu können.^{link 1 – 2.} Jedoch kommt es zu Problemen bei Dual-Boot-Installationen (von derselben Festplatte) mit einem EFI-Betriebssystem (das auf GPT-Partitionen installiert sein will) und mit einem BIOS(=CSM)-Betriebssystem (das von MBR booten will).^link

Lösungen gibt es, aber sie haben immer auch einen Pferdefuß und/oder sind nicht so einfach zu bewerkstelligen (z.B. Chameleon, rEFIt, MBR+GPT-Dual-Partitionstabelle).

So oder so: 1) BIOS oder (U)EFI-CSM → MBR, 2) UEFI → GPT.

‣Andreas•⚖ 22:39, 4. Mär. 2013 (CET)

Ist das auch von irgendeiner praktischen Relevanz? Daher gibt es Betriebssysteme, die sich nicht auf MBR-Partitionen installieren lassen? Die x86/x64-Versionen von Windows 7/Windows 8 unterstützen jedenfalls neben GPT auch MBR. --MrBurns (Diskussion) 22:47, 4. Mär. 2013 (CET)

Ich höre zum ersten Mal davon, dass sich ein Betriebssystem im UEFI-Modus auf MBR installieren lässt. Eher nicht.^link

Man kann es schon machen, aber dann ist viel Handarbeit gefordert. Wenn man sich um den Bootloader selber kümmert, warum sollte es nicht gehen? Doch halt – da war ja noch was: Beispiel Windows XP: auf einem MBR/GPT-Dual-System mit installiertem Windows 7 und Linux (beide UEFI, GPT-EFI-Boot-Partition mit EFI-Bootloader) auf der einen Seite und Windows XP (Partition ist im MBR vorhanden, also 1. protective MBR, 2. XP-Partition) auf der anderen Seite startet Windows XP dennoch nicht. Manche Betriebssysteme prüfen einfach zu viel und verweigern, wenn diese Prüfung nicht gelingt. XP unterstützt in diesem Fall auch GPT als Datenpartition – und findet diese beim Booten. Natürlich ist im GPT auch die Windows XP-Partition vorhanden (1. EFI-Boot, 2. Windows 7, 3. Linux, 4. Windows XP – die 1.-3. GPT-Partition ist im MBR als Protective MBR maskiert, die 4. Partition ist jeweils identisch). Windows XP verweigert nun den Start, weil es entdeckt, dass ein aktiver GPT vorhanden ist. Das wäre nicht nötig, da ja auch ein funktionaler MBR da ist. Aber sei’s drum. So ist es eben.

In diesem Zusammenhang würde ich gerne wissen, wie Bootcamp das macht…

Ebenfalls von praktischer Relevanz ist, dass sich im EFI-Modus keine MBR-Partition als Installationsziel verwenden lässt. Dabei kann EFI ja mittels CSM booten, es sollte daher funktionieren. Ist wohl eine Schutzfunktion: da das Installationsmedium im UEFI-Modus gestartet wurde, wird es diesen Modus auch für die Installation erwarten, und UEFI will eben von GPT starten. Umgekehrt ist es ebenso. Obwohl man ja ein EFI nachprogrammieren kann und somit ein auf MBR installiertes Betriebssystem im EFI-Modus starten könnte. Der Clover EFI bootloader ist so ein Beispiel. Er kann auf einem BIOS-Computer ein EFI bereitstellen und dann ein EFI-Betriebssystem starten. Wenn das Betriebssystem das jedoch nicht weiß, wird es sich nicht auf MBR installieren lassen, auch, wenn ein Betrieb auf MBR prinzipiell möglich wäre.

‣Andreas•⚖ 18:45, 5. Mär. 2013 (CET)

Nachtrag: Hier ist eine gute FAQ darüber. Windows kann laut dieser Quelle nicht von GPT booten, wenn es im BIOS-Modus läuft. Linux mit GRUB schon (anscheinend…).
Und noch eine gute Quelle. ‣Andreas•⚖ 19:03, 5. Mär. 2013 (CET)

Mit Daher gibt es Betriebssysteme, die sich nicht auf MBR-Partitionen installieren lassen? meinte ich eines, das garnicht von MBR booten kann, also auch nicht bei BIOS oder CSM. Was du schreibst ist mMn eher irrelevant, weil man ja das CSM je nach Bedarf ein- und ausschalten kann. --MrBurns (Diskussion) 20:13, 5. Mär. 2013 (CET)

Irrelevant? Wenn man in einer Multi-Boot-Umgebung ständig ins “BIOS-Setup” (“EFI-Setup”?) muss, um zwischen CSM- und UEFI-Modus umzuschalten?

Und ja, es gibt zumindest ein Betriebssystem, das statt des MBR einen andere Bootsektor/eine andere Partitionstabelle verwendet: FreeBSD mit BSD Disklabel. Außerdem gibt es noch die “PC booter”, die keinen VBR verwenden und –zugegeben– nur von Disketten starteten. Wenn man soetwas auf eine Festplatte kopierte, sollte es jedoch auch laufen (nicht probiert). Ich persönlich hatte einmal ein paar Spiele auf 5,25"-Disketten, die PC-Booter waren.

Außer einem selbstprogrammierten Betriebssystem würde es –ungeachtet dieser Fährigkeit– keinen Sinn machen, wenn ein Betriebssystem für PCs den MBR nicht unterstützte. Ein PC kommt (fast immer) mit einem PC-Betriebssystem und in >90% aller Fälle mit einem DOS/Windows-Gespann daher. Das war in den 1980er, 1990er und auch in den 2000er Jahren so. Ein PC-Betriebssystem, das eine gänzlich andere Partitionstabelle und einen ganz anderen Bootsektor verwenden würde bzw. einen anderen benötigen würde, wäre allein schon wegen der fehlenden Kompatibilität und der fehlenden Dual-Boot-Fähigkeit kein Erfolg. Darum wird FreeBSD auf PCs fast ausschließlich immer in einer MBR-Partition installiert, obwohl es Disklabel auch als primäre Partitionstabelle/Bootcode unterstützen würde. Für Linux gilt das ebenso. Welchen Sinn hätte ein Linux Bootloader auf PCs, der verlangt, DOS/Windows von der Platte zu fegen?

Deswegen wird die Aussage, dass es nur MBR gibt, aber nicht wahr. Für BIOS zumindest. Für UEFI ist GPT fix vorgegeben (Teil der EFI-Spezifikation), wie für Apples Open Firmware in der PowerPC-Äre APM fix vorgegeben war. Was für das BIOS gilt, gilt aber auch für das CSM von UEFI. Somit muss auch das CSM mit nicht-MBR/VBR-Bootcode umgehen können. Theoretisch. Dass sich einige BIOS-Hersteller vielleicht nicht daran halten ist eine ganz andere Sache, die man natürlich auch erwähnen sollte.^link

‣Andreas•⚖ 21:02, 5. Mär. 2013 (CET)

Das umschalten zwischen CSM- und UEFI-Modus ist ja keien Aufgabe, für die man Stunden braucht,wenn ich mal weiß, wo genau sich die Einstellung im UEFI-Setup findet, brauch ich dafür vielleicht 10 Sekuden, dazu kommen noch ein paar Sekunden dazu, weil der Rechner wohl zum Übernehmen der Einstellungen neu gebootet wird, aber insgesamt sollte der Zeitverlust unter 30 Sekunden bleiben, daher halte ich es nicht relevant für eine Enzyklopädie, für eine Anleitung wärs natürlich shcon relevant. --MrBurns (Diskussion) 08:05, 14. Mär. 2013 (CET)

Grammatik: "Es existieren auch BIOS,"

Im Artikeltext heißt es: "Es existieren auch BIOS, [...]". Ich dachte immer auf Deutsch ist das Plural von BIOS BIOSe. --MrBurns (Diskussion) 08:53, 26. Jun. 2013 (CEST)

Nach deutlich über 48h ohne Antwort ändere ich das mal. --MrBurns (Diskussion) 17:34, 28. Jun. 2013 (CEST)

Partition Boot Record ...

... führt hierher, ist aber in keinem Satz erwähnt... --188.102.177.114 14:58, 24. Jun. 2013 (CEST)

Also ich kenne nur Master Boot Record und Volume Boot Record. Ich halte es für unwahrscheinlich, dass Partition Boot Record eine geläufige Bezeichnung ist. --MrBurns (Diskussion) 15:04, 24. Jun. 2013 (CEST)

Volume Boot Record = Partition Boot Record --Thomei08 15:13, 24. Jun. 2013 (CEST)

Dann sollte Partition Boot Record nach Volume Boot Record führen und nicht hier her. --MrBurns (Diskussion) 15:24, 24. Jun. 2013 (CEST)

Ich habe die Umleitung soeben dementsprechend korrigiert. ‣Andreas•⚖ 18:28, 12. Jul. 2013 (CEST)

Abschnitt "Partitionstabelle"

Zitat: "Dadurch lassen sich mit herkömmlichen Partitionstabellen über CHS-Adressierung maximal etwas über 8 GB (ca. 7,8 GiB) große Datenträger und über LBA-Adressierung etwas über 2 TB (knapp 2 TiB) große Partitionen bzw. etwas über 4 TB (knapp 4 TiB) große Datenträger nutzen (wenn vom Betriebssystem unterstützt)."

Bei 32-bit-LBA-Adresse komme ich auf maximal 2 TiB bei 512 B blocksize (2^32 * 2^9 B = 2 199 023 255 552 B), wie kann man denn dann noch Blöcke in 4 TiB großen Datenträgern ansprechen? --Red*Star (Diskussion) 11:48, 10. Aug. 2013 (CEST)

Theoretisch indem die letzte Partition knapp vor der 2 TB Grenze beginnt und knapp 2 TB groß ist ... dann muss die interne Verarbeitung aber mehr als 2 TB adressieren können, darum steht dort auch "wenn vom Betriebssystem unterstützt" --Nobby1805 (Diskussion) 14:17, 10. Aug. 2013 (CEST)

FAQ: 3-TByte-Festplatten:

• Unter Windows mit „Größer-als-2-TByte“-Treibern wie dem DiskUnlocker von ASUS. Microsoft selbst unterstützt >2 TB-Datenspeicher mit MBR nicht: kb2581408.
• Linux kann bis zu 4 TB mit MBR addressieren, allerdings muss die Boot- und Root-Partition unterhalb von 2 TB liegen und die Datenpartition, die über die 2 TB-Grenze reicht, muss ebenfalls unterhalb der 2 TB-Grenze beginnen.
• Als allgemeine Möglichkeit funktionieren eventuell noch MBRs mit 4k-Blöcken statt den üblichen 512-Byte-Blöcken. Das kann aber bei vielen Betriebssystemen zu Problemen führen, weil gerade einige Systemprogramme und auch Diagnosewerkzeuge (möglicherweise auch chkdsk o.ä.), Partitionierungs- und Sicherungsprogramme o.ä. damit eventuell nicht umgehen können (und im schlimmsten Fall zu Datenverlust führen!). Und es stellt sich natürlich auch die Frage, mit welchem Partitionierungsprogramm (fdisk) man einen solchen MBR überhaupt erstellen kann…

‣Andreas•⚖ 18:24, 11. Aug. 2013 (CEST)

Danke für die Antworten :).

Ok, dann ist die Formulierung "eine 32-Bit-lange LBA-Adresse" aber irreführend, weil der (unaufmerksame ;) ) Leser davon ausgeht, dass 32 bit die Begrenzung der Adressierung (auf allen Ebenen) ist, sprich ein UInt32-Overflow nach dem 2^32+1sten Block spätestens auf der Ebene des BIOS dazu führt, dass der nächste Block wieder an LBA-Index 0 abgelegt wird.

Dass LBA-Adressen auf Ebene des BIOS bis zu 48 bit lang sein können, steht zwar im LBA-Artikel, aber geht aus diesem Abschnitt nicht hervor (ich habe es selbst erst gerade eben dort nachgelesen).

Änderungsvorschlag:

"...etwas über 2 TB (knapp 2 TiB) große Partitionen bzw. etwas über 4 TB (knapp 4 TiB) große Datenträger nutzen. Letzteres ist jedoch nur dann möglich, wenn das BIOS LBA48 (also 48 bit lange Adressen) unterstützt, und das Betriebssystem auch mit entsprechend großen Datenstrukturen arbeitet."--Red*Star (Diskussion) 22:00, 26. Aug. 2013 (CEST)

Zu DiskUnlocker:soviel ich weiß funktioniert das anders: der Treiber bewirkt, dass für das OS eine Festplatte wie mehrere Festplatten ausschauen, also praktisch das umgekehrte Verfahren von JBOD. --MrBurns (Diskussion) 18:22, 21. Sep. 2013 (CEST)

Überarbeiten!

Dieser Artikel ist nicht gut. Er ist gar nicht gut. Wenn man eine Enzyklopädie aufsucht, dann möchte man schnell und/oder umfassend über den jeweiligen Eintrag informiert werden. Das ist hier nicht der Fall, weil der Artikel

• unstrukturiert
• sich selbst widersprechend
• PC-lastig
• teilweise falsch

ist. Außerdem

• fehlt das Wesentliche

in

• kurzer und pregnanter Form!

Wie ich zu dieser Ansicht komme? Nun, es kommt nicht klar heraus, dass der MBR

• auf IBM-PCs als Partitionstabelle entwickelt wurde, mit der Auflage,
• kompatibel zum VBR zu bleiben (selbes Schema: BIOS lädt die ersten 512 Bytes in den RAM, sieht nach ob das ganze auf 55AA endet, wenn ja wird es ausgeführt im 16-Bit-Modus: das macht das BIOS auf einem IBM-PC-kompatiblen Computer IMMER, egal, mit welchem Betriebssystem oder Programm es gefüttert wird!)
• nicht größer als 512 Bytes zu sein.

Geschichtlich wurde der MBR von Microsoft (wahrscheinlich in Zusammenarbeit mit IBM) [→prüfen] entwickelt, als DOS nicht mehr nur mit Disketten (der originale IBM-PC hatte ja eins oder zwei davon, A: und B: unter DOS) sondern eben auch mit Festplatten umgehen können musste, sah man es offenbar als notwendig an, diese auch in Partitionen aufteilen zu können. Der MBR war das Ergebnis: quasi eine Vorstufe zum VBR. Denn der MBR macht nichts anderes, als:

• Partitionstabelle lesen und auswerten
• die erste aktive Partition suchen
• den Bootsektor auf jener Partition finden
• den Bootsektor laden und ausführen (wie es das BIOS machen würde, wenn statt des MBR ein VBR da ist, wie z.B. auf Disketten).

Erweiterte Partitionen machen dasselbe mit einem weiteren MBR-Block. Also BIOS→MBR→MBR (erweiterte Partition)→VBR→Betriebssystem.

Dass der MBR sich heute auch auf Festplatten und Speichermedien (USB-Sticks) von anderen Systemen findet, hat natürlich auch wieder – geschichtlich gesehen – damit zu tun, dass Windows bis in das erste Jahrzehnt nach dem Millenium immer noch MBR-Partitionen benötigte. Wenn man also kompatibel bleiben wollte, musste man auf bekanntes aufbauen. Apple hat also notgedrungen auch Medien mit MBR unterstützt (obwohl die Apple-Firmware nicht von MBR-Partitionen starten kann), ebenso wie es Unix und andere Betriebssysteme gemacht haben. Sonst hätte man keinen USB-Stick zwischen den unterschiedlichen Systemen benutzen können.

Gleichzeit ist es natürlich auch so, dass andere Betriebssysteme, die auf IBM-PCs liefen, das Rad nicht neu erfunden haben sondern den MBR einfach übernommen haben. So kann man jedes PC-Betriebssystem (mir fallen tatsächlich KEIN Ausnahmen ein!) immer auf MBR-Partitionen installieren und starten. Beispiel: FreeBSD: lässt sich auf einer MBR-Partition (mit dazugehörigem Bootloader auf der Partition, die vom MBR geladen wird wenn die Partition als aktiv markiert ist) ebenso installieren, wie im „nativen“ Modus, in dem es das Disklabel-Partitionierungsschema auf Spur 0 bringt = ohne MBR auf einem IBM-PC installiert wird.

Immer jedoch muss ein kleines Miniprogramm, das dann schließlich über mehr oder weniger Zwischenschritte das Betriebssystem lädt, in den ersten 512 Bytes abgelegt sein, und diese müssen auf 55AA enden, denn sonst lädt es das IBM-PC-BIOS ja nicht.

Und genau das würde ich gerne im Artikel erfahren.

Weiters geht der Artikel eben nicht darauf ein, dass es einen Unterschied gibt, ob man den MBR

• zu Starten eines Betriebssystems auf einem PC

oder

• zum Partitionieren eines externen Datenspeichers

verwendet. Da gibt es Unterschiede. Beim externen Datenspeicher, der MBR zur Partitionierung verwendet, muss kein Code enthalten sein. Es reicht die 64 Bytes große Partitionstabelle, die vom Betriebssystem, welches diesen externen Datenspeicher einbindet (=mount), gelesen und interpretiert wird. Danach werden die Partitionen in Betriebssystem überlicher Weise im System angemeldet, das Dateisystem gegebenfalls also gemounted. Unter Windows bekommt eine FAT- oder NTFS-Partition einen Laufwerksbuchstaben. Under Mac OS erscheint eine FAT- oder HFS-Partition auf dem Desktop (mit dem volume name). Unter Linux wird ein unterstütztes Dateisystem in /mnt oder /media eingebunden. Und so geht es dahin.

Diese beiden – ich nenne es mal so: – Nutzungsszenarien sollten besser herausgearbeitet, getrennt werden. Sonst kennt sich der Leser nicht aus.

Danach kann man über die Besonderheiten von erweiterten Partitionen, Aufbau der Partitionstabelle, Partitionstypen und weiß der Guckuck was schreiben.

Soweit meine Meinung. Ich habe nun einen entsprechenden Baustein gesetzt. Wenn jemand helfen will: Bitte sofort loslegen. Und: die Diskussion ist eröffnet! ‣Andreas•⚖ 23:03, 14. Feb. 2013 (CET)

Danke für das kundtun deiner Meinung. Ich würde mich freuen, wenn du mithelfen würdest diesen Artikel zu verbessern. Dazu musst du aber bei einigen Punkten wirklich noch genauer recherchieren.
Fachlich stimmt einiges was du da sagst auch nicht so ganz. Da bewegt sich der Artikel wie er jetzt besteht näher an den Fakten, auch wenn er nicht ganz perfekt ist. --Thomei08 08:16, 15. Feb. 2013 (CET)

Na gut. Was stimmt fachlich nicht? Fang einfach mal mit dem Punkt an, der dir als erstes ins Auge springt. ‣Andreas•⚖ 13:37, 15. Feb. 2013 (CET)

• [1]MBR und VBR sind nicht dasselbe. Die sind unterschiedlich aufgebaut.
• [2]MBR und VBR bestehen nicht nur aus dem Boot-Code.
• [3]BIOS kompatible Datenträge unterscheiden sich vom Aufbau her nicht, egal ob man von ihnen ein OS booten können soll oder nicht.
• [4]Der MBR und dessen Partitions-Tabelle sind keine Notwenigkeit für ein BIOS. Ich kann einen ganzen Datenträger mit einem einzigen VBR und einem einzeigen Filesystem belegen. Wie bei Disketten und viele USB-Sicks.
• [5]Der Grund für die Erfindung der Partitionstabelle hat nichts mit der Einführung der Festplatte zu tun.
• [6]Auch im MBR einer internen Festplatte, die die System-Partition eines OS beherbergt, muss nicht zwingend Boot-Code im MBR vorliegen um dies mit einem BIOS zu laden. Die Partitions-Tabelle des MBR's und der Boot-Code im VBR reicht vollkommen. Dazu muss aber die Partition in der Partitions-Tabelle als aktiv eingetragen sein.
• [7]Über die Möglichkeiten wie OSX und Linux (=unixoide System) Filesysteme mounten, scheinst du wenig zu wissen. (Stichworte mount, FUSE, Images, RAID, LVM, LBA, Labels, UUID... Würde zu weit führen das alles hier zu erklären, da es nicht Teil des Themas MBR ist.)
• [8]Was du mit einer "MBR-Partition" genau meist ist mir schleierhaft? Ich dachte immer, dass Partitionen nur wegen der Existenz eines MBR möglich sind auf einem BIOS-kompatiblen Systemen.
• [9]Wie soll das BIOS ein OS in einer Partition auf einem Datenträger ohne MBR finden? (Ausnahme es gibt keine Petitionen sondern nur ein FS mit einem VBR. Viele OS sind durchaus in der Lage die Petitionen auf "normalen" Festplatten auch ohne einen MBR zu finden. Das BIOS aber nicht.)
• [10]Deshalb gab es bis zu UEFI auch keine Alternativen für "andere OS" als den Boot-code in den MBR oder VBR zu schreiben. Es stellt sich also nicht die Frage wieso "andere OS" auch den VMR und MBR nutzen, statt das Rad neu zu erfinden. Ohne BIOS-Komptabilität kein Boot auf dem IBM-PC. So einfach war das. Ob nun der Boot-code im MBR oder nur VBR liegt oder nicht, ist eine andere Frage. --Thomei08 17:11, 15. Feb. 2013 (CET)

Erst einmal danke für die Beantwortung. Damit kann ich arbeiten. Leider muss ich in fast allen Punkten (nummeriert, z.B. [1]) widersprechen:

• [1]Aus der Sicht des BIOS ist ein MBR genau so gut wie ein VBR. Es ist also das gleiche – aus der Sicht des BIOS. (Begründung, siehe Punkt [3])
• [2]Natürlich nicht. Jedoch, wenn davon ein Betriebssystem gestartet werden soll, ist dieser Code wichtig. Wenn es kein Startmedium ist, enthält ein MBR/VBR (=Bootsektor) meist ein kleines Programm, das dann schreibt: „Kein Betriebssystem...“ oder so ähnlich. Es gab auch Bootsektoren für Disketten, die einfach an das erste Festplattenlaufwerk übergaben, also wie das BIOS diese Spur ladeten und ausführten.
• [3]Falsch! Die einzige Anforderung ist, dass es sich um ein Programm handelt, das 1. mit 512 Byte Code auskommt und das 2. auf 55 AA endet.
  Abgesehen davon kann alles andere vollkommen unterschiedlich sein – statt MBR z.B. Disklabel; oder direkt ein Kernel, ohne Partition oder Dateisystem.
• [4](a) Richtig und… (b) naja. Zu (a) – für das BIOS ist nur wichtig, was ich in Punkt [3] bereits als Anforderung beschrieben habe. Zu (b) – von USB-Sticks, die keine Partitionstabelle enthalten, höre ich in der Praxis das erste Mal. Als Linuxer habe ich das natürlich auch schon mal gemacht, einen USB-Stick ohne Partitionierung zu verwenden, aber das ist nicht der Standard. Tatsächlich wird sogar davon abgeraten.
• [5]Danke! Ich stimme zu, dass ich darüber nichts weiß. Es wäre sehr interessant, herauszufinden, was der ursprüngliche Grund war, einen Datenspeicher in Partitionen aufzuteilen und was die erste praktische Anwendung war!
• [6]Falsch. Denn das BIOS interpretiert die Partitionstabelle nicht. Es weiß daher nicht, was eine Partition ist, wo sie ist, geschweige denn, ob sie als aktiv markiert ist. Das BIOS benötigt Boot-Code auf Spur 0! So einfach ist das. Ob dieser Code nun im VBR direkt das Betriebssystem lädt, oder zuerst im MBR die Partitionstabelle analysiert und an den VBR einer aktiven Partition übergibt, das ist dann nur noch eine Verkettung von Maschinencode, der im Prozessor ausgeführt wird und schließlich zum gewünschten Ergebnis führt: ein Betriebssystem startet. Siehe dazu auch Punkt [3].
• [7]Ich glaube, dass ich mich gut genug auskenne, wie man unter Linux und Mac OS X Dateisysteme einhängt. Könntest du diese Aussage ein wenig präziser Formulieren? Was bringt dich zu dieser Annahme?
• [8]Das ist leider auch falsch. Ein Beispiel ist eine Installation von FreeBSD. Man kann sich bei der Installation entscheiden, die gesamte Festplatte mit Disklaben zu formatieren. Dann ist auf Spur 0 ein Disklabel mit für BSD spezifischen Slices (was einer Partitionstabelle entspricht), die dann von FreeBSD genutzt werden. Leider können dann einige andere PC-Betriebssysteme nicht auf diese Partitionen zugreifen und auch eine Parallelinstallation ist damit unmöglich. Daher gibt es bei FreeBSD die Möglichkeit, das Disklabel in einer MBR-Partition zu installieren. Dabei ist das Disklabel einfach in einer Partition, die im MBR definiert ist, enthalten, anstatt die gesamte Festplatte zu belegen. Damit kann man DOS/Windows/OS/2/whatever neben FreeBSD installieren. Wenn ein Betriebssystem nun den MBR lesen kann (was sogut wie jedes PC-Betriebssystem kann) und auch Disklabel auswerten kann (neben BSD etwa auch Linux) und auch noch das Dateisystem unterstützt, dann kann jenes Betriebssystem auf die Partition und auf die Disklabel-Slices auch zugreifen.
  The point is… dass man keinen MBR oder VBR braucht um BIOS-kompatibel zu sein. Siehe wiederum Punkt [3].
  Um jedoch DOS/Windows-kompatibel zu sein, muss man den MBR oder einen VBR (unwahrscheinlich) verwenden.
  Daher meine Formulierung „MBR-Partition“, z.B. als Unterscheidung zu einem Disklabel-Slice oder einer anderen Partitionstabelle (es gibt ja noch einige andere) zu sehen ist. Diese Unterscheidung mach(t)e ich auch auf meinem PC, in dem eine APM-formattierte Festplatte eingebaut war. Linux kann APM-Partitionen nach dem Start des Kernels – wie eben alle unterstützten Partitionstabellen – in überlicher Form einbinden. So war meine /home-Partition auf /dev/sdb5, was jedoch auf eine APM-Partition war. Diese Festplatte war natürlich nicht startfähig…
• [9]Siehe Punkt [3]. Das BIOS findet die Partition gar nicht: der ausführbare Bootcode der Partitionstabelle macht das (MBR oder Disklabel oder ???).
• [9]Bitte erkläre: welche Betriebssysteme sind in der Lage Partitionen auch ohne MBR zu finden? Was sind „normale“ Festplatten? Was meinst du damit?
• [10]UEFI ist ganz etwas anderes: in diesem Fall interpretiert die Firmware eine Partitionstabelle und lädt sogar Dateien von einer der Partitionen. Das macht übrigens Open Firmware auch. Nur das BIOS ist eben so dumm, dass es einfach das ausführt, was auf Spur 0 steht. (Siehe Punkt [3].) Die Frage stellt sich daher schon: warum verwenden die meisten PC-Betriebssysteme den MBR oder einen VBR? Ansich hätte jedes PC-Betriebssystem seine eigene Partitionstabelle erfinden können! Oder einfach gar keine Partitionstabelle. Meine Vermutung dazu habe ich ja bereits kundgetan.

Falls du meine Quellen durchschauen willst, es sind einige sehr interessante dabei:

• PC Boot Process and Boot Block von Dr. Lawlor (englisch)
• All the Details of many versions of both MBR and OS Boot Records in The Starman's Realm (englisch)
• Bootsector of the IBM PC auf The Syslinux Project (englisch)
• Boot Sector (since DOS 2.0) auf HelpPC Reference Library von David Jurgens (englisch)
• How Boot Loaders Work (29. Mai 2003) von Lennart Benschop (englisch) Nachtrag, ‣Andreas•⚖ 13:34, 17. Feb. 2013 (CET)
• How It Works: Master Boot Record (MBR) (englisch) Nachtrag, ‣Andreas•⚖ 13:34, 17. Feb. 2013 (CET)

Jedenfalls danke für die Antwort. Punkt [5] ist es auf jeden Fall wert, da weiter zu recherchieren.

Was die anderen Einwände betrifft, so lies dich bitte mal ein über das Thema. Ich habe bei meinen Recherchen jedenfalls keinen Hinweis finden können, dass das BIOS die Partitionstabelle lesen und interpretieren würde, oder, dass das BIOS einen Unterschied macht, ob ein MBR oder VBR vorhanden ist. Für das BIOS heißt das ganze einfach nur Bootsektor, ist die Spur 0, was historisch gesehen immer ein 512-Byte-Block war, lädt ihn und führt in im Real Mode = 16-Bit aus.

Ich bin jedoch auch hier offen für neues. Vielleicht habe ich etwas übersehen?

‣Andreas•⚖ 01:00, 16. Feb. 2013 (CET)

Nachtrag: Es ist kein Wunder, dass sich um die Sache mit dem Startvorgang eines PCs und um den MBR so viel Fehlinformation manifestiert hat. Selbst Zeitschriften verwechseln und vermischen ständig die wirklichen Tatsachen. Zum Beispiel hier. Wenn man das liest, muss man glauben, ein PC würde auf der Festplatte zwangsweise einen MBR benötigen. Stimmt so natürlich nicht. Die Begriffe MBR, Bootsektor, Spur 0 (oder Sektor 1 der Spur 0), und Partitionstabelle (die Partitionstabelle des MBR ist im 512 Byte großen MBR eingebettet und umfast 64 Bytes) werden ständig vermischt. Dass es nicht so leicht ist, verdeutlich die Aussage, dass MBR, GPT, APM, VTOC, ... Partitionstabellen sind. (Gemeint ist: verschiedene Typen von Partitionstabellen). Der MBR ist aber mehr, da er auch ein Startprogramm (Bootcode) enthält.

Dass es auch ohne MBR/VBR/… geht, verdeutlicht dieser Bootsektor: Eigene Betriebssystementwicklung am PC (12. August 2011) von Dr. Erhard Henkes.

‣Andreas•⚖ 13:46, 17. Feb. 2013 (CET)

1. Ja, solange es nur ums laden des boot codes geht schon. Das ist aber nicht der einzige Zweck des MBR.
2. Die Part-Tabelle ist Teil des MBR. Im VBR existiert keine.
3. Die min. Anforderungen schliessen nicht aus, dass das BIOS normalerweise weit mehr kann.
4. Sehe das oft.
5. Gibt es brauchbare Quellen? Wahrsch. muss man anderen Computer-Familien von IBM suchen.
6. Die Fähigkeit alles zu ignorieren und nur den ersten Sektor zu lesen, heisst noch lange nicht, dass das BISO nicht mehr kann und im normalfall auch macht, wenn es eine Part.-Tab. vorfindet. Das ist nur der Rückfall-Modus, wenn keine Partition aktiv ist, die aktive Partition nicht bootbar ist oder keine Partitionen existieren.
7. Zitat: "Unter Mac OS erscheint eine FAT- oder HFS-Partition auf dem Desktop (mit dem volume name). Unter Linux wird ein unterstütztes Dateisystem in /mnt oder /media eingebunden. Und so geht es dahin." Hmmmm... wenn das alles nur so einfach wäre...
8. Ja, es gibt alternative Möglichkeiten. Die unterstützt aber kein BIOS. Da musst du die ganze BIOS-Funktionalität nachbauen, was ohne Filesystemtreiber eine grosse Herusfoerung darstellt. Lässt sich nur durch Staging lösen. Mit MBR und VBR kann jedoch jedes BIOS umgehen.
9. "Normal" schlisst z.B. DB-Images aus. Den Beginn eines Filesystemes auf einer Platte zu identifizieren ist keine schwierige Sache. Dazu muss nicht einmal die ganze Platte durchsucht werden, da aus den meisten FS an der immer gleichen Stelle auch ihr Ende ausgelesen werden kann. Z.B. Testdisk oder auch chkdisk macht sich dies zu nutzen um Fehler im MBR zu finden und reparieren. Im Gegensatz dazu seiht das BIOS heute meist nicht einmal die ganze HD.
10. Ich denke der Grund war, dass man Mitte der 90er beim Boot-Prozess, gerne so viel wie möglich dem BISO überlassen wollte. Erst mit GRUB1 und BCD die selbst schon min. OS-ähnliche Eingeschalten mitbringen verlagerte sich das Gewicht weg von der BIOS-Funktionalität.

--Thomei08 13:59, 19. Feb. 2013 (CET)

• [1] Nach meinem Verständnis hat der Code im MBR den Sinn, die Partitionstabelle auszulesen, die aktive Partition zu ermitteln und diese in der PC-üblichen Form zu „starten“ – also wiederum im Real Mode den 512-Byte großen Block zu laden und auszuführen. Nochmal: ich höre es zum ersten Mal und habe es noch nie irgendwo gelesen, dass das BIOS diese Aufgabe übernehmen würde.
  Im Gegenteil: Bootviren sind eigentlich NUR dadurch möglich!
• [2] Das weiß ich. Ich wollte nur darauf hinaus, dass IMMER ein Bootcode enthalten ist. Der einzige Unterschied zwischen MBR und VBR ist, dass das Programm des MBR kein Betriebssystem startet, sondern die Partitionstabelle „initialisiert“=ausliest+interpretiert, und dann an die jeweilige aktive Partition übergibt. Das Chainloading-Prinzip also.
• [3] Korrekt. Doch dafür braucht man eine Quelle.
  Also, welches BIOS kann MBR-Partitionstabellen auslesen? – Und wir reden hier über ein BIOS, nicht über UEFI mit einem Compatibility Support Module, das dann (aus Betriebssystem-Sicht) wie ein BIOS agiert.
• [4] Meine Erfahrungen sind anders, aber gut. Ein USB-Stick hat eigentlich fast immer einen MBR und eine einzige Partition mit FAT32 oder NTFS, wenn er neu gekauft wird.
• [5] Ich hab’ noch keine Quellen dazu gefunden. Das Problem wird vermutlich sein, dass das in „grauer Computer-Vorzeit“ geschehen ist, und vieles davon ist heute nicht mehr so einfach zu finden…
• [6] siehe [3]
• [7] Ich hab’ mich bewußt einfach gehalten und das Endresultat aufgezeigt. Steckt man ein Wechselmedium an, so wird es im Betriebssystem verfügbar gemacht: unter Windows eben mit einem Laufwerksbuchstaben und in Mac OS X, BSD, Linux und vermutlich so gut wie jedem anderen unixoiden System (außer vielleicht Ultrix…[1])) in einem Verzeichnis, dessen Name unterschiedlich sein kann. Früher war es einmal /mnt. Unter Mac OS X ist es /Volumes. In einem modernen Linux ist es /media – oder war es zumindest mal. Neuerdings hängt mein Linux Dateisysteme unter /run/media/<Username>/<VolumeName> ein. Im Grunde genommen ist es aber immer dasselbe.
• [8] siehe [3] – das BIOS muss hier gar nichts unterstützen. Das Prinzip ist immer das gleiche. Das BIOS macht hier keinen Unterschied. Wenn du das anders sieht, dann bitte ich um eine Quelle. Siehe auch [2]…
• [9] 1. Was sind DB-Images?
• [9] 2. Ein Dateisystem zu finden ist eine ganz andere Sache, denn dazu muss man das Dateisystem kennen. Welches Dateisystem? Es gibt ja so viele. Aber natürlich, Programme wie Testdisk können sowas. Ist ja auch nur ein Programm, das zu programmieren nötig war. Das BIOS macht soetwas jedoch nicht – siehe [3]
• [10] Aber nicht doch. Umgekehrt wird ein Schuh draus. Die Betriebssysteme haben sich einfach weiterentwickelt und es entstand aufgrund des BIOS überhaupt erst die Notwendigkeit, Chainloader zu verwenden.
  • Denn das erste Programm wird ja immer im Real Mode ausgeführt. Dieser setzt jedoch gewisse (enge) Limits: When the boot sector is loaded, the CPU is in real mode. For those who are unfamiliar with 80x86 architecture: real mode is very limited compared to 32-bit protected mode (in which Linux runs). For example: data outside a 64K segment can only be accessed if you change a segment register and data outside the first 1MB of address space (which contains 640kB of main memory) cannot be accessed at all. Zitat aus: How Boot Loaders Work (29. Mai 2003) von Lennart Benschop (englisch)
  • Darum hat das erste 16-Bit-Programm (IO.SYS oder NTLDR) zunächst einmal die Aufgabe, den Start des Betriebssystems vorzubereiten. Es macht dies indem es in irgendwann in den Protected Mode springt und dann an den eigentlichen Kernel übergibt, der schließlich das eigentliche Betriebssystem startet.
  • Understanding the Boot Process (englisch) beschreibt dies auch sehr anschaulich:
    (1) The computer runs POST (Power-On Self Test) routines to determine the amount of physical memory, whether the hardware components are present, and so on. If the computer has a Plug and Play BIOS, enumeration and configuration of hardware devices occurs at this stage.
    (2) The computer BIOS locates the boot device and loads and runs the MBR (Master Boot Record).
    (3) The MBR scans the partition table to locate the active partition, loads the boot sector on the active partition into memory, and then executes it.
    (4) The computer loads and initializes the NTLDR file, which is the operating system loader.
    Der NTLDR ist in diesem Fall derjenige Teil in der Startsequenz (“chain”), der in den Protected Mode springt.
  • Gehen wir die Sequenz nochmal durch:
    1. BIOS – POST
    2. BIOS – findet ein passendes Startmedium, z.B. HDD0 (die erste Festplatte)
    3. BIOS lädt den Bootsektor (512 Bytes) dieses Startmediums in den Speicher und führt ihn (nach der 55AA-Prüfung) aus.
    4. Im Bootsektor ist ein MBR, der nun die Partitionstabelle ausliest. Der MBR findet eine aktive Partition, sagen wir mal es ist die erste primäre Partition.
    5. Der MBR lädt den Bootblock (wiederum 512 Bytes) dieser aktiven Partition, prüft ihn (wieder 55AA) und führt den Code aus.
    6. Dieser Bootblock ist ein erweiterter VBR – ich nenne es mal „erweitert“, da er einige weitere 512-Byte-Blöcke nachlädt (2 weitere Blöcke bei FAT32[2][3] und 5-15 weitere Blöcke bei NTFS[4])… also dieser „erweiterte“ VBR lädt nun entweder IO.SYS (Windows 95) oder NTLDR (Windows 2000, XP, …).
    7. Diese wiederum wecheln schließlich (endlich) in den Protected Mode und ladten den Kernel und benötigte Treiber. Das Betriebssystem wird gestartet…

Ich denke, dass ich diese Aussagen in ausreichender Form belegt habe. Daraus geht nicht hervor, dass irgendein BIOS das anders machen würde oder dass es Ausnahmen gibt.

Wenn das also so wäre, dann bitte ich dich um eine Quelle dafür (siehe [3]).

Gruß, ‣Andreas•⚖ 21:42, 20. Feb. 2013 (CET)

Nur eine kleine Anmerkung (falls das was du hier geshrieben hast überhuapt je in den Artikel kommt): Die IO.SYS schaltet bei keiner Windows-Version in den Protected Mode, das passiert frühestens beim Laden der WIN.COM. --MrBurns (Diskussion) 12:43, 20. Apr. 2013 (CEST)

Danke. Stimmt natürlich, aber auch hier zeigt sich wiederum anschaulich das Chainloading-Prinzip. Der VBR lädt den eigentlichen Bootloader des Betriebssystem, welcher entweder gleich der Kernel selbst ist (wie etwa bei *BSD und Linux der Fall), oder welcher wiederum selbst aus einer Chainloading-Sequenz besteht, wie bei Windows 9x: IO.SYS lädt WIN.COM lädt VXDs etc.[5] ‣Andreas•⚖ 19:20, 21. Apr. 2013 (CEST)

Ich habe den Überarbeiten-Baustein auf die Artikel Bootsektor und Volume Boot Record ausgeweitet, weil dieses Thema alle drei Artikel gleichermaßen betrifft. Zum Artikel über den VBR gibt es schon seit August 2012 einen Baustein zur Qualitätssicherung: Begründung hier ‣Andreas•⚖ 12:34, 23. Feb. 2013 (CET)

Es gab in den 90er-Jahren BIOS in denen ich sogar die zu bootende Partition festlegen konnte. Quellen finde ich momentan leider keine mehr darüber. In der Vergangenheit gab es auch nicht wenige BISO gab die sogar eigne Funktionen von einer FAT-Partitionen nachladen konnten. (siehe: [6]) Diese Partition konnte auf der Disk beliebig platziert sein. Deshalb denke ich, dass die Darstellung, dass ein BISO die Partitionstabelle nicht beachtet stark verkürzt ist. Von immer wieder genannten Minimalanforderungen sollte man nicht auf das ganze schliessen. Erhellend kann auch ein Studium des Quellcodes des in qemu enthaltenen SeaBIOS sein. Diese ist das einzige Open-Source-BIOS das ich kenne. --Thomei08 14:11, 24. Feb. 2013 (CET)

Ja, okay. Ich habe auch darüber nachgedacht und kann mich mittlerweile erinnern, dass ein Freund einmal einen Laptop hatte, der ohne hochzufahren MP3-Dateien von einer FAT32-Partition auf der Festplatte abspielen konnte. So konnte man bei minimalem Strombedarf (kein Display, kein OS – nur CPU, RAM und Festplatte) Lieder über den Audio-Kopfhöreranschluss genießen.

Die Sache ist jedoch die, dass es einen BIOS-Standard gibt. Es gibt bestimmte Dinge, auf die sich ein kompatibles Betriebssystem verlassen muss. Wenn nun ein BIOS mehr kann als es der Standard vorschreibt, so ist das schön, es heißt aber noch lange nicht, dass dies der neue Standard ist.

Es gibt auch heute noch neue Computer mit einem BIOS, das nicht mehr kann als es können muss. Wozu auch?

Ich werde mir mal die SeaBIOS-Quellen ansehen, sobald ich Zeit habe. Danke für den Hinweis.

‣Andreas•⚖ 20:43, 24. Feb. 2013 (CET)

Nachtrag: Hab mir SeaBIOS durchgeschaut. Ich kann unter src/boot.c lediglich finden, dass die Funktion boot_disk nach einer Gültigen MBR-Signatur (Magic Number = 0x55 0xAA) sucht. Mehr aber auch nicht. ‣Andreas•⚖ 21:00, 24. Feb. 2013 (CET)

"BIOS-Standard"? Also ISO, DIN, IEEE oder so was? Wenn es den tatsächlich gibt, würde das in den Artikel gehören. Wenn Disk-Signaturen gesucht werden, spielt auch die Partitionstabelle eine Rolle. --Thomei08 07:28, 27. Feb. 2013 (CET)

Der Standard heißt IBM-PC-kompatibler Computer. Die Disk-Signatur ist eigentlich eine Bootsektor-Signatur und seit dem IBM-PC XT eingeführt. Sie hat mit dem MBR genau so viel zu tun wie mit dem VBR, Disklabel oder dem Eigenbau-Kernel. ‣Andreas•⚖ 17:31, 27. Feb. 2013 (CET)

Nachtrag: Dann gibt es (gab es) ja noch die “PC booter” getauften Spiele, die ansich ein Betriebssystem darstellen. Auch die müssen im ersten Sektor diese Signatur aufweisen, wenn sie von einem IBM-PC oder kompatiblen Computer gestartet werden wollen. Ganz ohne Partitionstabelle (MBR) oder DOS-Bootsektor (VBR) – und auch damit sollte SeaBIOS wohl umgehen können. Sonst wäre es nämlich nicht BIOS-kompatibel. ‣Andreas•⚖ 17:51, 27. Feb. 2013 (CET)

Ich würde mich feuern, wenn im Artikel auch erwähnt würde, dass das BIOS durchaus einen VBR direkt laden kann. Die Quellenlage dazu ist etwa gleich dünn, wie für die Aussage, dass das BIOS die Partitions-Tabelle nicht auswertet. Nur das zu belegen, was nicht stimmen soll, kann als WP:TF verstanden werden. --Thomei08 23:08, 4. Mär. 2013 (CET)

PS: Da die Wikipedia nur belegtes Wissen wiedergibt, kann eine Wikipdeia-Artikel keinen Standard sein. --Thomei08 23:11, 4. Mär. 2013 (CET)

Das BIOS kann natürlich einen VBR direkt laden. Das BIOS kann jeden Bootsektor direkt laden, egal wie der nun heißt. Was soll das ganze? Um einen möglicherweise hinkenden Vergleich zu benutzen: „ach ja, dieses Auto kann auch 57 km/h fahren“ – ich finde das sollte man erwähnen. ???

Was Wikipedia als Quelle betrifft: stimmt wohl. Aber es war nicht als Quelle gedacht, sondern sollte dem Verständnis dienen. Aber sei’s darum: hier ein paar externe Quellen:

• Tom's Hardware
  PC-compatible systems have thrived not only because compatible hardware can be assembled easily, but also because the most popular OS was available not from IBM but from a third party (Microsoft). The core of the system software is the basic input/output system (BIOS); this was also available from third-party companies, such as AMI, Phoenix, and others. This situation enabled other manufacturers to license the OS and BIOS software and sell their own compatible systems. The fact that DOS borrowed the functionality and user interface from both CP/M and UNIX probably had a lot to do with the amount of software that became available. Later, with the success of Windows, even more reasons would exist for software developers to write programs for PC-compatible systems.
• computerhistory.org
  Eagle released its clone less than a year after the IBM PC. IBM swiftly sued Eagle for copying its “basic input-output system” (BIOS) software. As part of the settlement, Eagle halted manufacturing, independently engineering a BIOS to replace IBM’s.
• Computer Magazine
  Except for a critical piece of code called BIOS, the PC truly was an open hardware architecture. Every major and minor component, enclosures, motherboards, disk, memory, bus, even the CPU would eventually be easily second-sourced.
  The BIOS remained copyrighted by IBM since they intended to use it to prevent unlicensed cloning of the IBM PC. Unfortunately for IBM the BIOS was soon reverse engineered by Compaq and others using a “clean room” process that avoided legal liability for copyright infringement.

Das BIOS war die Erfindung von IBM, PC-DOS/MS-DOS setzte auf das BIOS auf. Die Idee war denkbar einfach: während CP/M für jeden Computer, auf dem es laufen sollte, angepasst werden musste, sollte DOS (am Anfang beinahe ein Clone von CP/M) durch das BIOS eine Art Hardware-Abstraktionsschicht verwenden. Jeder PC würde ein BIOS mitbringen, DOS würde daher auf jedem PC laufen.

Das BIOS ist untrennbar mit dem IBM PC – und somit auch mit dessen Clones, die “IBM PC compatibles” – verbunden. Darüber sollte es doch wirklich keine Zweifel mehr geben. Es ist also ein Defakto-Standard. Der Industrie, die sich um den „IBM-PC/kompatibel“ aufgebaut hat, ist es letztlich egal, ob es eine ISO/DIN/ANSI/IEEE/IEC/sonstwas-Norm ist oder nicht. Wer ein DOS/Windows-Programm (vor Windows NT!) verwenden wollte, der brauchte zwangsläufig einen IBM-PC-kompatiblen Computer dafür. Und das beinhaltet auch ein BIOS. Analog gilt das für Betriebssysteme.

‣Andreas•⚖ 18:31, 5. Mär. 2013 (CET)

Ich glaube, ich sollte etwas klar stellen: ich bin durchaus dafür, dass man Sonderfunktionen im BIOS erwähnen kann bzw. sogar sollte. Ja, es gibt BIOS-Implementationen, die den MBR lesen und analysieren (können) um Sonderfunktionen bereitzustellen. IBM hat beispielsweise auf einigen ThinkPads eine HPA (Hidden Protected Area) eingerichtet.^link Das sollte man aber 1. explizit mit einer Quelle belegen können und es 2. explizit als Sonderfunktion deklarieren. Es ist ja nicht so, als würde ein PC-Betriebssystem diese Funktion voraussetzen (können).

In der Grundfunktion kann das BIOS aber nur den Bootsektor laden und ausführen. Das ist belegt. Jede andere Aussage müsste ebenfalls belegt werden.

‣Andreas•⚖ 19:54, 5. Mär. 2013 (CET)

Na, so weit sind wir schon! Nun finde ich –ausgerechnet ich!– die Ausnahmen!

El Torito (Spezifikation) interpretiert die Daten auf dem Medium. Aber das ist gemäß der Spezifikation so vorgegeben.

Manche BIOS-Hersteller halten sich auch bei Disketten/Festplatten/USB-Sticks nicht an die vorgegebene „Einfachheit“ des Original-IBM-PC-BIOS und interpretieren auch da den Bootsektor (oder mehr als nur diesen einen Sektor) – was dann auch zu Problemen mit GPT-Partitionen führen kann: Legacy BIOS Issues with GPT

Die Betonung liegt auch manche.

Ein BIOS sollte immer auch ein Selbstbau-Betriebssystem starten können. Doch in einer Monokultur, die von DOS/Windows geprägt ist, war die Versuchung vermutlich einfach zu groß.

Diese Negativ-Beispiele sollten in einem der relevanten Artikel (entweder hier, oder im BIOS-Artikel) erwähnt werden.

Hoffentlich finden sich auch noch ein paar Positiv-Beispiele. Adhoc fällt mir nur die Bootsektor-Virenschutz-Funktion ein, die wohl nur ein Schreibschutz für den MBR war. Aber vielleicht ging es ja auch darüber hinaus, und das BIOS las die Partitionstabelle aus und schütze auch die Bootsektoren der Partitionen, wer weiß.

Die Kernaussage lautet: gibt es Quellen?

‣Andreas•⚖ 21:13, 5. Mär. 2013 (CET)

Ich denke, wir habe genug Belege, die zeigen, dass die immer wieder von dir genannte "Norm" (oder Standard) so nicht existiert und sich die BISO-Hersteller durchaus mehr Freiheit erlaubten, als der Artikel momentan weise machen will. Ich werde dieses eingeschränkte Sicht wieder aus dem Artikel entfernen, da auch der Gegen-Beleg fehlt. Alle von dir angeführten Belege beschreiben nur die Mindestanforderungen und schliessen mehr Funktionalität nicht aus. --Thomei08 16:15, 20. Mär. 2013 (CET)

Wäre schön, wenn du diese Belege auch zeigen würdest. ‣Andreas•⚖ 18:36, 25. Mär. 2013 (CET)

Im Gegenteil, ein Beleg für die Einfachheit: A device is "bootable" if it carries a boot sector with the byte sequence 0x55, 0xAA in bytes 511 and 512 respectively. When the BIOS finds such a boot sector, it is loaded into memory at a specific location; this is usually 0x0000:0x7c00 (segment 0, address 0x7c00).[7] ‣Andreas•⚖ 18:36, 25. Mär. 2013 (CET)

Noch ein Beleg: When the BIOS identifies the boot device (typically one of several hard disks that has been tagged as the bootable disk), it reads block 0 from that device to memory location 0x7c00 and jumps there.[8] ‣Andreas•⚖ 18:47, 25. Mär. 2013 (CET)

Dies hier ist ebenfalls eine ausgezeichnete englische Beschreibung für den Startvorgang inklusive MBR. ‣Andreas•⚖ 18:30, 12. Jul. 2013 (CEST)

Hat mich gerade angesprungen…

KB149877:

Der MBR besteht aus Startcode, der vom System-BIOS verwendet wird, um die Partitionstabelle zu lesen. Aus den in der Partitionstabelle enthaltenen Daten kann der MBR ermitteln, welche Partition als startbar (aktiv) gekennzeichnet wird und welches der Startsektor der Partition ist. Nachdem dieser Ort ermittelt wurde, springt das BIOS zu diesem Sektor und beginnt mit der Textphase des Startprozesses, indem es zusätzlichen Code ausführt, der sich auf das Betriebssystem bezieht.

Umständlich formuliert, aber in etwa richtig. Das BIOS lädt den ersten Sektor und führt ihn aus. Dieser wiederum findet in der Partitionstabelle, welchen Sektor es zu lesen und wiederum auszuführen gilt. Dies macht es mit BIOS-Funktionen. Was Microsoft als Textphase bezeichnet bezieht sich wohl auf Microsoft’sche Loader, etwa den VBR, den NT-Loader oder ähnliches. Andere Betriebssysteme mögen andere Loader verwenden…

‣Andreas•⚖ 20:35, 21. Sep. 2013 (CEST)

Minimalanforderungen (die hier MS zitiert) und was es auf dem Markt alles gibt, (oder üblich ist) ist nicht immer das Selbe. Es wäre schön, wenn du diesem Umstand endlich Beachtung schenken würdest. DANKE! --Thomei08 12:02, 22. Sep. 2013 (CEST)

Würde ich BITTE GERNE. Aber es fehlt an Fakten. Nur weil du es sagst, soll es so sein?

Ich habe schon viele BIOS-Implementierungen gesehen, aber die konnten alle nicht mehr als das Minimum (außer IBM/Lenovo). Wie soll ich dir glauben, ohne dass du belegst?

‣Andreas•⚖ 12:42, 22. Sep. 2013 (CEST)

Nachtrag:

Wenn das BIOS keinen gültigen Bootsektor vorfindet (Magic Number AA55h am Ende des 1. 512-Byte-Blocks aka „Sektor 0“) schreibt es meist eine der folgenden Meldungen auf den Bildschirm (siehe KB321626):

• Operating System Not Found
• Missing operating system

Findet es aber einen gültigen MBR, so wird dieser geladen und ausgeführt.

Findet nun der MBR keine gültige Startpartition oder ist er nicht in der Lage, von einer markierten Boot-Parition zu starten, z.B. weil dort die Magic Number fehlt, so wird eine der folgenden Meldungen ausgegeben (siehe The Starman: Standard-MBR):

• Invalid partition table
• Error loading operating system
• Missing operating system

Wird beispielsweise ein FAT32-MSWIN4.1-VBR-Sektor auf der aktiven Startpartition vorgefunden, geladen und ausgeführt, der dann aber kein passendes Betriebssystem vorfindet, so gibt der VBR folgende Meldungen aus (siehe The Starman: MSWIN4.1 OS Boot Record):

• Invalid system disk
• Replace the disk, and then press any key
• Disk I/O error

All dies würde nicht geschehen, wenn das BIOS das Betriebssystem direkt laden würde. Denn dann würde das BIOS anderslautende Meldungen für die beschriebenen Fehlerfälle ausgeben (müssen).

Anders als aber z.B. bei Open Firmware oder bei UEFI, wo die Firmware tatsächlich einen Bootloader direkt lädt, macht das BIOS dies explizit nicht. Nimm das doch bitte endlich zur Kenntnis. BITTE.

‣Andreas•⚖ 17:55, 22. Sep. 2013 (CEST)

Nachtrag 2:

Sagen wir mal, nun installiert jemand Linux (nicht Mulitboot) auf seinem PC. Er verwendet LILO um dieses Linux zu starten und installiert LILO im MBR. Nun wird der MBR durch den Bootloader LILO ersetzt. Die Partitionstabelle bleibt naturgemäß erhalten – das ist so, weil LILO nicht inkompatibel zu anderen PC-Betriebssystemen sein will (LILO hält sich an Konventionen, obwohl diese kein DIN, ISO, IEEE, … sind; sehr brav, oder?).

Würde nun das BIOS direkt die aktive Startpartition finden und ausführen: LILO würde nie gestartet.

Der LILO-Bootcode findet sich hier: The Starman: LILO

Wenn man die Logik zu Rate zieht, kommt man zu dem Schluss, dass es eigentlich nur diese eine Möglichkeit gibt: das BIOS startet nur den Bootsektor; und initialisiert die Hardware, stellt BIOS-Systemaufrufe bereit usw. (siehe weiter oben, schon viel zu oft erläutert).

Wenn man die Faktenlage zu Rate zieht, kommt man zum selben Schluss.

Du kannst mir aber gerne Belege zeigen, die dies anders sehen.

‣Andreas•⚖ 18:12, 22. Sep. 2013 (CEST)

Im Ernst, drücke ich mich so undeutlich aus?
Ich bezweifle doch nicht den Sachverhalt, den du nun weider einemal mehr ausfühliche beschreibst. Ich sage nur, dass man dies nicht so absolut, als das einzig existierende hinstellen sollte, wie es jetzt der Artikel tut. Die Welt ist etwas grösser als das was auf den ersten PC's die Minimalanforderungen. Da sich der jetzige Text (belegt) selbst wiederspricht, denke ich, dass es keine weiteren Belege benötigt. Also müsste man enfach eine offenere Formulierung finden. Mehr will ich gar nicht. Ich verstehe deine Abwehrhaltung wirklich nicht. --Thomei08 11:01, 23. Sep. 2013 (CEST)

Du drückst dich nicht undeutlich aus. Aber du hast keinen einzigen Fakt, der deine immer wieder getätigte Aussage stützen würde.

Es steht ja gar nicht da, dass es das einzig Existierende ist. Nach deiner ersten erneuten Überarbeitung steht hier nun „im Allgemeinen“… also das, was ein BIOS immer kann – auch ohne Sonderfunktionen. Und das ist doch auch so.

Der zweite Absatz erklärt dann die Sonderfunktionen mancher BIOSe (mit IBM/Lenovo als konkretes Beispiel). Diese Funktion habe ich auch in den BIOS-Einstellungen eines Thinkpad gefunden. Sie ist also sowohl belegt, als auch entspricht sie meiner persönlichen Erfahrung.

Auf einem Lenovo IdeaCentre habe ich auch eine solche Recovery-Startpartition (OneKey Recovery) vorgefunden, die sich über das Drücken einer Funktionstaste beim Starten wählen lies. Dies ist vermutlich (mit ziemlicher Sicherheit) über das BIOS implementiert. Da es sich jedoch abermals um Lenovo handelt, habe ich einen Beleg für die OneKey-Recovery-Funktion gar nicht erst gesucht…

Und natürlich: es sollte schon belegbar sein, was wir hier schreiben. Ich weiß zwar, dass sich nicht jeder Umstand und Fakt mit Quellenangaben belegen lässt, aber hier ist es nun einmal so, dass das, was du schreibst, überhaupt nicht dem entspricht, wie ich es kenne. Und ich schaue mir wirklich jedes BIOS an, das ich in die Finger kriege. Die meisten haben keinerlei Sonderfunktionen. Wenn ich so darüber nachdenke… in den späten 1990ern gab es mal einen Boot-Virus-Schutz. Dieser ändert aber das Startverhalten nicht.

Ebensowenig ändern die Sonderfunktionen von IBM/Lenovo das Standard-Startverhalten. Es handelt sich also um eine Zusatzfunktion, nicht um eine Ersatzfunktion. Denn was auch auf diesen Computern immer funktioniert, ist das Standard-Startverhalten, welches ich beschrieben habe („im Allgemeinen“).

Wenn auch andere Herstellen – und nochdazu so viele, wie du es immer wieder schreibst – solche Funktionen implementiert haben, so sollten diese doch dokumentiert sein. Und dann kann man sie auch belegen und als weitere Beispiele anführen.

Und selbst dann ist es dennoch so, dass im Allgemeinen ein BIOS so vorgeht, wie es nun beschrieben steht.

Verstehst du nun, warum ich dich nicht verstehe?

‣Andreas•⚖ 18:26, 23. Sep. 2013 (CEST)

Wir schein uns besser zu verstehen, als ich dachte. Sorry, wenn ich bei der letzten Änderung etwas übers Ziel hinaus geschossen bin.

Ich weiss vorwiegend aus Erfahrung, dass verschiedene Hersteller zusätzliche BISO-Erweiterungen ab einer HD-Partition nachladen können oder ein eAuswahl des zu startenden OS anbieten. Geschäftlich habe ich vor allem mit Lenovo und Dell zu tun; und bieten beide seit Langem die Möglichkeit, aus dem BISO heraus Hilfe- und Diagnosetools zu starten. (Lenovo mit der Thinktaste und Dell mit F12) Mir ist auch bekannt, dass Compaq (als sie noch nicht zu HP gehörten... schon lange her!) solche Funktionen boten. Ich besitze ein altes (~2005) HP Pavillion-Notebook, dass MP3-Files von einer FAT-HP-Partition und Musik-CD's über eine BIOS-Funktion abspielen kann! (Erstaunlich, nicht?) HP geht aber heute mit seinen Utility-Tools einen anderen Weg: Sie lassen den Benutzer ein OS, ab einer CD starten. Auch bei Lenovo und Dell startet das BISO "nur" ein OS, (meist WinPE oder FreeDOS) dass auf einer versteckten Partition auf der HD liegt. Die Nr. (Position) und Grösse dieser "Utility Partition" ist egal, solange sie nicht in der Erweiterten-Part. liegrt. Es ist scheinbar nur ein bestimmter Label(FS-Name) nötig, den das BIOS scheinbar sucht.

Quellen darüber zu finden ist nicht ganz einfach, da die Hersteller scheinbar um ihr BISO eine grosse Hülle des Schweigens legen... Aber zu Dell habe ich Quellen gefunden: Dell BIOS, Dell BISO und IBM hällt ein Padent zu diesem Theman: IBM Padent. Auch von IBM gibt es diese Quelle hier. Zu Lenovo gibt es schon eine Quelle im Atikel. Zu anderen Herstellern findet man sicher auch noch Infos.

Was ich an der jetzigen Formulierung ungeschickt finde, ist der erste Satz: "Die Aussage, das BIOS würde die aktive Partition suchen und den Bootsektor (VBR) dieser Partition starten, ist im Allgemeinen falsch…" Das ist zwar nicht falsch, aber da es nicht "Das BISO" gibt, steht die Aussage im Widerspruch zu "Einige Hersteller entwickelten jedoch BIOS-Varianten die zusätzliche Funktionen bieten, wie z. B. ein Auswahlmenü welches das Starten von einer beliebigen Partitionen erlaubt…" Könnte man das nicht offenere, weniger allgemein formulieren? Der jetzige Text könnte stellenweise auch so verstanden werden, dass es eine Norm/einen Standard gibt, für "Das BIOS." Nur kenn ich keinen solchen. Ev. weisst du da mehr darüber: Hatte IEEE oder eine anderes Normierungs-/Standardisierungs-Gremium dazu etwas geschaffen? Wenn ja, könnte man zwischen standard-konformen und anderen Funktion unterscheiden. Da aber kein solcher Standard/Norm im Artikel erwähnt wird, kann man auch nicht von "Dem BIOS" schreiben. Die die BISO von Lenovo, Compaq und Dell sollten gleichwertig mit anderen betrachtet werden und nicht als Sonderfall.

Ich hoffe, du kannst meine Gedanken nachvollziehen. --Thomei08 09:14, 24. Sep. 2013 (CEST)

Ich denke, dass es mehr eine unterschiedliche Anschauung ist, die wir zwei da haben.

Einen BIOS-Standard per se habe ich noch nie gesehen. Wie ich bereits versucht habe zu verdeutlichen, heißt der Standard “IBM PC”, und dieser beinhaltet eine PC-kompatible Firmware, welche beim IBM-PC eben BIOS heißt. Dieses wurde, ich hatte es weiter oben schon einmal geschrieben, von Drittfirmen (neudeutsch:) „reverse-engineered“. Es ist kompatibel zum original IBM-PC-BIOS. Dieses hat bestimmte Eigenschaften (BIOS-Funktionen aka “System Calls” etwa), an die sich auch die BIOS-Implementierungen der anderen Firmen (American Megatrends, AMI, Phoenix, Award, …) halten müssen, damit PC-Betriebssysteme (allen voran MS-DOS/PC DOS) damit laufen. Eine weitere notwendige Eigenschaft ist, wie das BIOS ein Betriebssystem startet…

Aber, lass mich – nur um es auch wirklich ganz klar zu verdeutlichen – annehmen, dass es umgekehrt besser ausgedrückt ist:

Ein BIOS startet ein Betriebssystem entweder, indem es den MBR lädt und ausführt, oder, indem es die Partitionstabelle selbst ausliest und entweder ein entsprechendes Startmenü einblendet oder über eine Funktion in ein vorbereitetes Betriebssystem, das meist auf einer versteckten Partition liegt, startet. Dabei handelt es sich meist um Sicherungs-/Wiederherstellungs- und/oder Diagnoseprogramme.

Dieser Satz klingt toll, aber er trifft nur auf Komplettsysteme von der Stange zu, weil nur diese bereits vorbereitete Service Partitions aufweisen, die diese Funktionen überhaupt erst möglich machen. Kauft man sich jedoch ein Mainboard selbst, so wird das BIOS in fast allen Fällen eine derartige Funktion nicht bieten. Die Funktion, dass das BIOS den MBR einfach nicht ausführt und stattdessen eine bestimmte Partition direkt startet ist eher ein „Extra“.

Ist es also nicht besser, wenn man von einem allgemein gültigen Verfahren ausgeht, und erst in einem weiteren Absatz etwaige Sonderfunktionen erwähnt, die nicht auf alle BIOS-Varianten zutreffen?

Der Satz suggeriert weiters, dass es einen häufigen Umstand darstellt. Aber außer Dell-Systeme und fertige IBM/Lenovo-PCs ist eine derartige Zusatzfunktion nicht zu finden. Auf Laptops findet sich vielleicht noch die ebenfalls schon genannte MP3-Player-Funktion. Aber auch diese ist eher ein „Extra“ als eine häufig anzutreffende Funktion.

Wie man es nun schreibt ist also beinahe eine Geschmacksfrage, wobei es jedoch augenscheinlich um die Anschauung geht.

Wenn es dir so wichtig ist, bitte ich dich, doch einmal einen Vorschlag zu machen, wie man es deiner Meinung nach anders schreiben könnte. Ich bitte dich weiters, nicht das bestehende umzuschreiben sondern komplett von vorne zu beginnen. Vielleicht finden wir ja einen Weg, der uns beide zufrieden stellt.

‣Andreas•⚖ 22:24, 24. Sep. 2013 (CEST)

Überarbeiten_

Dennoch ist dieser Artikel, übrigens inklusive der Anmerkungen im Diskussionsteil, das Beste, was ich je über Masterbootrecords gelesen habe! Ich möchte Euch herzlich DANKEN! --84.46.77.214 16:26, 12. Feb. 2014 (CET)

Was hier in der Diskussionsseite von mir als schlechten Artikel bezeichnet wurde, waren die alten Versionen von Master Boot Record und Partitionstabelle, welche zusammengemischt waren und inhaltlich NUR am MBR ausgerichtet waren. Die anderen Partitionstabellen waren damit außen vor, weil ständig Partitionstabelle und MBR vermischt wurde. Seither hat sich einiges getan, und es freut mich, wenn der Artikel gefällt. Es haben ja auch viele Autoren beigetragen!

‣Andreas•⚖ 22:03, 12. Feb. 2014 (CET)

CHS versus LBS

Der Artikel erklärt scheinbar überhaupt nicht wann warum welche der beiden Adressierungsarten zum Tragen kommen oder wie sie evt. innerlich miteinander kompatibel sind. In diesem Zusammenhang fehlt auch der nicht mal erwähnte DOS-Kompatibilitätsmodus. --Itu (Diskussion) 17:29, 22. Aug. 2014 (CEST)

Auf welchen DOS-Kompatibilitätsmodus beziehst du dich? ‣Andreas•⚖ 21:18, 22. Aug. 2014 (CEST)

Auf den in man fdisk so genannten. --Itu (Diskussion) 02:24, 23. Aug. 2014 (CEST)

So, wie ich das in der (deutschen) man-page lese, handelt es sich lediglich um Kompatibilität von Linux zu DOS – weil Linux C/H/S gar nicht verwendet, DOS jedoch ausschließlich und Windows beides. Allerdings könnte das auch falsch sein, weil DOS noch einige andere sonderbare Spezialfunktionen verwendet, etwa für den FORMAT-Befehl.

Wie dem auch sei, wer da genau durchblickt, kann es gerne in den Artikel mit einbringen…

Wenn wir allerdings schon bei fehlenden Informationen sind: auch die OEM-Partitionstabelle von OEM-MS-DOS für NEC mit den 8 Primärpartitionen ist nirgends erwähnt.

Generell finde ich, dass es nicht Aufgabe einer Enzyklopädie sein kann, jeden Sonderfall darzustellen und auch noch technisch zu erklären.

‣Andreas•⚖ 09:32, 23. Aug. 2014 (CEST)

Gilt die Ausssage, dass Linux kein CHS verwende, allgemein für alle Versionen? Linux 0.01 erschien ja 1991, gabs da überhaupt schon LBA? Oder haben die ersten Linux-Versionen noch keine Festplattenunterstützung? --MrBurns (Diskussion) 10:43, 23. Aug. 2014 (CEST)

Hat nicht Linux am Anfang wirklich nur aus einem Kernel bestanden? Das heißt doch, das Userland war von einem anderen System. Da auch das Dateisystem Minix verwendete, kann ich mir gut vorstellen, dass Linux anfangs einfach bloß ein alternativer Kernel für das schon existierende Minix-System war. Nach und nach fanden immer mehr Userland-Tools aus der GNU-Bewegung ihr Zuhause (nicht nur) bei Linux.

Ob und wann nun Linux nur noch LBA unterstützte, ist mir leider nicht bekannt.

Wenn du das recherchieren willst: viel Spaß dabei!

‣Andreas•⚖ 12:05, 24. Aug. 2014 (CEST)

DOS Kompatibilitätsmodus

irgendwie herrscht hierzu grosse Dunkelheit. Kann die jemand beseitigen? -- itu (Disk) 01:40, 22. Mai 2015 (CEST)

Was ist ein DOS-Kompatibilitätsmodus?

‣Andreas•⚖ 13:46, 22. Mai 2015 (CEST)

Ich hab da nochmal nachgeschaut, und jetzt nur die manpage zu (Linux) fdisk gefunden: fdisk(8)

Ja, da ist von einem DOS-6-Modus die Rede (gemeint ist MS-DOS/PC DOS 6 und kompatiblte Betriebssysteme sowie alle Versionen vor API-Version 6). Es geht dabei um die CHS-Addressierung versus LBA-Addressierung. In modernen MBR-Partitionstabellen werden die CHS-Daten weggelassen, weil diese 1. bei großen Partitionen sowieso nicht funktionieren und 2. von aktuellen Betriebssystemen nicht mehr verwendet werden.

Will man also eine (kleinere) Festplatte (oder anderen Datenspeicher) für ein MS-DOS-kompatibles DOS bis inklusive API-Version 6 unter Linux partitionieren, so müsste man den CHS-Modus (Kompatibilitätsmodus) aktivieren. Aber warum sollte man das unter Linux und nicht gleich unter (MS-)DOS machen?

Zitat aus der manpage:

In einer DOS-Partitionstabelle wird der Startversatz (starting offset) und die Größe der einzelnen Partitionen auf zwei Arten gespeichert: als absolute Anzahl der Sektoren (angegeben in 32 Bit) und als Zylinder/Köpfe/Sektoren-Tripel (CHS, angegeben in 10/8/6 Bit). Ersteres ist in Ordnung - mit 512-Byte-Sektoren funktioniert das bis zu 2 TB. Letzteres hat zwei Probleme. Erstens können die C/H/S-Felder nur dann ausgefüllt werden, wenn die Anzahl der Köpfe und die Anzahl der Sektoren pro Spur bekannt sind. Und zweitens, selbst wenn diese Zahlen bekannt sind, reichen die 24 verfügbaren Bit nicht aus. DOS verwendet C/H/S, Windows beides, Linux verwendet C/H/S nie. Die C/H/S-Adressierung ist veraltet, daher ist es möglich, dass diese in zukünftigen Versionen von fdisk nicht mehr unterstützt wird.

Bitte lesen Sie den Abschnitt zum DOS-Modus, wenn Sie DOS-kompatible Partitionen benötigen. fdisk beachtet in der Voreinstellung keine Zylindergrenzen.

Des weiteren gibt es ein spezifisches Problem mit MS-DOS fdisk und MS-DOS format wie folgt:

Der FORMAT-Befehl von DOS 6.x sucht im ersten Sektor des Datenbereichs der Partition nach ein paar Informationen und behandelt diese Informationen als zuverlässiger als die Informationen in die Partitionstabelle. Der DOS-FORMAT-Befehl erwartet vom DOS-FDISK-Befehl, dass die ersten 512 Byte des Datenbereichs einer Partition bei jeder Größenänderung gelöscht werden. DOS FORMAT wird dieser zusätzlichen Informationen suchen, auch wenn der /U-Schalter gesetzt ist - die Programmautoren betrachten dies als einen Fehler in DOS FORMAT und DOS FDISK.

Aber all diese Informationen würden wohl den Rahmen dieses Artikels sprengen. Nochdazu wenn man dann auch anfängt die Inkompatibitäten zwischen z.B. MS-DOS/PC DOS und DR-DOS zu behandeln. Oder zwischen MS-DOS/PC DOS/DR-DOS und Compaq NEC MS-DOS 3.x und PTS-DOS und … es gibt ja noch einige andere DOS-kompatible Betriebssysteme die den MBR verwenden. Dafür gibt es ja dann weiterführende Informationen bei den einzelnen Betriebssystemen, etwa Linux mit den manpages. Wer nur ein DOS oder ein anderes OS, das MBR verwendet, einsetzt, der braucht davon ohnehin nichts zu wissen.

‣Andreas•⚖ 18:18, 22. Mai 2015 (CEST)

Wo hier etwas gesprengt würde sehe ich nicht, sondern nur überhaupt mal ein bis drei Sätze dazu zusammenzubringen.

Mir dämmert grad dass das /U Flag ein Parameter im DOS FDISK Tool sein muss.

Ansonsten bleibt das etwas dunkel was da wo genau hingeschrieben und wie von DOS ausgewertet würde. Aber der DOS Kompatibilitätsmodus begegnet einem auch heutzutage noch, z.B. beim hochaktuellen Thema Alignment und zwar so als müsste man sich damit heute noch damit auseinandersetzen. Für eine Aufklärung wäre es also nicht zu spät. -- itu (Disk) 22:44, 22. Mai 2015 (CEST)

Also ich denke schon, dass es den Rahmen sprengen würde. Die Frage ist, wo man die Grenze ziehen soll.

Sollte man schreiben, dass mein Panasonic-Autoradio den USB-Stick zum Abspielen der MP3s nicht verwenden kann, wenn der MBR nur in C/H/S vorliegt (=die LBA-Partitionsangaben fehlen)? Ist es okay, wenn man schreibt, dass es unterschiedliche Inkompatibilitäten zwischen den einzelnen MS-DOS-kompatiblen DOS-Vertretern gibt (CompaqNEC DOS hatte einen Master Boot Record, der 8 Primärpartitionen aufnehmen konnte)? Soll man auch andere Betriebssysteme mit aufnehmen? Oder sollte man sich auf MS-DOS/PC DOS beschränken? Oder gar auf Microsoft? (Achtung: NPOV!)

Ein Kompatibilitätsmodus ist nur dann erforderlich, wenn es Inkompatibilitäten gibt. Und: ja, diese alle aufzuzählen ist 1. sehr sehr viel Arbeit und 2. ziemlich sinnlos, außer, man will ein ganz spezielles Dual-Boot erstellen. Etwa DR-DOS 3.41 und FreeBSD auf einem Intel 486 mit BIOS. Oder MS-DOS 5.0 und Linux 2.6 auf einem IA-32-PC mit UEFI und CSM.

Partitionsausrichtung aka Partition Alignment gab es ja schon früher. Bei C/H/S kommt es ja nicht von ungefähr, dass man eine Partition immer an der Zylindergrenze ausrichtet. Das ist bei LBA dann später komplett egal, da zählt nur die Sektorgröße.

Die Ausrichtung (das Alignment) ist also nicht ein Problem des MBR, sondern von jedem Partitionierungskonzept (vgl. RAID, LVM), jeder Partitionstabelle und jedem Dateisystem, insgesamt von jedem Betriebssystem. Es hat aber nichts zu tun mit einem Kompatibilitätsmodus.

Wer sich heute, 2015, ein MS-DOS 6 oder früher installieren will, der muss sich wohl oder übel einlesen, ob und wie er am besten partitioniert. Abgesehen davon, dass Partitionstabellen+Partitionen+Dateisysteme unter früheren Betriebssystemen ganz andere Größenlimits aufwiesen und auf modernen Speichermedien mit jenseits von 8 GB ohnehin Probleme damit auftreten werden – im besten Fall wird einfach weniger Speicherplatz erkannt. Und all das jenseits der Frage, ob ein altes Betriebssystem auf einem modernen Computer überhaupt noch lauffähig ist – und zwar nicht nur theoretisch, sondern auch praktisch.

Das alles würde 1. den Rahmen eindeutig sprengen (wo soll man anfangen, wie weit soll man ausholen) und 2. wäre es für 99,9 % der Leser einfach nicht interessant.

‣Andreas•⚖ 20:43, 25. Mai 2015 (CEST)

Du ergehst dich hier in sehr unkonstruktive, nicht zielführende Ausführungen. Niemand hat von einem direkten Zusammenhang des DOS-Kompatibilitätsmodus zum Alignement geredet, den du hier ebenso wortreich wie unnötig widerlegst.

Hier sollte nur nach Möglichkeit erst mal geklärt werden was der DOS Kompatibilitätsmodus ist. Erst wenn das geklärt ist kann man schätzungsweise ein bis drei Sätze dazu im Artikel schreiben. Ich denke allerdings das wird jetzt so schnell nix mehr. -- itu (Disk) 02:25, 26. Mai 2015 (CEST)

@itu: hattest du nicht selbst den DOS-Kompatibilitätsmodus und Alignement erstmals hier in Zusammenhang gebracht? Ansonsten kann ich die Argumentation von Y2kbug gut nachvollziehen --Nobby1805 (Diskussion) 09:28, 26. Mai 2015 (CEST)

Ich habe einen aktuellen Text verlinkt in dem es um Alignment geht und in dem der DOS-Kompatibilitätsmodus vorkommt bzw. erwähnt wird - lediglich um zu zeigen dass der DKM sogar heute noch eine Rolle spielt, das Verständnis dafür also noch nicht obsolet ist. Den Zusammenhang stellt der Text her, nicht ich.

Es geht hier gar nicht darum ob die Ausführungen von Y2kbug zu diesem Punkt nachvollziehbar sind, sie sind einfach nicht am Thema.

Die anderen Ausführungen ("mein Panasonic-Autoradio ...") sind allerdings mindestens genauso daneben(und das mindestens im zweifachen Sinn). -- itu (Disk) 10:59, 26. Mai 2015 (CEST)

Dieser DOS-Kompatibilitätsmodus, den du verlinkt hast, stammt von Thomas Krenn. Vielleicht solltest du ihn fragen, was er damit meint.

Was fdisk unter Linux angeht, so habe ich schon verlinkt und zitiert, was er eventuell damit meinen könnte.

Nun liegt es an dir, hier konstruktiv zu sein.

Denn was du als daneben bezeichnest, ist mein Verständnis davon, warum ich dieses Thema für zu detailiert für die Wikipedia halte. Aber bitte, du kannst mich ja mit konstruktiven Beiträgen vom Gegenteil überzeugen…

‣Andreas•⚖ 14:09, 26. Mai 2015 (CEST)

eine umfassende Erklärung

Neuer Versuch:

Dies ist eine hoffentlich logische Herleitung der Thematik DOS-Kompatibilitätsmodus spezifisch für den Artikel Master Boot Record.

1. Der MBR unter verschiedenen Betriebssystemen:
   • Unter PC DOS/MS-DOS wurde ein MBR verwendet, den man getrost als Standard-MBR oder als Referenz-Implementierung eines MBR ansehen könnte. Siehe An Examination of the Standard MBR.
   • Der MBR wurde auf IBM-PCs und IBM-PC-kompatiblen Computern von den meisten Betriebssystemen für diese Rechnerarchitektur ebenfalls genutzt. Allerdings gab es eine Reihe inkompatibler Implementierungen des MBR: beispielsweise führte NEC mit einem OEM-MS-DOS 3.3 (ich hatte bisher fälschlicherweise Compaq statt NEC geschrieben) eine Partitionstabelle mit 8 primären Partitionen ein, der in dieser Form mit keinem anderen DOS oder PC-Betriebssystem kompatibel ist. Siehe Notes on the Differences in one OEM version of the DOS 3.30 MBR
   • Halten wir fest, dass es eine Reihe von unterschiedlichen Implementierungen eines MBR gibt und gab.
   • Halten wir weiters fest, dass es für die diesen MBR schreibenden (die Partitionen erstellenden) Programme, hauptsächlich fdisk, unter Umständen einen Kompatibilitätsmodus für eine der anderen Implementierungen gibt.
     • Beispiel: NEC FDISK (in NEC MS-DOS 3.3) kann mit einem solchen Kompatibilitätsmodus auch 4-Partitionen-MBRs schreiben (Standard-MBR).
     • Beispiel: Linux fdisk kann mit einem Kompatibilitätsmodus auch einen für PC DOS/MS-DOS geeigneten MBR schreiben (also mit LBA und CHS-Werten in der Partitionstabelle).
     • es gibt sicher noch viele viele weitere solche Beispiele…
2. Alignment, also die Ausrichtung der Partitionen auf Sektoren oder andere Grenzen:
   • Moderne Partitionierungswerkzeuge richten Partitionen automatisch so aus, dass sie auf 4k-Sektoren ideal passen, weil es heute nunmehr gängiger ist, ein Speichermedium mit Advanced Format (englisch) (=Sektoren à 4096 Bytes) zu verwenden als ein herkömliches Speichermedium mit Sektoren à 512 Bytes.
   • fdisk, parted, gdisk, gpt, die Datenträgerverwaltung, Disk Utility, … alle gängigen aktuellen fdisk-Pendants partitionieren aktuell in der Standardeinstellung 4k-kompatibel.
   • Die CHS-Adressen (zusätzlich oder statt den heute üblichen LBA-Adressen) im MBR haben mit einem Alignment nichts zu tun!
   • Der von itu gezeigte aktuelle Artikel zum Alignment enthält eine Erwähnung des Linux-fdisk-Kompatibilitätsmodus, weil Linux fdisk mit dieser Einstellung nicht nur einen DOS-kompatiblen MBR inklusive CHS-Werten erzeugt, sondern auch Zylindergrenzenausrichtung aka Cylinder alignment vornimmt, wie es von DOS bis 6.0 so erwartet wurde und damals auch vernünftig war, weil es ja ohnehin keine SSDs gab, die man nun anders ausrichten sollte. Das ist für das Alignment auf modernen SSD natürlich kontraproduktiv, weshalb der Artikel dasrauf hinweist, diesen Kompatibilitätsmodus zum Zwecke eines Alignments tunlichst zu deaktivieren.
     Warum macht fdisk das also? Warum ein Cylinder-Alignment zusätzlich zu den eigentlich nur gewünschten CHS-Werten? Nun, da DOS mit modernen Ausrichtungen aber eventuell/vermutlich/sicher (? das wäre zu klären…) nicht zurecht kommt, kann man in einem DOS-kompatiblen Modus einfach schon deswegen keine Ausrichtung auf 4k- oder gar 8k-Sektoren vornehmen. DOS könnte davon dann nicht mehr starten und auch nicht darauf zugreifen. Deshalb muss man das mit dem Alignment hinten anstellen, wenn man DOS-kompatibel bleiben möchte. Der DOS-Kompatibilitätsmodus macht also zwei Dinge: 1. CHS (was NUR mit dem MBR zu tun hat) und 2. Alignment (was NUR mit den damals verwendeten Festplatten zu tun hat). Beides ist nötig, um DOS-kompatibel zu sein.
   • Um DOS-kompatibel zu sein, braucht man allerdings auf jeden Fall eine Festplatte, die 512-Byte-Sektoren meldet – auch wenn sie intern vielleicht 4k-Sektoren verwendet. Die 512-Byte-Sektoren sind Voraussetzung dafür, das DOS damit überhaupt korrekt funktioniert! Das gleiche gilt übrigens auch für Mac OS (Classic) und Mac OS X/PowerPC mit der Apple Partition Map.
   • Und das ist dann auch das Wesentliche des Alignment: um kompatibel zu bleiben, melden Speichermedien mit 4096-Byte-Blöcken einfach 512-Byte-Blöcke und die interne Logik im Controllerchip kümmert sich darum, dass, wenn so ein 512-Byte-Block (Block entspricht Sektor) gerschrieben wird, in Wirklichkeit der 4096-Byte-Block gelesen, die geänderten 512 Bytes ausgetauscht und der veränderte 4096-Byte-Block wieder geschrieben wird.
     • Das hat natürlich Einfluss auf die Performance: es wird langsamer (weil statt 512 Bytes geschrieben immer 4096 Bytes gelesen, verarbeitet und geschrieben werden müssen).
     • Das hat aber den Vorteil, dass ein Speichermedium mit 4096-Byte-Sektoren uneingeschränkt kompatibel zu bestehenden und älteren Betriebssystemen und Programmen bleibt.
     • Die Betriebssysteme und Programme haben sich seit dem Erscheinen der geänderten Sektorgröße angepasst und nehmen nun standardmäßig ein Alignment, also eine Sektorausrichtung, vor. Das betrifft sowohl die Partitionen, wie auch die Dateisysteme wie auch alle Programme, die damit zu tun haben (etwa die Pendants von FORMAT, FDISK, CHKDSK, …).
     • Alte Betriebssysteme werden nicht mehr angepasst. Damit muss man, wenn man es will und kann, ein manuelles Alignment vornehmen, was in dem verlinkten Artikel Partition Alignment sehr gut beschrieben steht. Ob diese Ausrichtung dann aber auch 100% mit z. B. einem MS-DOS 2.0 funktioniert, das ist damit noch nicht gesagt.

Conclusio

1. Alignment:
   • Alle Aspekte von Alignment (Ausrichtung) sind meiner Meinung nach sehr spezifische Information, die nur teilweise etwas mit dem MBR zu tun haben – immerhin ist auch Mac OS und Mac OS X mit der Apple Partition Map (verwendet auch 512-Byte-Sektoren) davon betroffen und es geht mehr um das jeweilige Betriebssystem und dessen Werkzeuge (fdisk, format) als um die Partitionstabelle. (Vgl. Apple TechNote 2166).
   • Natürlich ist auch die Partitionstabelle wichtig beim Alignment.
2. DOS-Kompatibilitätsmodus
   • Der Artikel Master Boot Record behandelt (derzeit) den Standard-MBR und nur den.
   • Wäre es möglich, alle anderen (inkompatiblen) MBRs einzuarbeiten und zu erwähnen? Ja.
     • In 3 Sätzen? Eher nicht.
     • Nur den DOS compatibility mode von Linux-fdisk? Eher nicht – das wäre WP:NPOV.
     • Täte es dem Artikel gut? Eher nicht – wer genaueres wissen will, wird früher oder später bei einem Fachbuch oder im Internet fündig, etwa bei Starman's Realm. Ja, man könnte tatsächlich ein ganzes Buch mit >500 Seiten nur über das Thema Master Boot Record füllen. Aber ist das der Zweck einer Enzyklopädie? WP:WWNI
     • Für alle anderen reicht es schon, wenn sie etwas über den Standard-MBR lesen.

Aber es ist natürlich jeder herzlich eingeladen, das anders zu sehen und Verbesserungen vorzunehmen. Es sollte dennoch darauf geachtet werden, übersichtlich zu bleiben. Immerhin gibt es in der Wikipedia WP:OMA, also das Oma-Prinzip.

Ich hoffe, das ist halbwegs objektiv und nachvollziehbar.

‣Andreas•⚖ 11:51, 31. Mai 2015 (CEST)

Ich glaube dieser Text jetzt ist sowenig am Punkt wie zuvor, sondern noch extrem weiter ausgewalzt - aber zugegeben sehr gut und nützlich fürs Gesamtverständnis des ganzen Themas. Wie üblich vermisse ich leider an entscheidenen Stellen Beleglinks.

Für weitere Antwort meinerseits muss ich erst selber Zeit aufbringen um mir die Sache zu recherchieren, wozu ich jetzt leider keine Prognose abgegeben kann. -- itu (Disk) 14:42, 31. Mai 2015 (CEST)

falsche Synonyme

Die Synonyme Partitionssektor und master boot sector findet man immer wieder, doch sind sie falsch, weil das, was gemeint ist (und das erschließt sich immer eindeutig), der Master Boot Record (MBR) ist.

Es ist also nicht bloß falsch, weil ich das so sagen würden, sondern weil der Name und die offizielle Bezeichnung dieses Bootsektors+Partitionstabelle eben Master Boot Record ist – und nicht partition sektor oder master boot sector.

Ich habe den Abschitt Synonyme hinzugefügt, weil ich oftmals feststellen müsste, dass die Leser dieser Artikel das glauben, was dort falsch steht bzw. weil sie dadurch verwirrt werden. Die glauben dann, der MBR wäre eine Partitionstabelle (partition sektor, Partitionssektor), und vergessen dadurch, dass es auch einen Master Boot Code gibt – was dann dazu führt, dass die Behauptung in den Raum gestellt wird, das BIOS würde die Partitionstabelle aus diesem Sektor lesen und interpretieren (initialisieren). Das ist schlichtweg falsch, mit der Ausnahme von besonderen (aber bei jedem Hersteller unterschiedlichen und nicht immer vorhandenen) Sonderfunktionen. Doch die Ausnahme wird dann zur Regel, und plötzlich sei es dann immer so – was falsch ist.

Wenn vom Master Boot Sector gesprochen wird, wird oft nur an einen Bootsektor gedacht, und die Partitionstabelle unterschlagen. Der Ausdruck Master Boot Sector (MBS) ist ebenfalls falsch, weil die Bezeichnung dieses Bootsektors+Partitionstabelle eben Master Boot Record heißt und nicht anders.

Was ist daran also auszusetzen? Welche Referenzen (Belege) dafür, dass es Master Boot Record heißt, brauchst du denn? Du wirst dir schwer tun, eine Spezifikation oder einen Bootcode oder eine binäre Aufschlüsselung einer Partitionstabelle aus dem MBR zu finden, wo es dann plötzlich partition sector oder master boot sector hieße. Diese gibt es nicht, weil es keinen partition sector und keinen master boot sector gibt. Du wirst dir aber auch schwer tun, eine Quelle zu finden, die besagt: „es gibt keinen partition sector und auch keinen master boot sector, weil es Master Boot Record heißt“.

Das ist das Dilemma.

Und wie weiter jetzt?

‣Andreas•⚖ 22:07, 3. Jun. 2015 (CEST)

Hm, ich verstehe dein Ding überhaupt nicht mit dem Unterschied von Record und Sector, wo soll denn da überhaupt der Unterschied liegen?

Aber es gibt doch sowieso kein Dilemma da ich beide Begriffe rausgenommen habe. Damit sollte sich doch alles erledigt haben aus deiner Sicht. -- itu (Disk) 16:10, 4. Jun. 2015 (CEST)

Ich verstehe jetzt nicht, warum du das nicht verstehst.

Ich habe den Abschnitt aufgenommen, und du streichst ihn wieder. Und verstehst meine Gründe offenbar nicht, die den Abschnitt für mich wichtig erscheinen lassen.

Also: der Unterschied zwischen Record und Sector ist nicht relevant – das könntest du in einem Englisch-Deutsch-Wörterbuch nachschlagen.

Worum es geht, ist, dass es eben Master Boot Record und nicht Master Boot Sector heißt. Das ist eine Tatsache.

Eine Analogie: Was ist der Unterschied zwischen micro und tiny? Egal, sagen wir einfach mal Tinysoft statt Microsoft.

Ergo, 1. Teil: wir erkennen, Master Boot Record und Mircosoft ist richtig, Master Boot Sector und Tinysoft ist falsch.

Okay, das wäre nun geklärt. (Hoffentlich.)

Doch halt! Einige Fachzeitschriften, die auch online vertreten sind, schreiben nun fälschlicherweise Master Boot Sector. Also haben wir nun die Situation, dass es Leser gibt, die durch das Lesen dieser Fachzeitschriftenartikel verwirrt sind (in etwa so: was ist es denn nun? MBS, Partitionssektor oder MBR?). Also ist es gut, wenn wir diese Verwirrung auflösen.

Hätten Fachzeitschriften statt Microsoft auch oft Tinysoft geschrieben – was falsch ist – so müsste das auch in den Microsoft-Artikel, weil sich die Leser, die von Tinysoft gelesen haben, sonst nicht auskennen. Man muss natürlich darauf hinweisen, dass das eine richtig und das andere falsch ist.

Ergo, 2. Teil: WEIL es einige Fachartikel über die Partitionierung beim PC gibt, die falsche Begriffe verwenden, wenn sie eigentlich den MBR meinen, wäre es angebacht, diese Begriffsverwirrung hier aufzugreifen und aufzulösen.

Verstehst du jetzt, was das Dilemma ist?

‣Andreas•⚖ 16:54, 4. Jun. 2015 (CEST)

Entschuldigung, aber ich muss weiter den Kopf schütteln.

Das einzige was ich verstehe ist dass du Leser vor deiner Meinung nach falschen Begriffen warnen willst.

Synonyme sind allgegenwärtig. Dazu muss man z.B. nur die Anfangszeilen vieler Wikipediaartikel lesen.

Synonyme sind nicht falsch. (irgendwie schon per def.)

Ein Vergleich von Fachbezeichnungen mit (Marken)Namen ist mehr als nur hinkend, sondern abwegig.

Was du hier reklamierst ist auf dem gleichen Niveau wie wenn du behaupten würdest „Festplatte ist ein falscher und irreführender Begriff und der Leser muss über diesen Fakt aufgeklärt werden, es heisst in jedem Fall Festplattenlaufwerk.“

record heisst in meinem Wörterbuch Aufzeichnung / Datensatz. Was ist nun daran falsch bzw. was ist der Gegensatz oder die Unvereinbarkeit mit Sektor ?

Und es ist doch so dass der MBR ein Bootsektor ist und auch so bezeichnet wird (und man kann locker sagen es ist DER Bootsektor, weil der zentrale ).

Und als ob das alles noch nicht überzeugend genug wäre findet man beispielsweise im EN-Artikel den Satz „ A partition table describing the partitions of a storage device. In this context the boot sector may also be called a partition sector.“ - Und mit the boot sector ist an der Stelle auch exakt der MBR gemeint.

Am Ende bleibt dass die Synonyme die du für völlig falsch hältst aktuell nicht im Artikel sind, aber du willst sie wieder drin haben um vor ihnen zu warnen. -- itu (Disk) 20:51, 4. Jun. 2015 (CEST)

Wie du richtig bemerkst, ist parition sector im englischen MBR-Aritkel erwähnt, und das ja nicht ohne Grund. Diese Synonyme werden (leider) benutzt, und da es die Aufgabe einer Enzyklopädie ist, zu informieren, müssen die genutzten Begriffe natürlich vorkommen.

Mein Vergleich hinkt allerdings gar nicht. Deiner leider schon. Es gibt nämlich ein Festplattenlaufwerk (1960er Jahre) und es gibt Festplatten (kann regulär nicht geöffnet werden). Und es gibt auch SSDs (Solid State Drives), obwohl die keine drives also Laufwerke sind, aber sie heißen dennoch so. Und das ist auch richtig.

Und genau darum geht es: wie was heißt!

Genauer: wie heißt es offiziell und richtigerweise?

Und dann sollte man in einer Enzyklopädie noch dazuschreiben, dass es geläufige Synonyme gibt. Diese sind allerdings fachlich nirgendwo zu finden, daher sind sie falsch. (Ich habe noch keine einzige fachspezifische Informationsquelle entdeckt, die die Bezeichnungen MBS oder partition sector genutzt hätte.)

Ich wollte hier eigentlich nicht WP:TF betreiben, sondern nur das darbringen, was ich für fachlich (belegbar) richtig halte.

1. Belegbar ist, dass es richtig Master Boot Record heißt. Und zwar nur so, und nicht anders.
2. Belegbar ist, dass der MBR ein Bootsektor ist.
3. Belegbar ist aber auch, dass der MBR eine Partitionstabelle ist.
4. In diversen Artikeln findet man Synonyme,
   • die einmal mehr in Richtung Bootsektor ausschwenken: Master Boot Sector
   • und einmal mehr in Richtung Partitionstabelle: Partitionssektor oder partition sector
5. Diese Synonyme sind auch belegbar, weil sie da sind. Fachlich sind sie aber falsch: der MBR heißt nicht so.
6. Fachlich sind sie auch falsch, weil
   • was soll Master Boot Sector heißen? Bootsektoren gibt es viele, aber die meisten enthalten nicht gleich auch eine Partitionstabelle.
   • was soll partition sector heißen? Wenn es nur eine Partitionstabelle in einem Sektor (Datenblock) wäre, dann wäre es kein Bootsektor. (Vgl. andere Partitionstabellen wie etwa die Apple Partition Map → kein Bootsektor, nur eine Partitionstabelle)

Für dich scheint das einerlei zu sein, ist es aber nicht.

1. Bootsektor
2. Partitionstabelle

Das sind zwei unterschiedliche Dinge.

Der MBR ist beides und sein Name ist Master Boot Record. So wie Microsoft, Festplatte und Solid State Drive.

Verstehst du jetzt? ‣Andreas•⚖ 21:39, 4. Jun. 2015 (CEST)

Nein, ich werd nur kirre und deine Argumentation mit Festplatte* und SSD ist auch noch komplett widersprüchlich zu dem was du hier zum MBR reklamierst. Jetzt schreibst du die angebl. falschen Synonyme "sind allerdings fachlich nirgendwo zu finden", weiter oben hast du ausführlich das Gegenteil geschrieben.

Ich weiss nicht ob dirs aufgefallen ist aber Solid-State-Drive ist mit 3 Synonymen vertreten (obwohl gerade hier bekanntlich eine geradezu exemplarische Bedeutungswidrigkeit vorliegt, bei allen dreien sogar).

Wenn man einen gängigen Begriff als falsch erklärt dann muss man einen Grund angeben können und da gibts eigentlich nur Irreführung und das ist nicht zu erkennen.

Es gibt offenbar keine Organisation mit Autorität die den Begriff streng normiert hat - warum sollte sie auch wenn es keine Verwechslungsprobleme gibt. Da gibt es eine Mio. sinnvollere Sachen zu normieren.

Ich sehe hier nur dich allein der die Auffassung vertritt dass 2 Synonyme als falsch deklariert werden müssen.

Und belegen (aka Quellen zitieren) kannst das wohl auch nicht. Damit sollte es eigentlich erledigt sein. -- itu (Disk) 22:51, 4. Jun. 2015 (CEST)

Nein, damit ist das nicht erledigt.

Quellen sind zu genüge im Artikel. Soll ich dir jetzt nochmal jede einzeln hier aufbreiten, um das zu zeigen?

Eigennamen sind nicht diskutabel, wie du bei meinem Beispiel Microsoft selbst gesehen hast. Und der Eigenname dieses Bootsektores+Partitionstabelle ist Master Boot Record.

Wenn es einen richtigen Namen gibt, es aber in diveren Fachartikel – und das ist wohl nicht klar rübergekommen: gemeint sind Fachartikel in Computerzeitschrift, allerdings sind die meist nicht für Fachpublikum gedacht sondern für Heimanwender – also, wenn es aber in diversen Fachartikeln in Computerszeitschrift dann anders genannt wird, also ein anderer Name benutzt wird, dann gehört dieser in den Artikel. Als Synonym.

Liest man technische Fachartikel über den MBR (für Entwickler, Programmierer – also solche, wo ein Heimanwender aussteigt), so heißt es immer (richtig) Master Boot Record. Es tut mir leid, wenn ich das zu unklar formuliert hatte.

Und wenn es einen richtigen Namen gibt, dann sind die anderen falsch – oder zumindest eben nicht ganz richtig. Wieso siehst du das anders?

Und, was du bei Festplatte und SSD nicht verstehst, das kapier ich auch nicht. Deine Frage war ja, was auszusetzen ist an Record versus Sektor. Nun, gar nichts. Es geht um Eigennamen. Bei SSDs gibt es Leute, die etwas auszusetzen haben an der Tatsache, dass eine SSD ja keine Disk oder kein Drive ist. Aber es geht eben um Namen, wie sie einer Erfindung von den Entwicklern gegeben wurden. So heißt die SSD eben so, obwohl sie keine drehenden Scheiben besitzt – der Name wird nicht geändert. Und der Master Boot Record heißt eben so, weil er von IBM und Microsoft so genannt wurde. Der Name darf auch nicht geändert werden, nur weil irgendjemand keinen nennenswerten Unterschied zwischen Record und Sektor sieht.

Der Zusammenhang erschließt sich dir immer noch nicht?

Auf den Punkt gebracht: es wäre Theoriefindung, wenn man das Ding anders nennen würde.

Jedoch gleichzeitig das Gegenteil, nochmal auf den Punkt gebracht: man muss die gebräuchlichen Begriffe – auch wenn diese falsch (im Sinne von: so heißt es eben nicht!) – ebenfalls anführen, weil dies eben eine Enzyklopädie ist.

Also muss Partitionssektor aka partition sector und Master Boot Sector wieder in den Artikel. Wie man das schlussendlich formuliert, darüber kann man streiten. Ich behaupte ja nicht, dass meine Fomulierung perfekt war. Aber nicht erwähnen geht auch nicht.

Oder bist du da anderer Meinung? Und wenn ja, warum?

‣Andreas•⚖ 23:45, 4. Jun. 2015 (CEST)

Das „Master Boot Record“ ein unveränderlicher Eigenname vergleichbar einem Firmennamen ist und keine Synonyme duldet, ist offenbar eine fixe Idee von dir und von sonst niemand anderem.

Ist jetzt der EN-Artikel für dich nicht falsch der diese Synonyme ganz normal anführt, ohne sie als falsch zu qualifizieren?

Sind die drei Synonyme in der Einleitung von Solid-State-Drive jetzt für dich alle 3 richtig oder nicht? Wo ist dann der Unterschied zu hier. Dort OK, hier aus unerfindlichen Gründen falsch?

Offenbar gibt es für deine Ansicht keine Belege, denn du hast bis jetzt keinen einzigen angeführt. Es war auch kein Beleg da bevor ich diese Privattheorie samt deinem Abschreckungsbeispiel entfernt habe.

Deine Thesen sind auch völlig abstrus: Ein Name ist nicht geändert wenn neben ihm Synonyme existieren.

Die Situation ist klar: WP:Keine Theoriefindung. -- itu (Disk) 12:43, 5. Jun. 2015 (CEST)

Ja, du hast mich entlarvt. Ich wollte die Geschichte der Welt auf diesem Wege umschreiben… </sarkasmus>

?!?!?

Die Art der Formulierung ist nicht das Thema – wir können das gerne besser schreiben.

Der englische Artikel schreibt das nicht so schlecht, weil er sagt: “It may contain one or more of: A partition table describing the partitions of a storage device. In this context the boot sector may also be called a partition sector.” In this context, also in diesem Zusammenhang – bezogen auf die enthaltene Partitionstabelle – may, also könnte auch von einem Partitionssektor gesprechen werden.

Ich habe nie gesagt, dass ich die Synoyme nicht im Artikel haben will. Offenbar geht es um das Wie. Und du unterstellst mir eine Privattheorie, die ich so nicht habe. Meine Logik war und ist, dass es einen offiziellen Namen für das Thema gibt, dieser ist gleichlautend mit dem Lemma, und dass es Synonyme gibt, die allerdings auf einen Kontext bezogen sind. Das steht ja in der englischen Wikipedia auch so. Dort soll es also passen, und hier nicht?

Sind wir uns hier einig? Die Synonyme müssen im Artikel stehen? Ja?

Dann geht es um das Wie.

Ich kann damit leben, dass die böse Unterstellung und Privattheorie meinerseits, dass, wenn Master Boot Record richtig ist, die Synonyme das nicht sind (das Gegenteil von richtig ist falsch), dass wir diese böse böse Unterstellung nicht hineinschreiben. Dann muss aber wenigstens der Kontext stimmen. Die englische Wikipedia macht das wie gesagt nicht so schlecht.

Also, reden wir jetzt bitte, bitte über das Wie?

‣Andreas•⚖ 13:39, 5. Jun. 2015 (CEST)

Nachtrag: Oder doch nicht – ich habe es mir anders überlegt. Es heißt nur Master Boot Record. Weil ich ohnehin der Meinung bin, dass die falschen Synonyme falsch sind, verschweigen wird die einfach. Dass die Leser das eine oder andere Mal (in irgendwelchen Artikeln in Computerzeitschriften oder im Internet) einen anderen Begriff lesen, ist mir einfach egal. Denn ich will ja unbedingt meine Privattheorie durchsetzen… </ironie> ‣Andreas•⚖ 13:49, 5. Jun. 2015 (CEST)

Weißt du was, ich werde das einfach mal umsetzen… bei Zeiten… ‣Andreas•⚖ 22:48, 5. Jun. 2015 (CEST)

Update: Resultat. Was hältst du davon? ‣Andreas•⚖ 13:03, 6. Jun. 2015 (CEST)

Siehe meine Änderungen.... -- itu (Disk) 03:37, 9. Jun. 2015 (CEST)

Änderungen

Einleitung: Verwendung auf anderen Systemen

Was jetzt drinnen steht:

• Der MBR wurde hardwareseitig mit dem IBM PC-XT eingeführt (heißt: der IBM PC-XT war der erste Computer überhaupt, auf dem der MBR im Auslieferungszustand zu finden war, also keine hardwareseitige Unterstützung, sondern ein erstes auftauchen des MBR seitens einer so verkauften Hardware).
• Der MBR wurde mit PC DOS/MS-DOS 2.0 eingeführt.

Was jedoch jetzt fehlt:

• Der MBR wird von so gut wie allen PC-Betriebssystemen, wenn diese auf einem BIOS-basierten Computer laufen, unterstützt/vorausgesetzt/verwendet (und somit erstellt, falls nicht vorhanden). Beispiele: Linux, FreeBSD/OpenBSD/NetBSD, OS/2, Windows NT.
• Der MBR wird von vielen Geräten unterstützt, wenn diese die Möglichkeit zum Anschluss von externen Speichermedien bieten (meistens über die USB-Schnittstelle). Beispiele: Fernseher (kann von USB-Stick .mp4/.divx/.avi/.mov/...-Filme wiedergeben), Radio und Autoradio (ditto für MP3-Dateien), Smartphone (z.B. OTG-Modus bei Android), diverse Haussysteme wie elektronisch geregelte Heizungssysteme (wenn diese eine USB-Schnittstelle bieten), etc.

Das hatte ich versucht, mit diesem Satz zu beinhalten:

Der MBR findet jedoch auf vielen weiteren Speichermedien anderer Betriebssysteme und Geräten, wie z. B. Fernsehern, Radio-Empfangsgeräten und Autoradios, MP3-Playern und vielen weiteren Geräten mit USB-Schnittstelle, Verwendung.

Du hast es gelöscht und jetzt steht da:

Der MBR findet auch auf Flashspeichermedien wie USB-Sticks oder Speicherkarten Anwendung.

Jetzt hast du dich auf Flashspeichermedien beschränkt, obwohl auch Festplatten mit MBR genutzt werden könnten. Außerdem ist es die umgekehrte Sichtweise. Ich beziehe mich auf die Geräte, die den MBR unterstützen müssen (lesen müssen), du dich auf die Medien, die einen MBR enthalten (denen es aber völlig egal ist, was gespeichert ist, weil sie den MBR ja nicht selbst nutzen können).

Außerdem verstehe ich deinen Änderungskommentar nicht. Du schreibst: das ist schonmal _totaler_ Quark: MBR gibts überall wo x86-kompatible Rechner sind, Konsumerprodukte einzeln aufzuzählen ist da sinnlos, doch ist z.B. ein Autoradio sicher kein x86-Gerät, aber es ist dennoch mit dem MBR kompatibel (bei USB-Sticks). Da das also nicht selbstverständlich ist, sollte es doch zumindest erwähnt werden!

Was schlägst du also vor?

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

„Der MBR wird von so gut wie allen PC-Betriebssystemen ...“ - dann schreib das doch so rein.

Lies bitte einfach mal meinen Kommentar https://de.wikipedia.org/w/index.php?title=Master_Boot_Record&diff=next&oldid=142837343

"Medien denen es völlig egal ist, was gespeichert ist, weil sie den MBR ja nicht selbst nutzen können" - was für eine abstruse Aussage: als ob Medien sich selbst lesen könnten.

Es ist abwegig einzelne Produkte aufzuzählen, die ein embedded (PC-)OS besitzen. Genauso müsste das für jede von zighundert/tausend anderen Teilen eines OS gemacht werden wie Bibliotheken. Man könnte auch schreiben dass der MasterBootRecord auf dem Planet Erde in der Milchstrasse vorkommt. Anders gesagt: Kein vernünftiger Mensch kommt auf die Idee daruf zu bestehen ausdrücklich mitzuteilen dass in einem Autoradio Schrauben, Platinen, Kabel enthalten sind, weil das logisch ist bei einem elektronischen Gerät, und wers nicht weiss liest es unter Elektronik,etc. nach. -- itu (Disk) 19:52, 10. Jun. 2015 (CEST)

Zentrale Datenstruktur

Was ist bitte eine zentrale Datenstruktur?

Für BIOS-basierte Computer IBM-PC-kompatible Computer ist der MBR gerade KEINE zentrale Datenstruktur, weil der IBM-PC eigentlich jeden Inhalt im ersten Sektor à 512 Byte ausliest, die Signatur prüft, und diesen dann im Real Mode ausführt. Weiter geht der IBM-PC und das BIOS nicht. Da muss nicht zwangsweise ein MBR stehen.

Das muss definitiv geändert werden, weil es einfach nicht stimmt.

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

Man kann um solche Formulierungen streiten und sie ersetzen wenn man bessere findet, die ist ad hoc entstanden.

Du explizierst hier immer wieder Dinge und folgerst abwegiges daraus: wer hat denn wo behauptet dass da „zwangsweise ein MBR stehen“ muss?

Das rein theoretisch da kein MBR stehen muss, ändert nichts daran dass der MBR überall bei PS-OSen verwendet wird. -- itu (Disk) 20:00, 10. Jun. 2015 (CEST)

Dings

1. Der Master Boot Record (MBR) beinhalt bei einem bootfähigen Datenträger zwei Dinge:
2. Der Master Boot Record (MBR) ist in zwei unterschiedliche Funktionen aufgeteilt:

Gut, ich gebe zu, dass auch meine Formulierung (2.) nicht wirklich zu 100% gelungen ist. Aber Dinge? Ernsthaft? Das lustige ist, ich hatte beim Verfassen anfangs auch genau Ding[s|e] stehen, habe es aber durch das mMn bessere Wort Funktionen ersetzt. Weil, ein Ding kann ja wirklich alles sein. Oder nichts.

Nicht wirklich besser → ändern.

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

Dinge ist nicht die Krönung sprachlichen Ausdrucks. Aber besser als Begriffe die etwas schlecht beschrieben. -- itu (Disk) 20:05, 10. Jun. 2015 (CEST)

Du sitzt auf einem sehr hohen Ross. Komm wieder herunter.

‣Andreas•⚖ 21:53, 10. Jun. 2015 (CEST)

Master Boot Code

Da der MBR ursprünglich für BIOS-basierte Computer entwickelt wurde, ist das Startprogramm (englisch Master Boot Code) ein wesentlicher Bestandteil dieses Partitionierungskonzepts, da auf IBM-PC-kompatiblen Computern mit BIOS ohne dieses Programm die Partitionstabelle nicht ausgewertet und genutzt werden kann.

Was ist an diesem Satz nicht verständlich?

• Der Master Boot Code ist das Programm, das die Partitionstabelle auswertet
• Da auf PCs durch die Firmware (=das BIOS beim PC) keine Unterstützung für Partitionstabellen besteht, ist das Master Boot Code auch wirklich der wesentliche Bestandteil, weil das Programm zur Auswertung von Partitionstabellen auf dem PC.
• Der Master Boot Code ist also ein wesentlicher Bestandteil des Partitionierungskonzepts MBR.
• Auf anderen Partitionstabellen, beispielsweise GPT und APM, ist kein wie auch immer gearteter Code, an welcher Stelle auch immer, ein wesentlicher Teil der Partitionstabelle, weil sich die Firmware (UEFI bei GPT, oder Open Firmware bei APM) darum kümmert.

Ich sollte den Satz wohl etwas einfacher formulieren. Oh, das hast du ja schon gemacht:

Auf IBM-PC-kompatiblen Computern wird die Partitionstabelle grundsätzlich vom MBR-Bootcode ausgewertet.

Danke!

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

? - Alles erledigt hier?

DU hast, im Gegenteil zu deinem letzten Aufzählpunkt, geschrieben bei der GPT wäre Bootcode im MBR und ich habs entfernt, weil nicht zutreffend. -- itu (Disk) 20:15, 10. Jun. 2015 (CEST)

Sag einmal, willst du mich nicht verstehen oder was? Siehe Diskussion:Master_Boot_Record#Vorhandensein_von_Master_Boot_Code_.231.2C_.232 Nachtrag mit Quelle.

Du siehst nicht das wesentliche: BIOS+MBR: Master Boot Code wird ausgeführt. UEFI+GPT:: kein Bootsektor nötig. GPT auf einem BIOS-PC führt aber immer auch den Master Boot Code im Schutz-MBR des GPT aus! Wenn du so willst, ist eine der Ausstattungsmerkmale des GPT, dass ein MBR enthalten ist. Das nennt man Kompatibilität.

Du kannst nicht hergehen, und dann behaupten, dass der Master Boot Code bei GPT ja nicht ausgeführt wird, also ist es bewiesen, dass es nicht immer notwendig ist. NEIN. Denn bei GPT+BIOS ist das notwendig, weil eben dann ein MBR genutzt wird.

Das ist nicht erledigt. Berichtige das. Sonst mach ich es.

‣Andreas•⚖ 21:51, 10. Jun. 2015 (CEST)

Pfft. Kapierst du eigentlich dass der Masterbootcode immer nur bei einem Bootvorgang gestartet wird? Wenn man einen USB-stick an einen Computer hängt wird natürlich kein Bootcode gesucht, auch wenn er überflüsigerweise vorhanden ist. Was würde das für einen Sinn machen? -- itu (Disk) 22:18, 10. Jun. 2015 (CEST)

auf neueren Systemen und Geräten

Auf neueren Computern und Geräten wird jedoch der MBR nicht zum Starten eines Betriebssystems benötigt, beispielsweise wenn auf einem Autoradio Musik von einem USB-Stick wiedergegeben werden soll. In diesem Fall wird nur die Partitionstabelle des MBR verwendet – das Startprogramm wird nicht genutzt, da es nur auf Computern mit x86-Prozessor und BIOS lauffähig ist.

• Auf neueren Systemen wird UEFI verwendet. UEFI nutzt GPT als Partitionstabelle. Der MBR-Bootcode (Master Boot Code) wird nicht mehr zum Starten eine Betriebssystems verwendet.
• Auf Geräten (Beispiel: Autoradio) wird niemals der Master Boot Code zum Starten verwendet.

Deine Änderung:

Auf Datenträgern ohne Bootfunktion wird nur die Partitionstabelle des MBR verwendet – eventuell vorhandener Bootcode wird nicht genutzt.

Dein Kommentar: auch komplett falsch , eine zweite festplatte gabs schon immer, die hatte auch immer schon einen MBR bzw. eine PT

1. ist das nicht komplett falsch sondern richtig, aber unglücklich formuliert. 2. kann man eine zweite Festplatte als Bootmedium festlegen, indem man die erste kurzerhand absteckt…

Mit den Datenträgern ohne Bootfunktion kann ich leben.

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

? - Erledigt?. -- itu (Disk) 20:21, 10. Jun. 2015 (CEST)

Vorhandensein von Master Boot Code #1, #2

Dein Kommentar: es scheinen zwar die meisten USB-Stick tatsächlich mit Bootcode ausgeliefert zu werden, aber der ist offensichtlich von vorneherein überflüssig

Nun, der Master Boot Code ist immer überflüssig, wenn man ein Medium nicht als Startmedium einsetzt. Das heißt aber nicht, dass er nicht vorhanden ist. Was soll das?

Partitionierungsprogramme schreiben jedoch weiterhin immer beide Teile in den MBR: das Startprogramm (Bootloader) einerseits und die Partitionstabelle andererseits.

Das stimmt im allgemeinen auch. Wenn dein HP-Stream keinen Master Boot Code enthält, dann gibt es offenbar Ausnahmen zur Regel. Welches Programm wurde denn zur Partitionierung verwendet?

‣Andreas•⚖ 18:52, 9. Jun. 2015 (CEST)

„Nun, der...“ - warum schreibst du diese 2 Sätze so als ob hier jemand das Gegenteil behauptet hätte? - Ja, was soll das?

„Partitionierungsprogramme schreiben jedoch weiterhin immer beide Teile in den MBR“ - Nein das ist eben offenbar nicht richtig, probier doch einfach mal, so wie ich, (GNU-) fdisk aus auf einem genullten MBR. Den Bootcode schreibt hier offenbar immer erst der Bootloader (GRUB, etc).

Hast du einen Beleg dafür dass mein HP-Stream mit fabrikmässig genulltem Bootcodebereich eine Ausnahme ist? -- itu (Disk) 20:33, 10. Jun. 2015 (CEST)

Nachtrag: laut Starman's Realm – Protective MBR (englisch) ist der Master Boot Code bei GPT derselbe wie bei MBR alleine. Der Schutz-MBR einer GPT weist nur die Besonderheit der Schutz-Partition darin auf, die unter anderem auch auf „nicht bootfähig“ gesetzt ist. Wenn man ein Medium mit GPT zum Starten in einen BIOS-Computer steckt, so lädt der MBR ganz normal den Master Boot Code. Dieser findet allerdings keine startfähige Partition und gibt anschließend eine Fehlermeldung aus.

Zitat: When a disk is initialized as GPT by Windows 7 (or Windows 8), the first sector (Absolute Sector 0) still contains the same boot code as a Windows 7 MBR initialized disk drive…

Es ist also der Normalfall, dass ein MBR beide Teile, bestehend aus Master Boot Code und Partitionstabelle, besteht. Und zwar auch dann, wenn er als Protective MBR eigentlich Teil von GPT ist.

‣Andreas•⚖ 23:30, 9. Jun. 2015 (CEST)

Tsja, möglicherweise verallgemeinert diese Quelle ohne genug GPTs angeschaut zu haben oder dort ist gemeint dass vorher ein Partitionsprogramm benutzt wurde. Wie gesagt habe ich hier einen GPT-MBR der ausser diskidentifier (=vorhanden im Gegensatz zur Quelle) und dem Schutzpartitionseintrag und MBRsignatur 55aa komplett aus 00 besteht. -- itu (Disk) 22:08, 10. Jun. 2015 (CEST)

Master Boot Record vs. Master Boot Code oder Initial Program Lader oder Bootloader vs. Partitionstabelle

Erstmal: du hast Recht.

Du hast Recht, dass fdisk unter Linux keinen Bootcode schreibt. Das heißt, dass nur Windows-basierte Partitionierungsprogramme auch immer einen Bootcode schreiben. Wie es unter Mac OS X, unter OS/2 und unter Haiku etc. aussieht, das wissen wir nicht.

Linux richtet für ein zum Starten gedachtes Speichermedium, das mit MBR partitionieriert ist, einen Bootloader im MBR ein. Sonst geht nämlich nix. Das ist z.B. LILO oder GRUB oder... sonst was … Jedoch macht das nicht fdisk.

TestDisk schreibt seit 2005 den MBR i386, der unter GPL steht. Davor hat Testdisk den MBR von Microsoft/IBM verwendet.

Die Frage, die sich mir stellt, ist jetzt diese:

Was ist der Master Boot Record?

• Der erste Sektor eines mit MBR partitionierten Speichermediums? Dann gehört der Bootcode, so vorhanden, dazu.
• Nur die Partitionstabelle? Dann gehört der Bootcode nicht dazu, aber das ergibt eigentlich keinen Sinn.
• Nur der Bootcode? Ergibt noch weniger Sinn, dann dann heißt dieser Startsektor nicht mehr MBR.

Es war mir wirklich neu, dass ein MBR ohne Bootcode geschrieben würde. Unter Linux kann ich mir das schon ganz gut vorstellen, aber auch das war mir neu.

Meiner Meinung nach müssen also beide Teilaspekte in den Artikel. Und, wir müssen auch schreiben, dass der Bootcode optional ist, aber doch bei Microsoft immer noch dabei ist, bei Linux durch einen Bootloader nach Wahl geschrieben oder ersetzt wird, und bei OS/2, Mac, … muss noch geklärt werden.

Passt das soweit? Ich habe das nach bestem Wissen und Gewissen nun so in den Artikel geschrieben (Änderungen). Du kommst ja sicher wieder mit Feedback und Änderungen. Alles in Allem ist der Artikel dadurch jedoch mEn besser geworden. ‣Andreas•⚖ 17:45, 11. Jun. 2015 (CEST)

Ich kann deine Änderungen nicht ganz überblicken weil du einiges durcheinandergewürfelt hast und fürs komplette Neu-Durchgehen habe ich nur begrenzte Lust. -- itu (Disk) 21:46, 11. Jun. 2015 (CEST)

Kein Problem. Ich bin sehr froh, dass wir uns die Arbeit teilen (bzw. erstreiten). Ich bin der tiefen Überzeugung, dass nur so ein Artikel besser werden kann.

‣Andreas•⚖ 23:17, 11. Jun. 2015 (CEST)

4.3.1. Partitionstabelle

Ich bin auf einen angeblichen Fehler in der Tabelle hingeweisen worden, den ein Berufsschullehrer in FFM als schlechtes WP-Beispiel nutzen soll - warum auch immer der #§$%?! das dann nicht korrigiert. Eventuell ist der zwischenzeitlich korrigiert worden (in der Historie nicht ersichtlich)
In der Tat erschienen auch mir die Einträge der Länge bzw. Startsektoren der Partitionen 2-4 zunächst fehlerhaft. Milchmädchenrechnung: P1: 3f000000+41295402=80295402
P2: 80295402+fae71d00=17B107102
P3: 7a117202+fae71d00=174F88F02
P4: 74f98f02+0c836c04=817CFB06
Tatsächlich sind die Wert in Little Endian-Darstellung, die 4-Byte-Werte sind in umgekehrter Folge zu lesen und die Rechnung lautet daher:
P1: 0000003f+02542941=02542980
P2: 02542980+001de7fa=0272117a
P3: 0272117a+001de7fa=028ff974
P4: 028ff974+046c830c=06FC7C80
Bitte nicht archivieren, sonst fragt wieder mal jemand. Unter 4.3.2 könnte man mal die Liste der Partitionstypen aktualisieren.--Mideal (Diskussion) 17:35, 21. Okt. 2015 (CEST)

Lesen sollte man schon können, auch als Berufsschullehrer ;-) der Hinweis auf LittleEndian steht unmittelbar dahinter --Nobby1805 (Diskussion) 18:25, 21. Okt. 2015 (CEST)

Du hast natürlich recht, das nützt aber nichts, wenn man nicht weiß, was das bedeutet (und dann da auch nicht weiterliest).--Mideal (Diskussion) 11:16, 2. Nov. 2015 (CET)

hexadezimaldarstellung der Partitionstabelle

Diese zwei Edits, Geht nicht und man kann nicht von einem erweiterten laufwerk booten, haben es insich. Da wird die beispielhafte Partitionstabelle zerlegt und die Begründungen sind "geht nicht" und "kann man nicht booten".

Zu zweitem: Man kann sehrwohl von einer erweiterten Partition booten, es muss sich nur im Bootsektor/Startsektor der erweiterten Partition auch ein Bootloader finden, den ebenso das Starten aus einer erweiterten Partition unterstützt. Ich weiß, DOS tat das nie, aber OS/2 beispielsweise kann von einer erweiterten Partition aus gestartet werden. Ob der Bootcode allerdings in der erweiterten Partition steht oder gleich im MBR, ist mir nicht bekannt. Dennoch, möglich wäre es, von daher ist die Aussage so pauschal falsch.

(Umgekehrt: wenn keine einzige Partition als "startfähig" markiert ist, im MBR aber entsprechender Bootcode liegt, der dennoch von einer der Partitionen startet, dann geht es auch. Unter Linux mit GRUB z.B. ist das so, da ist die Partitionsmarkierung völlig egal.)

Ich habe die Hex-Werte mit einem Hex-Editor (unter KDE z.B. Okteta) aus der Wikipedia in eine Datei mbr.bin übertragen. Die Erstellung der Datei unterhalb von /tmp (bei mir ein tmpfs, also im RAM, siehe RAM-Disk):

$ dd if=/dev/zero of=/tmp/mbr.bin bs=512 count=1

Die Ausgabe der Version vor dem Edit ist dann unter Linux mit fdisk wie folgt:

$ fdisk -l /tmp/mbr.bin 
Lesen der erweiterten Partitionstabelle ist fehlgeschlagen (Position=42989940): Erfolg 
Festplatte /tmp/mbr.bin: 512 B, 512 Bytes, 1 Sektoren 
Einheiten: Sektoren von 1 * 512 = 512 Bytes 
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes 
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes 
Festplattenbezeichnungstyp: dos 
Festplattenbezeichner: 0x12345678 
 
Gerät         Boot   Anfang      Ende Sektoren Größe Kn Typ 
/tmp/mbr.bin1            63  39070079 39070017 18,6G 83 Linux 
/tmp/mbr.bin2      39070080  41030009  1959930  957M 82 Linux Swap / Solaris 
/tmp/mbr.bin3      41030010  42989939  1959930  957M 83 Linux 
/tmp/mbr.bin4 *    42989940 117210239 74220300 35,4G  5 Erweiterte

Damit weiß man auch gleich die Größe, und kann nun eine Sparse-Datei mit dd daraus machen (der letzte Sektor ist mindestens 117210239):

$ dd if=/dev/zero of=/tmp/mbr.bin bs=512 count=0 seek=117210239

Nun funktioniert fdisk fehlerfrei (weil ja vermeintlich der ganze Speicher da ist, siehe Sparse-Datei):

$ cd /tmp
$ fdisk -l mbr.bin 
Festplatte mbr.bin: 55,89 GiB, 60011642368 Bytes, 117210239 Sektoren 
Einheiten: Sektoren von 1 * 512 = 512 Bytes 
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes 
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes 
Festplattenbezeichnungstyp: dos 
Festplattenbezeichner: 0x12345678 
 
Gerät      Boot   Anfang      Ende Sektoren Größe Kn Typ 
mbr.bin1              63  39070079 39070017 18,6G 83 Linux 
mbr.bin2        39070080  41030009  1959930  957M 82 Linux Swap / Solaris 
mbr.bin3        41030010  42989939  1959930  957M 83 Linux 
mbr.bin4   *    42989940 117210239 74220300 35,4G  5 Erweiterte

Das scheint zu stimmen...

So, und nun nach der Änderung:

$ fdisk -l mbr.bin 
Festplatte mbr.bin: 55,89 GiB, 60011642368 Bytes, 117210239 Sektoren 
Einheiten: Sektoren von 1 * 512 = 512 Bytes 
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes 
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes 
Festplattenbezeichnungstyp: dos 
Festplattenbezeichner: 0x12345678 

Gerät      Boot   Anfang      Ende Sektoren Größe Kn Typ 
mbr.bin1              63  39070079 39070017 18,6G 83 Linux 
mbr.bin2        39070080  41030009  1959930  957M 82 Linux Swap / Solaris 
mbr.bin3        41030010  42989939  1959930  957M 83 Linux 
mbr.bin4        42989940 117210239 74220300 35,4G  0 Leer

Die 4. Partition ist nun leer. Das ist sinnfrei. Ich werde es daher revertieren.

‣Andreas•⚖ 13:20, 7. Nov. 2023 (CET)

Ich habe nun ein neues Beispiel auf Basis des bestehenden erstellt. Als MBR-Code habe ich TestDisk verwendet, um den unter freier Lizenz stehenden Code von mbr-install, entwickelt von Neil Turton^ref, zu verwenden.

Die Alternative wäre der Standard-MBR von MS-DOS 2.00, weil MS-DOS 2.00 von Microsoft zu Ausbildungszwecken veröffentlicht wurde. Allerdings weiß ich nicht genau, wo der Standard-MBR-Bootcode dort zu finden ist, denn gerade FDISK fehlt dort. Weitere Informationen zu diesem "Standard-MBR": The Starman's Realm (dort steht auch, dass der MBR-Code von FDISK in den ersten Sektor geschrieben wurde)...

Und das ist das Ergebnis:

$ od -A x -t x1z -v mbr_testdisk.bin  
000000 fc 31 c0 8e d0 31 e4 8e d8 8e c0 be 00 7c bf 00  >.1...1.......|..< 
000010 06 b9 00 01 f3 a5 be ee 07 b0 08 ea 20 06 00 00  >............ ...< 
000020 80 3e b3 07 ff 75 04 88 16 b3 07 80 3c 00 74 04  >.>...u......<.t.< 
000030 08 06 af 07 83 ee 10 d0 e8 73 f0 90 90 90 90 90  >.........s......< 
000040 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  >................< 
000050 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  >................< 
000060 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90  >................< 
000070 90 90 90 90 90 90 90 90 90 90 90 90 90 90 be be  >................< 
000080 07 b0 00 b9 04 00 80 3c 00 75 6e fe c0 83 c6 10  >.......<.un.....< 
000090 e2 f4 31 db b4 0e be 9d 07 8a 0e af 07 ac d0 e9  >..1.............< 
0000a0 73 02 cd 10 08 c9 75 f5 b0 3a cd 10 31 c0 cd 16  >s.....u..:..1...< 
0000b0 3c 00 74 f8 be 8b 07 b9 02 00 e8 ba 00 3c 0d 74  ><.t..........<.t< 
0000c0 b4 3c 61 72 06 3c 7a 77 02 2c 20 88 c3 be 9d 07  >.<ar.<zw., .....< 
0000d0 8a 0e af 07 ac d0 e9 73 04 38 c3 74 06 08 c9 75  >.......s.8.t...u< 
0000e0 f3 eb af b8 0d 0e 31 db cd 10 8d 84 62 00 3c 07  >......1.....b.<.< 
0000f0 75 07 b0 1f a2 af 07 eb 99 31 d2 b9 01 00 3c 04  >u........1....<.< 
000100 74 11 73 f3 30 e4 b1 04 d2 e0 be be 07 01 c6 8a  >t.s.0...........< 
000110 16 b3 07 bf 05 00 56 f6 c2 80 74 31 b4 41 bb aa  >......V...t1.A..< 
000120 55 52 cd 13 5a 5e 56 72 1e 81 fb 55 aa 75 18 f6  >UR..Z^Vr...U.u..< 
000130 c1 01 74 13 8b 44 08 8b 5c 0a be 8d 07 89 44 08  >..t..D..\.....D.< 
000140 89 5c 0a b4 42 eb 0c 8a 74 01 8b 4c 02 b8 01 02  >.\..B...t..L....< 
000150 bb 00 7c 50 c6 06 8f 07 01 cd 13 58 5e 73 05 4f  >..|P.......X^s.O< 
000160 75 b4 eb 93 81 3e fe 7d 55 aa 75 f6 ea 00 7c 00  >u....>.}U.u...|.< 
000170 00 be 83 07 b9 0a 00 50 b4 0e 31 db ac cd 10 e2  >.......P..1.....< 
000180 fb 58 c3 54 65 73 74 44 69 73 6b 0d 0a 10 00 01  >.X.TestDisk.....< 
000190 00 00 7c 00 00 00 00 00 00 00 00 00 00 31 32 33  >..|..........123< 
0001a0 34 46 00 00 41 4e 44 54 6d 62 72 00 02 02 02 1f  >4F..ANDTmbr.....< 
0001b0 c7 00 00 80 00 00 00 00 78 56 34 12 00 00 00 01  >........xV4.....< 
0001c0 01 00 83 fe ff ff 3f 00 00 00 41 29 54 02 00 fe  >......?...A)T...< 
0001d0 ff ff 82 fe ff ff 80 29 54 02 fa e7 1d 00 80 fe  >.......)T.......< 
0001e0 ff ff 83 fe ff ff 7a 11 72 02 fa e7 1d 00 00 fe  >......z.r.......< 
0001f0 ff ff 05 fe ff ff 74 f9 8f 02 0c 83 6c 04 55 aa  >......t.....l.U.< 
000200

$ fdisk -l mbr_testdisk.bin 
Lesen der erweiterten Partitionstabelle ist fehlgeschlagen (Position=42989940): Erfolg 
Festplatte mbr_testdisk.bin: 512 B, 512 Bytes, 1 Sektoren 
Einheiten: Sektoren von 1 * 512 = 512 Bytes 
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes 
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes 
Festplattenbezeichnungstyp: dos 
Festplattenbezeichner: 0x12345678 
 
Gerät             Boot   Anfang      Ende Sektoren Größe Kn Typ 
mbr_testdisk.bin1            63  39070079 39070017 18,6G 83 Linux 
mbr_testdisk.bin2      39070080  41030009  1959930  957M 82 Linux Swap / Solaris 
mbr_testdisk.bin3 *    41030010  42989939  1959930  957M 83 Linux 
mbr_testdisk.bin4      42989940 117210239 74220300 35,4G  5 Erweiterte

Zu den Änderungen:

1. Die aktive Partition ("Bootpartition") ist nun Partition 3 (ich gehe davon aus, dass diese Linux-Partition eventuell /boot beherbergt)
   • Partition 1 wäre dann das root-Dateisystem /, und
   • Partition 2 der swap.
2. Partition 4 ist wieder eine "Erweiterte Partition", wobei die darin enthaltenen Partitionen für den Zweck dieser Darstellung belanglos sind. Darum enthält sie auch keine weiteren Partitionen.

Das baue ich nun ein, und ich hoffe, dass das so passt.

‣Andreas•⚖ 14:09, 7. Nov. 2023 (CET)