Re: [Gptfdisk-general] GPTPart::GetDescription broken in 1.0.7 on Big Endian systems
Brought to you by:
srs5694
Menu
▾
▴
Re: [Gptfdisk-general] GPTPart::GetDescription broken in 1.0.7 on Big Endian systems
|
From: Erik L. <cat...@gm...> - 2021-06-08 10:20:43
|
Hi Christian, On 8.6.2021 10.35, Christian Ehrhardt wrote: > On Tue, Jun 8, 2021 at 9:24 AM Erik Larsson <cat...@gm...> wrote: >> In general I prefer to keep data read from disk into memory in the >> on-disk endianness and transform endianess when retrieving it or setting it. >> gptfdisk does not do this but instead byteswaps the fields back and >> forth in the structures that were read from disk. This is error-prone >> and can lead to on-disk corruption when it's written back. This might be >> contributing to the problems. >> >> I'll check if I can reproduce with e.g. Debian sid ppc64 (big endian) > I was not seeing the very same on ppc64el which is the ppc64 > architecture of Debian/Ubutnu. > But then the "el" means little endian so that would make sense. Yes, that makes sense. No byteswapping needed there. > The https://wiki.debian.org/PPC64 for big endian exists but is > unofficial and thereby might have some issues. True, but I tested anyway in a chroot just to see if I got any different result but I did not. > I'd think the fastest way for you could be getting a free s390x VM to > work on via > https://developer.ibm.com/components/ibm-linuxone/gettingstarted/# Thanks for the pointer! That was very helpful, I was able to get an s390x VM up and running pretty quickly. Unfortunately they do not offer Ubuntu specifically but I fired up a RHEL8.3 VM to do the testing. >> and find out what's going on. I have no access to an s390x machine but >> maybe qemu can help with that... > It can, but you'd want to use a rather new qemu and an older > Debian/Ubuntu system as too recent instructions always are a problem. > As I said the community cloud likely is your quickest way out of this. Indeed it was the quickest way. I have now compiled gptfdisk from source on the s390x instance and compared it against the bundled 'gdisk' on RHEL8.3. I used a GPT sample image that I created with the 'gpt' utility in macOS, just to make sure it's untouched by the gdisk utility on any platform. It has 8 partitions with the phrase "File system" in various different languages as GPT partition labels (for testing Unicode chars). I uploaded the image here: https://catacombae.org/temp/gpttest.img.bz2 I am however getting the same results as I got on my PowerPC setup. With the RHEL8.3-provided gdisk 1.0.3: -------- $ uname -a Linux catacombaetest 4.18.0-305.3.1.el8_4.s390x #1 SMP Mon May 17 10:16:29 EDT 2021 s390x s390x s390x GNU/Linux $ sudo gdisk /dev/loop1 GPT fdisk (gdisk) version 1.0.3 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): p Disk /dev/loop1: 262144 sectors, 128.0 MiB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): A4FE502F-C264-4D51-920B-3849BB696BA7 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 262110 Partitions will be aligned on 2-sector boundaries Total free space is 98237 sectors (48.0 MiB) Number Start (sector) End (sector) Size Code Name 1 34 20513 10.0 MiB 0700 䘀椀氀攀 猀礀猀琀攀洀 2 20514 40993 10.0 MiB 0700 ꌃ촃쌃쐃뜃밃넃 넃섃윃딃꼃줃봃 3 40994 61473 10.0 MiB 0700 蝥ﭼ 4 61474 81953 10.0 MiB 0700 ␄〄㤄㬄㸄㈄〄伄 䄄㠄䄄䈄㔄㰄〄 5 81954 102433 10.0 MiB 0700 䘆㠆✆䔆 ✆䐆䔆䐆䄆✆⨆ 6 102434 122913 10.0 MiB 0700 ⬉㸉܉㈉ 㠉㼉㠉䴉Ἁ⸉ 7 122914 143393 10.0 MiB 0700 8 143394 163873 10.0 MiB 0700 锋ꌋ뼋꼋锋촋锋쬋ꨋ촋ꨋ섋 긋섋넋젋긋젋 Command (? for help): q -------- It's all garbage. However with the patched and freshly compiled gdisk 1.0.7 straight from git: -------- $ uname -a Linux catacombaetest 4.18.0-305.3.1.el8_4.s390x #1 SMP Mon May 17 10:16:29 EDT 2021 s390x s390x s390x GNU/Linux $ sudo ./gdisk /dev/loop1 GPT fdisk (gdisk) version 1.0.7 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Command (? for help): p Disk /dev/loop1: 262144 sectors, 128.0 MiB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): A4FE502F-C264-4D51-920B-3849BB696BA7 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 262110 Partitions will be aligned on 2-sector boundaries Total free space is 98237 sectors (48.0 MiB) Number Start (sector) End (sector) Size Code Name 1 34 20513 10.0 MiB 0700 File system 2 20514 40993 10.0 MiB 0700 Σύστημα αρχείων 3 40994 61473 10.0 MiB 0700 文件系统 4 61474 81953 10.0 MiB 0700 Файловая система 5 81954 102433 10.0 MiB 0700 نظام الملفات 6 102434 122913 10.0 MiB 0700 फाइल सिस्टम 7 122914 143393 10.0 MiB 0700 טעקע סיסטעם 8 143394 163873 10.0 MiB 0700 கணியக்கோப்பு முறைமை Command (? for help): q -------- With the version compiled from git including my fix it looks fine. All characters are decoded properly. Would you be able to test this image on your Ubuntu s390x instance and report back the results? Or provide an image with a counterexample? Best regards, - Erik >> On 8.6.2021 10.12, Christian Ehrhardt wrote: >>> Hi, >>> I wanted to let you know that the recent try to fix big endian byte >>> swapping is actually breaking big endian in 1.0.7. >>> >>> This is broken on s390x (=big endian) in Debian [1] and Ubuntu [2]. >>> >>> When you look at just these logs it seems it is just failing for no >>> apparent reason, >>> but with -x enabled in gdisk_test.sh one quickly sees there is some >>> string-mangling happening: >>> >>> Number Start (sector) End (sector) Size Code Name >>> 1 2048 131038 63.0 MiB 8300 䰀椀渀甀砀 昀椀氀攀猀礀猀琀攀洀 >>> >>> Reading the very same file with the old gdisk is good - so likely the >>> on-dis content is good as well: >>> Number Start (sector) End (sector) Size Code Name >>> 1 2048 131038 63.0 MiB 8300 Linux filesystem >>> >>> This is caused by GPTPart::GetDescription due to this change [3] in 1.0.7 >>> >>> Reverting this fixes change fixes the problem. >>> >>> [1]: https://buildd.debian.org/status/fetch.php?pkg=gdisk&arch=s390x&ver=1.0.7-1&stamp=1617791278&raw=0 >>> [2]: https://launchpadlibrarian.net/540613637/buildlog_ubuntu-impish-s390x.gdisk_1.0.7-1_BUILDING.txt.gz >>> [3]: https://sourceforge.net/p/gptfdisk/code/ci/86dd5fea351a5a55bea26b7622eb85ebd6075a60/ >>> > > |
