Hi Miroslav,



good catch. It looks like GPT uses a weird Microsoft-specific encoding of 
GUID/UUID, whereas we use the encoding per RFC 4122. The other case where we
call uuid_encode() is in ext4 superblock, where it is appropriate since ext4
encodes UUIDs according to RFC 4122 (in network byte order).





I never thought alternate encodings would exist. In light of this, it might
make more sense for the internal representation to be actually structured,
at least for the first three dash-delimited fields (and maybe for all of 
them).


Your changes look mostly OK, although I am not a big fan of the helper
function (which couldn't exist anyway if we changed the internal
representation to structured).  Some of the inline comments incorrectly
start with a double asterisk, e.g. /** time_low */ even though they are not
documentation comments.




Cheers,

Jiri




---------- Původní e-mail ----------
Od: Miroslav Cimerman <m...@doas.su>
Komu: helenos-devel@lists.modry.cz
Datum: 10. 6. 2024 18:25:01
Předmět: [HelenOS-devel] GPT partition type UUID
"Hi,
 
""I found that when creating GPT partitions, the partition
type UUID is encoded so that it is not possible to know
the partition type when looking at it outside of HelenOS.

I opened a PR on Github that fixes this issue.

Example:

qemu-img create testdisk.img 100M

qemu-system-x86_64 -enable-kvm -boot d -cdrom image.iso \
-drive file=testdisk.img,format=raw,media=disk

# in this example inside HelenOS I created 3 partitions:
# ExFAT, Ext4, FAT

Before my PR (fdisk -l ./testdisk.img output):

Disk ./testdisk.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 80CAD31B-F30A-3449-8866-9656101F2153

Device Start End Sectors Size Type
./testdisk.img1 128 39295 39168 19.1M unknown
./testdisk.img2 39296 117503 78208 38.2M unknown
./testdisk.img3 117504 204671 87168 42.6M unknown


After my diff and the same process as above,
after deleting and creating testdisk.img again:

Disk ./testdisk.img: 100 MiB, 104857600 bytes, 204800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: EEEFD1FE-2CF9-8144-B431-C4A5549419B1

Device Start End Sectors Size Type
./testdisk.img1 128 39295 39168 19.1M Microsoft basic data
./testdisk.img2 39296 117503 78208 38.2M Linux filesystem
./testdisk.img3 117504 204671 87168 42.6M Microsoft basic data


I also attached some links and more information in the PR.
PR: https://github.com/HelenOS/helenos/pull/231


--
mc


_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
"
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to