Repository navigation
Bug: Fail to build on s390x and 32-bit architectures #648
Description
stacker version
v1.0.0
Describe the bug
I'm trying to package stacker for AlpineLinux at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60169. CI in the MR fails for different architectures as listed below:
32-bit platforms (x86, armhf, armv7)
The error comes from building submodule https://github.com/project-machine/atomfs.
# machinerun.io/atomfs/squashfs
vendor/machinerun.io/atomfs/squashfs/verity.go:112:22: cannot use _Ctype_ulong(verity.HashOffset / uint64(os.Getpagesize())) (value of type _Ctype_ulong) as _Ctype_uint64_t value in assignment
vendor/machinerun.io/atomfs/squashfs/verity.go:113:29: cannot use _Ctype_ulong(verity.HashOffset) (value of type _Ctype_ulong) as _Ctype_uint64_t value in assignments390x
On s390x, Statfs_t struct has element Type of uint32. The type is int32 for 32-bit platforms. Ref: https://cs.opensource.google/go/x/sys/+/refs/tags/v0.26.0:unix/ztypes_linux_s390x.go
# stackerbuild.io/stacker/pkg/stacker
pkg/stacker/check.go:107:26: cannot use st.Type (variable of type uint32) as int64 value in map indexTo reproduce
make -C cmd/stacker/lxc-wrapper LDLIBS="$(pkg-config --libs lxc) -lpthread -ldl" lxc-wrapper
go build -v \
-tags exclude_graphdriver_btrfs,exclude_graphdriver_devicemapper,containers_image_openpgp,osusergo,netgo,external_libzstd \
-ldflags "-X stackerbuild.io/stacker/pkg/lib.StackerVersion=v$pkgver -X stackerbuild.io/stacker/pkg/lib.LXCVersion=$(pkg-config --modversion lxc)" \
./cmd/stackerExpected behavior
The build succeeds.
Screenshots
No response
Additional context
No response
Activity
rchincha commentedon Oct 17, 2024
@folliehiyuki stacker for its isolation uses lxc which ties it closely to linux/amd64 arch (at least for now)
We are looking to build for other platform/arch maybe using qemu.
hallyn commentedon Oct 17, 2024
lxc on s390 should be fine. But github doesn't have s390x runners.
@folliehiyuki do you by any chance have a s390 that could be used as a self-hosted github action runner? :-)
mikemccracken commentedon Oct 17, 2024
I see that the PR has
arch="all":https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60169/diffs#c7e8b1dcf9ee996620985421d1559f431d242bc9_0_7
@folliehiyuki - unless you specifically want to include 32-bit platforms, would you be OK with adjusting this to just say
arch="x86_64"so it can get merged and be available for the platform that (I believe) users are most likely to want to use stacker on?folliehiyuki commentedon Oct 18, 2024
Sadly I only have x86_64 machines to test the package on. For AlpineLinux, if the package isn't broken (on an "unusable" level) on a specific architecture, it's encouraged to build and provide the package in the repo for as many architectures as possible.
With some naive patches, I've managed to get
stackerbuilt for x86_64, aarch64, loongarch64, ppc64le, riscv64 while x86, armhf, armv7 and s390x are current broken as reported here.lxcpackage is available on all AlpineLinux repositories, so it shouldn't be an issue for the build there.If upstream can benefit from having the package in AlpineLinux repository, and is interested in making it built on other platforms, I'm happy to disable the build on those failing architectures for the time being.
rchincha commentedon Oct 19, 2024
Not sure what "upstream" means. But from stacker pov, we are happy to have it included/packaged as part of AlpineLinux repo.
folliehiyuki commentedon Oct 19, 2024
Sorry! I was talking with the perspective of a downstream distro's package maintainer, so "upstream" means this repo here. I've disabled the alpine build on platforms where it failed.
rchincha commentedon Oct 21, 2024
https://pkgs.alpinelinux.org/packages?name=stacker
^ see this now.
mikemccracken commentedon Oct 21, 2024
🥳 nice to see it in there. Thanks @folliehiyuki !
sertonix commentedon Sep 30, 2026
When project-machine/atomfs#49, project-machine/atomfs#55 and #804 are merged this should be fixed.