Open zhaiyan920 opened 1 year ago
Thanks @zhaiyan920 for reporting this, and sorry for getting to it so late.
In the future, we may not need to use the rootfs as part of the CI, so this should be resolved at the same time.
It's all good as I worked around the issue with some variant implementation. Just curious, what alternatives do you plan to replace rootfs? Is it possible we use 9p and virtio instead in future?
It's all good as I worked around the issue with some variant implementation. Just curious, what alternatives do you plan to replace rootfs? Is it possible we use 9p and virtio instead in future?
Yeah, that would be the plan. So using the host root.
— Reply to this email directly, view it on GitHub https://github.com/libbpf/ci/issues/103#issuecomment-1793516779, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAF77A6TFEYA2ZSOS5MOXTYC2DPZAVCNFSM6AAAAAA3UOAT6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGUYTMNZXHE . You are receiving this because you commented.Message ID: @.***>
Hi,
I was encountering some relocation issue when test PR on BPF-CI. After some digging the error says:
libbpf: prog 'test_lwt_redirect_in': bad map relo against '.rodata.str1.1' in section '.rodata.str1.1'
It turns out the latest root image libbpf-vmtest-rootfs-2022.10.23-bullseye-amd64.tar.zst has iproute2 with libbpf-0.3, and support for .rodata. was introduced in commit 5bf62459b185 ("libbpf: Support multiple .rodata. and .data. BPF maps") from v0.6.0. Unpacking and running the root image locally with same BPF object confirms that upgrading libbpf0 would fix the issue.
Will it be feasible if admins can update the root image to pull libbpf0 from bullseye-backport? It does have slight newer version https://packages.debian.org/bullseye-backports/libbpf0, or better if we can have newer iproute2 and libbpf1 in the root image?
thanks