Alternativer Speicherort für die GPT-Partitionseintragstabelle

1134
Juan

Der GPT-Header (normalerweise in LBA 1) hat ein PartitionEntryLBAFeld (siehe 5.3.2 GPT-Header in der Spezifikation). In verschiedenen Referenzen (z. B. im Wikipedia-GPT-Eintrag) gibt es eine Sprache, die das Feld beschreibt, in dem es heißt, es sollte auf LBA 2 verweisen.

Die Spezifikation besagt "Das primäre GPT-Partitionseintragungs-Array muss sich nach dem primären GPT-Header befinden und vor der ersten verwendbaren LBA enden."

In diesem Zusammenhang scheint ein Wackelraum mit "nach" verbunden zu sein. Das bedeutet nicht notwendigerweise unmittelbar danach - der erste Partitionseintrag könnte eine Anzahl von LBAs nach dem Header sein und diese Vorgaben in der Spezifikation noch erfüllen.

Ich verwende einen eingebetteten Prozessor, der im zweiten Sektor einer Speicherkarte (z. B. SD) nach einer 4k-Vektortabelle sucht. Daher kann ich die GPT-Partitionseinträge nicht dort ablegen. Ich möchte also nach dieser Tabelle GPT-Partitionseinträge schreiben (5-KB-Offset unter Annahme von 512-Byte-Sektoren). Ich denke, das ist vernünftig, habe aber noch keine Standard-GPT-Partitionierungs-Tools (z. B. Partition für Linux) angeschaut, um zu sehen, ob / wie dies unterstützt wird. Auch nicht, ob Standard-Bootloader (z. B. u-boot) eine Partitionseintragstabelle an einem solchen Ort finden können.

Ich bin also an praktischen Erfahrungen mit atypischen GPT-Partitionseintragstabellen (dh nicht an LBA 2 für die primäre Kopie der Tabelle) mit verschiedenen Partitionierungswerkzeugen und Bootloadern interessiert. Bevorzugen Sie bsd / linux, aber ich bin auch an anderen Umgebungen interessiert (sogar Anekdoten über bestimmte kommerzielle Betriebssysteme).

Das ist ein bisschen eine offene Anfrage. Etwas genauer formuliert: Gibt es bekannte Fehlerfälle mit Tabellenpositionen für atypische GPT-Partitionseinträge und vorhandene Partitionierungswerkzeuge und / oder Bootloader?

Die UEFI-Spezifikationen finden Sie hier: http://www.uefi.org/specifications . Ich habe mir das zuletzt angesehen (Version 2.4, Errata C).

Ich habe noch keine Mitgliedschaft bei UEFI ( http://www.uefi.org/join ), daher habe ich keinen Zugang zum dortigen Forum ( http://www.uefi.org/FWOSForum ).

ps Es scheint eine noch stärkere Anforderung (?) zu bestehen, dass der primäre GPT-Header bei LBA 1 ist, obwohl es StartingLBAin der PMBR ein Feld gibt (bei LBA 0). Die Spezifikation schreibt ausdrücklich vor, dass das StartingLBAFeld dort LBA 1 sein sollte. Aber warum sollte es das Feld sein, wenn es bei LBA 1 sein muss? Warum lassen Sie den GPT-Header nicht bei LBA 10 sein, wenn eine Situation dies erfordert? Dies ist in meinem aktuellen Anwendungsfall nicht notwendig und die Fragen sind in diesem Forum etwas rhetorisch (wahrscheinlich besser in den offiziellen UEFI-Foren gestellt).

0
Ich denke, ich verwende möglicherweise einen ähnlichen Prozessor wie Sie. Ich konnte U-Boot so ändern, dass der Partitionseintragsversatz 'richtig' verwendet wird, um den erforderlichen Bereich unverändert zu lassen. Ich habe auch keine Tools gesehen, die dieses Feld standardmäßig verwenden. Dies ist zwar schmerzhaft, verhindert jedoch, dass Benutzer von anderen Tools gebissen werden, die es nicht unterstützen. oscode vor 7 Jahren 0

1 Antwort auf die Frage

0
Rod Smith

Ich hätte schwören können, ich hätte so etwas in einigen hybriden ISO-Images gesehen (die Sorte, die für Linux-Distributionen verwendet wird, sodass sie ohne Nachbearbeitung auf eine CD-R gebrannt oder auf ein USB-Flash-Laufwerk geschrieben werden können); Ich habe jedoch nur ein paar geprüft und sie scheinen das nicht zu tun. Vielleicht erinnere ich mich nicht richtig, oder vielleicht habe ich die richtigen nicht überprüft. Ich sehe darüber auch nichts auf der isohybridManpage - aber ich bin mir nicht sicher, ob dies zum Erstellen dieser Bilder am häufigsten verwendet wird. Vielleicht möchten Sie dieser Spur jedoch weiter folgen als ich ...

FWIW, ich bin der Autor von GPT fdisk. Es ist schon eine Weile her, seit ich den relevanten Code berühren musste, aber ein kurzer Überblick legt nahe, dass GPT fdisk dies tun sollteeine Platte lesen, bei der die primäre Partitionstabelle nicht bei LBA 2 beginnt; GPT fdisk unterstützt jedoch nicht das Ändern dieses Speicherorts. Ich kann nicht versprechen, dass die Tabelle wieder am ursprünglichen Speicherort gespeichert wird, selbst wenn eine solche Festplatte erfolgreich gelesen werden konnte. Möglicherweise können Sie sie hacken, um diese Tabelle zu Experimentierzwecken an anderer Stelle zu starten. In der Tat habe ich das nur versucht, aber es gibt eine Reihe von Stellen im Code, die hartcodierte Werte "1" oder "2" verwenden, um die LBA-Werte aufzufüllen, und ich habe sie nicht alle in meinem Anfang gefunden versuchen, also schrieb ich den Header in die Mitte der Partitionstabelle, was natürlich nicht schön war. Wenn Sie es versuchen wollen, schauen Sie sich die gpt.ccDatei an. Beginnen Sie mit der Suche nach dem Ort partitionEntriesLBAund der firstUsableLBAEinstellung, aber einige der relevanten Konstanten befinden sich auch in Funktionsaufrufen.

Ich bezweifle, dass Sie den Ort des primären GPT-Headers ändern können. Der schützende MBR ist an sich nicht wirklich Teil der GPT-Datenstrukturen. Ihr Zweck besteht darin, die Festplatte als GPT-Platte zu identifizieren und zu verhindern, dass GPT-unbewusste Tools sich mit der Festplatte verbinden, und nicht, wo GPT-Datenstrukturen beginnen. Das StartingLBAFeld dort ist vorhanden, weil es Teil der MBR-Datenstruktur ist, nicht weil GPT es für irgendetwas verwendet. Ich nehme an, es ist möglich, dass einige Tools den Startpunkt der MBR-Schutzpartition als Zeiger auf den primären Header verwenden, aber ich bezweifle, dass eine Mehrheit dies tun würde. Gewiss tut GPT fdisk nicht; es kodiert LBA 1 als Position des primären Headers.

Wenn Sie weitere Fragen dazu haben, möchten Sie vielleicht in der edk2-devel-Mailingliste posten. Es gibt viele EFI-Entwickler, und einige von ihnen kennen vielleicht Präzedenzfälle für das, was Sie versuchen, oder alternative Wege, um Ihr Ziel zu erreichen.