staging.inyokaproject.org

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

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

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

Verschoben mit Dank an den Autor RapaNui für die intensive Arbeit und nach Partitionierung (Abschnitt „Kommandozeilen-Programme“) verknüpft!

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

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.

Artikel als fehlerhaft gekennzeichnet.

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

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.

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

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

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

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.

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.

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.