Re: [Gptfdisk-general] GPTPart::GetDescription broken in 1.0.7 on Big Endian systems

[Christian E. <chr...@ca...>]

On Tue, Jun 8, 2021 at 9:24 AM Erik Larsson <cat...@gm...> wrote:
>
> Hi,
>
> I submitted this patch and tested it on Ubuntu 16.04 PowerPC (big
> endian, 32-bit) which had the same string-mangling problem when this fix
> is *not* applied... so there's something weird going on.

Agreed and thanks for the quick reply.

> 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.

The https://wiki.debian.org/PPC64 for big endian exists but is
unofficial and thereby might have some issues.

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/#

> 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.

> 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/
> >



-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd