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

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

...

> This was a thought error. I meant most significant byte, not least. :)

not a problem, the examples were more important anyway

> > --------
> > $ dd if=tmp/test1.0.6 bs=$[1024+128] count=1 | xxd -a
...
> > 00000430: 0000 0000 0000 0000 004c 0069 006e 0075 .........L.i.n.u
> > 00000440: 0078 0020 0066 0069 006c 0065 0073 0079  .x. .f.i.l.e.s.y
> > 00000450: 0073 0074 0065 006d 0000 0000 0000 0000 .s.t.e.m........

Yes, thanks for the command I was able to confirm that.

...

> > Another indicator that there's something wrong is that GNU parted
> > doesn't print the label:

oO :-/
...

> > If sgdisk created these partition layouts, then there's clearly a bug
> > in sgdisk which makes it write labels characters in big-endian format
> > without byteswapping them.

Indeed - gdisk exposes the same issue when creating partition labels
as the test of gdisk was what initially made me look at this.
I guess they share the underlying code anyway.

I'm slightly scared as that means the gdisk we have in the field -
potentially for quite a while - was labeling the wrong way.
I'm somewhat afraid how to handle the disk/images that have already
written tables as the fix to the display function will make it show
the mangled data.

To get a feeling I was checking this through all kinds of past
releases and architectures.
It seems to only affect s390x, but there all Ubuntu release up until
16.04 are affected the same way.
That matches gdisk versions 1.0.1 - 1.0.7
For example:

$ lxc exec testkvm-xenial-to -- bash -c "dd if=/dev/zero
of=/tmp/mytest bs=1024 count=65536; sgdisk /tmp/mytest -o; sgdisk
/tmp/mytest -n 1 -c '1:Linux filesystem' -t 1:8300; dd if=/tmp/mytest
bs=$[1024+128] count=1 | xxd -a | grep 't.e.m'"
...
00000450: 0073 0074 0065 006d 0000 0000 0000 0000  .s.t.e.m........

Well let us find the root cause and fix first and then think about
what we could do to handle past issues any better.
Since we don't have any specific delta on top of gdisk I wonder why
"our" gdisk would be affected but not the one of RH8.3 that you were
testing.

> 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