ppc64le - GU_PAGE_SIZE(4096) does not maptch real system page size(65536)

I am facing the same issue, please patch the code fix to solve this defect. Thanks.
https://github.com/MariaDB/galera/commit/0e815d9f12af74e3e94bcb39a913d26bdfd946b8

Status changed to 'Confirmed' because the bug affects multiple users.

It looks to me like the version of galera-3 in Xenial, Zesty and Debian sid has architecture-specific code/configure paths and has never supported ppc64le. Is this correct?

The upstream patch does not apply cleanly - neither to sid nor to Xenial (but differently). So we don't have a fix available right now.

The conflict in sid looks like it'll take more rework. The conflict in Xenial is simpler, which seems odd. It may be that the automatic conflict resolution is not sufficient and it will be more involved to fix properly.

Additionally galera-3 is FTBFS on armhf in zesty-proposed right now, so it's an additional pain to resolve to get this fixed in Zesty.

Has this package ever worked on ppc64le, or is this an enablement request rather than a defect?

I think it's always been broken for us in OIL, I don't know if it ever worked on ppc64le.

I have done a preliminary backport. Please can you test on ppc64el to see if this fixes the problem? My backport is at ppa:racb/experimental.

Note that armhf FTBFS for some reason, so this will need further investigation since it did work in Xenial previously. It's not clear to me from the build log whether this is something I introduced in my backport, or there is some other reason for the failure.

Also, I haven't looked at addressed the situation in Zesty at all, and this will need resolving before any SRU.

Backport notes:

There are two upstream branches: codership's 3.x and mariadb-3.x.
mariadb-3.x regularly merges in codership's 3.x branch. This merging
happens in only one direction; effectively codership's branch is
mariadb-3.x's upstream. mariadb-3.x's branch is what is packaged in this
source.

Two relevant commits are 0e815d9 and 22c4a52. 0e815d9 adds ppc64el
support, only exists in the mariadb-3.x branch, and is what is
backported here. 22c4a52 adds s390x support and exists in both branches.
The changes introduced by the two commits first appear together in
6896615.

Cherry-picking 0e815d9 on its own results in a merge conflict because of
the changes introduced by 22c4a52. Since this conflict was already
resolved by mariadb-3.x upstream in 6896615, this backport resolves the
conflict in exactly the same way.

I tried to test but percona-galera-3 is what actually gets installed in our deployment. We'd need this package built as well in order to be able to verify the fix.

Will it be possible to have that built as well please?

@Larry,

I've patched and built percona-galera-3 in my PPA now too. Please try this. Note that I'm still just throwing patches at it to see what sticks. If it works, then I'll need to do it properly before we can land a fix in Ubuntu.

@robbie, this might be related:

https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.5/+bug/1657256

I have run an hour-long sysbench oltp test against percona built form my ppa, and haven't had issues, nor ones that are mentioned in #1657256 or from this bug.

That is, Robie, not Robbie :)

Tests are run as part of the build. In Debian galere-3 builds fine on ppc64el: https://buildd.debian.org/status/package.php?p=galera-3

Is this issue still valid?

Current galera-3 in Xenial is 25.3.14-1. Should we backport and upload the 25.3.22-1 from Debian Sid to Xenial?

There are no reports that this would affect galera-3 anymore, so marking it solved now.