Closed iii-i closed 1 year ago
I am afraid this may cause other problems. In https://github.com/libbpf/ci/commit/414e80f1cf620c95817c0cbbec5510c69f1f7ffb we scaled back to bulleye because of some SSL library version issue. I should be able to confirm with some logs later. I has made the script a bit more generic but did not go old the way to testing that the rootfs creation worked just right.
I think at this stage we will eventually need to just build a rootfs for the same env then the runner itself or we will keep on having those kind of issues where the binary is build on a host with a set of dependencies which will be missing on the target platform.
https://github.com/libbpf/ci/issues/48#issuecomment-1278272600 is what I was referring to.
The commit https://github.com/libbpf/ci/pull/52/commits/85be0e8f6d0e39da0dd1261023281d1b677499a6 explains why we did the downgrading.
Oh, that's unfortunate. Thanks for digging up the rationale for downgrading.
vmtest.sh fails on new distros with:
./test_progs: /lib/s390x-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./test_progs)
Upgrade the guest OS to handle new glibcs.
If this change is merged, could someone please run
sudo ./mkrootfs_debian.sh --arch=arm64 sudo ./mkrootfs_debian.sh --arch=s390x
and update https://github.com/libbpf/ci/blob/master/INDEX? I tested this locally, but I do not have access to S3.
I think here the problem is that we do not have a way to do close distribution matching… we could probably fix that in the way the INDEX is generated so vmtest can either inform the target rootfs, discover a matching one, or default to something kinda sane.
@iii-i I captured what we could do to solve this in #84. Feel free to comment :)
vmtest.sh fails on new distros with:
Upgrade the guest OS to handle new glibcs.
If this change is merged, could someone please run
and update https://github.com/libbpf/ci/blob/master/INDEX? I tested this locally, but I do not have access to S3.