RapaNui
(Themenstarter)
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Newubunti schrieb: RapaNui schrieb:
Nein, da wurde die Zusammenarbeit nur zäh, weil wir nicht gleich einer Meinung waren und es teilweise auch nach wie vor nicht sind. Das hilft aber für das vorliegende Problem überhaupt nicht weiter.
Das nennt sich Diskussion, mit Argumenten und Gegenagumenten arbeiten. So, ich hab die paar Wortfetzen noch entnommen und damit ist der Artikel für mich endgültig fertig. Saludos de Chile RapaNui
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
RapaNui schrieb: Newubunti schrieb: RapaNui schrieb:
Nein, da wurde die Zusammenarbeit nur zäh, weil wir nicht gleich einer Meinung waren und es teilweise auch nach wie vor nicht sind. Das hilft aber für das vorliegende Problem überhaupt nicht weiter.
Das nennt sich Diskussion, mit Argumenten und Gegenagumenten arbeiten.
Das sehe ich genauso! So, ich hab die paar Wortfetzen noch entnommen und damit ist der Artikel für mich endgültig fertig.
Dann ist für mich nun der Augenblick gekommen, Dir für den Artikel sowie die konstruktive Zusammenarbeit daran zu danken! Gruß,
Martin
|
Lasall
Ehemalige
Anmeldungsdatum: 30. März 2010
Beiträge: 7723
|
Hi RapaNui, von mir auch grünes Licht für den Artikel (syntaxmäßig). Super Arbeit, danke 👍 ! @Newubunti: Vielen Dank für deine inhaltliche Kritik und Analyse beider Artikel ☺ ! @noisefloor: Ich überlasse dir mal die Ehre 😉 . Gruss
Lasall
|
frustschieber
Ehemalige
Anmeldungsdatum: 4. Januar 2007
Beiträge: 4259
|
Verschoben mit Dank an den Autor RapaNui für die intensive Arbeit und nach Partitionierung (Abschnitt „Kommandozeilen-Programme“) verknüpft!
|
luwex
Anmeldungsdatum: 13. Juli 2005
Beiträge: 53
|
Hallo Für mich war der Artikel interessant, da endlich mal eine Möglichkeit für die Erstellung einer Bootpartition mit GPT. Habe wie unter "sgdisk" > "Anlegen einer Partition" den Befehl eingegeben.
Nun kam aber nicht das wie unter "sgdisk" > "Partitions-Information (detailliert)" angegeben heraus. Sondern: First sector: 1024 (at 512.0 KiB)
Last sector: 2047 (at 1023.5 KiB)
Partition size: 1024 sectors (512.0 KiB) Kann ja auch nicht wenn 1024 als start angegeben.
Wenn ich 34 statt 1024 verwende kommt das Ergebnis heraus. Nur das von allen möglichen Live-CD die Platte mit Fehler: "dev/sdg:unrecognised disk label" erkannt wird.
Und dann auch unbenutzbar ist.
Komisch ist, dass mein normales System mit allen möglichen Partitionierungswerkzeugen richtig erkannt wird. Nach dem löschen der 1. Partition ist es wieder möglichen mit Live-CD die Platte zu gebrauchen. Was ist nun richtig, reicht es so wie im Befehl angegeben. Wenn ja wäre es gut unter "sgdisk" > "Partitions-Information (detailliert)" die Ausgabe auch dementsprechend anzpassen. Dann kann es nicht, wie bei mir, zu Verwirrung kommen. Gruß Uwe
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo, kann es sein, dass da Mist steht? : Anlegen einer Partition
Im folgenden Beispiel wird eine neue Partition mit der Nummer 1 angelegt:
Das Alignment wird auf 1024 Bytes eingestellt (-a 1024 ) Die neue Partition erhält die Nummer 1 , wird 1024 Bytes groß und vor die anderen Partitionen in den Bereich von 1024-2048 Bytes gelegt (-n 1:1024:2048 ) Der interne Name der 1.Partition wird geändert (-c 1:"BIOS Boot Partition" ) Der GPT-Partitionstyp wird auf ef02 eingestellt und bekommt dadurch die GUID 21686148-6449-6E6F-744E-656564454649 zugeteilt (Die GUID erzeugt im lesbaren Format, z.B. mit hexdump -C , den Text Hah!IdontNeedEFI ).
Seit wann werden denn Partitionen an Bytes ausgerichtet? Ich denk, da müsste Sektoren stehen. Außerdem: Die angegebene GUID in Textform ergibt: !haHdInotNeedEFI Also entweder stimmt die GUID oder der Text nicht.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
Artikel als fehlerhaft gekennzeichnet.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
UlfZibis schrieb: Ich denk, da müsste Sektoren stehen.
Jedenfalls ist es so, dass wenn man das Kommando wie angegeben ausführt, es auf Sektoren und nicht auf Bytes wirkt: sudo gdisk -l /dev/sdX
GPT fdisk (gdisk) version 1.0.8
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 2097152 sectors, 1024.0 MiB
Model: QEMU HARDDISK
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 7F78C8EE-ED27-4CF4-85E0-21DB09658370
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 2097118
Partitions will be aligned on 1024-sector boundaries
Total free space is 2096061 sectors (1023.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 1024 2047 512.0 KiB EF02 BIOS Boot Partition
Außerdem: Die angegebene GUID in Textform ergibt: !haHdInotNeedEFI
Wie hast Du das überprüft? Wenn ich das Kommando wie im Beispiel ausführe, also diese hier, sudo sgdisk -a 1024 -n 1:1024:2047 -c 1:"BIOS Boot Partition" -t 1:ef02 /dev/sdX dann ergibt bei mir ein anschließendes, sudo dd if=/dev/sdX bs=512 skip=1 count=33 | hexdump -C folgende Ausgabe: 00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...|
00000010 b6 bd 61 db 00 00 00 00 01 00 00 00 00 00 00 00 |..a.............|
00000020 ff ff 1f 00 00 00 00 00 22 00 00 00 00 00 00 00 |........".......|
00000030 de ff 1f 00 00 00 00 00 ee c8 78 7f 27 ed f4 4c |..........x.'..L|
00000040 85 e0 21 db 09 65 83 70 02 00 00 00 00 00 00 00 |..!..e.p........|
00000050 80 00 00 00 80 00 00 00 ba 1e ef fb 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
00000210 c3 69 ea bf 1a a0 0a 49 9f 46 ca 81 91 1a 35 91 |.i.....I.F....5.|
00000220 00 04 00 00 00 00 00 00 ff 07 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 42 00 49 00 4f 00 53 00 |........B.I.O.S.|
00000240 20 00 42 00 6f 00 6f 00 74 00 20 00 50 00 61 00 | .B.o.o.t. .P.a.|
00000250 72 00 74 00 69 00 74 00 69 00 6f 00 6e 00 00 00 |r.t.i.t.i.o.n...|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
33+0 Datensätze ein
33+0 Datensätze aus
16896 Bytes (17 kB, 16 KiB) kopiert, 0,00110519 s, 15,3 MB/s
00004200
Deine Ausgabe erinnert mich an ein Little/Big-Endian-"Problem" bzw. Phänomen. LG,
Newubunti
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Newubunti schrieb: UlfZibis schrieb: Außerdem: Die angegebene GUID in Textform ergibt: !haHdInotNeedEFI
Wie hast Du das überprüft?
Mit einem Hexdump von 21686148-6449-6E6F -744E-656564454649 folgende Ausgabe:
00000200 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
Das ist ja auch nicht dieselbe GUID ist, die im Artikel angegeben ist.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
UlfZibis schrieb: 00000200 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
Das ist ja auch nicht dieselbe GUID ist, die im Artikel angegeben ist.
Doch schon, wenn Du die Bytereihenfolge beim Lesen beachtest, siehe:
Byte-Reihenfolge insbesondere auch Little-Endian-Format Und im Prinzip ist es auch genauso in GUID_Partition_Table beschrieben. Bei hexdump kommt es dann auch immer noch auf die Formatierung an. Z.B. kannst Du auch so ausgeben:
sudo dd if=/dev/sdX bs=512 skip=1 count=33 | hexdump -xC
0000000 4645 2049 4150 5452 0000 0001 005c 0000
00000000 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...|
0000010 bdb6 db61 0000 0000 0001 0000 0000 0000
00000010 b6 bd 61 db 00 00 00 00 01 00 00 00 00 00 00 00 |..a.............|
0000020 ffff 001f 0000 0000 0022 0000 0000 0000
00000020 ff ff 1f 00 00 00 00 00 22 00 00 00 00 00 00 00 |........".......|
0000030 ffde 001f 0000 0000 c8ee 7f78 ed27 4cf4
00000030 de ff 1f 00 00 00 00 00 ee c8 78 7f 27 ed f4 4c |..........x.'..L|
0000040 e085 db21 6509 7083 0002 0000 0000 0000
00000040 85 e0 21 db 09 65 83 70 02 00 00 00 00 00 00 00 |..!..e.p........|
0000050 0080 0000 0080 0000 1eba fbef 0000 0000
00000050 80 00 00 00 80 00 00 00 ba 1e ef fb 00 00 00 00 |................|
0000060 0000 0000 0000 0000 0000 0000 0000 0000
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000200 6148 2168 6449 6e6f 4e74 6565 4564 4946
00000200 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
0000210 69c3 bfea a01a 490a 469f 81ca 1a91 9135
00000210 c3 69 ea bf 1a a0 0a 49 9f 46 ca 81 91 1a 35 91 |.i.....I.F....5.|
0000220 0400 0000 0000 0000 07ff 0000 0000 0000
00000220 00 04 00 00 00 00 00 00 ff 07 00 00 00 00 00 00 |................|
0000230 0000 0000 0000 0000 0042 0049 004f 0053
00000230 00 00 00 00 00 00 00 00 42 00 49 00 4f 00 53 00 |........B.I.O.S.|
0000240 0020 0042 006f 006f 0074 0020 0050 0061
00000240 20 00 42 00 6f 00 6f 00 74 00 20 00 50 00 61 00 | .B.o.o.t. .P.a.|
0000250 0072 0074 0069 0074 0069 006f 006e 0000
00000250 72 00 74 00 69 00 74 00 69 00 6f 00 6e 00 00 00 |r.t.i.t.i.o.n...|
0000260 0000 0000 0000 0000 0000 0000 0000 0000
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
33+0 Datensätze ein
33+0 Datensätze aus
16896 Bytes (17 kB, 16 KiB) kopiert, 0,00285475 s, 5,9 MB/s
00004200
Außerdem noch die Ausgabe von,
sudo sgdisk -i 1 /dev/sdX
Partition GUID code: 21686148-6449-6E6F-744E-656564454649 (BIOS boot partition)
Partition unique GUID: BFEA69C3-A01A-490A-9F46-CA81911A3591
First sector: 1024 (at 512.0 KiB)
Last sector: 2047 (at 1023.5 KiB)
Partition size: 1024 sectors (512.0 KiB)
Attribute flags: 0000000000000000
Partition name: 'BIOS Boot Partition'
von der nach dem Artikel-Beispiel angelegten Partition. Also das stimmt schon so. LG,
Newubunti
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Newubunti schrieb: Doch schon, wenn Du die Bytereihenfolge beim Lesen beachtest, siehe:
Byte-Reihenfolge insbesondere auch Little-Endian-Format
Du meinst, dass die ersten 8 Byte in der GUID-Schreibweise gruppenweise (2- und 4-Bayte-Gruppen) in little-endian und die letzten 8 Byte in big-endian notiert werden? Wer hat denn sowas schräges erfunden?
sudo dd if=/dev/sdX bs=512 skip=1 count=33 | hexdump -xC
*
0000200 6148 2168 6449 6e6f 4e74 6565 4564 4946
00000200 48 61 68 21 49 64 6f 6e 74 4e 65 65 64 45 46 49 |Hah!IdontNeedEFI|
*
Der markierte ganz in middle-endian (wortweises little-endian) ausgegebene Wert entspricht jedenfalls nicht der genannten GUID 21686148-6449-6E6F-744E-656564454649
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
UlfZibis schrieb: Newubunti schrieb: Doch schon, wenn Du die Bytereihenfolge beim Lesen beachtest, siehe:
Byte-Reihenfolge insbesondere auch Little-Endian-Format
Du meinst, dass die ersten 8 Byte in der GUID-Schreibweise gruppenweise (2- und 4-Bayte-Gruppen) in little-endian und die letzten 8 Byte in big-endian notiert werden?
Naja, ganz offensichtlich ist es so und in 🇬🇧 https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries_(LBA_2%E2%80%9333) wird das als "mixed endian" benannt. LG,
Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
UlfZibis schrieb: […]
Wer hat denn sowas schräges erfunden?
Das Format ist definiert in RFC4122. Dort steht auch, dass die ersten drei Felder als Ganzzahl konzipiert sind (und damit der little/big-endian-Problematik unterliegen) und die restlichen Felder als Bytefolge. Es ist bekannt, dass es bei der Bytefolge Hah!IdontNeedEFI zu Darstellungsproblemen kommt, wenn man diese als UUID interpretieren soll.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
kB schrieb: Das Format ist definiert in RFC4122. Dort steht auch, dass die ersten drei Felder als Ganzzahl konzipiert sind (und damit der little/big-endian-Problematik unterliegen) und die restlichen Felder als Bytefolge. Es ist bekannt, dass es bei der Bytefolge Hah!IdontNeedEFI zu Darstellungsproblemen kommt, wenn man diese als UUID interpretieren soll.
Vielleicht könnte man das in dem Artikel kurz erklären, um zukünftigen Verwirrungen vorzubeugen, und das ist ja auch allgemein eine interessante Info zum Thema GUID.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
UlfZibis schrieb: Vielleicht könnte man das in dem Artikel kurz erklären, um zukünftigen Verwirrungen vorzubeugen
Das gehört nicht in diesen Artikel, dessen Thema "gdisk" lautet. Ich habe aber im Artikel UUID einen entsprechenden Experten.Hinweis hinterlegt und der Artikel UUID wird noch von hier verknüpft werden.
|