EDK2 removed OVMF IA32 support in commit [1], which is included in
version edk2-stable202511. This commit removes the test relying on it.
[1] 1fb88ffe28
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit bd06eace37)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
EDK2 removed OVMF IA32 support in commit [1], which is included in
version edk2-stable202511. This commit removes tests relying on it.
[1] 1fb88ffe28
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
(cherry picked from commit cf16e1abe0)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The CPIO filesystem generated by the test_firewalld test is too
large, and doesn't fit as an initramfs in the 256MB of RAM available
in the versatilepb machine. This causes a "Initramfs unpacking failed:
write error" when booting, and many files being missing from the root
filesystem, ultimately causing the test to fail.
The test_firewalld test initially started to fail following a systemd
update [1][3]:
[BRTEST# systemctl is-active firewalld
failed
But really started to crash at boot following a python 3.14 update
[2][4]:
Run /init as init process
/init: exec: line 15: /sbin/init: not found
Also, update TestFirewalldSysVInit to use ext2 instead of cpio.
[1] 926e0504d0
[2] a0a6abc8b1
Fixes:
[3] https://gitlab.com/buildroot.org/buildroot/-/jobs/12944797059
[4] https://gitlab.com/buildroot.org/buildroot/-/jobs/11856840940
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 6a7fe6382a)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Peter: Fix flake8 warning, use http.server instead of relying on
connectivity]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 425abcd025)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The test failed in the past, due to kbd build failure. See [1].
This specific issue was fixed by commit [2].
This commit was originally written to workaround this issue, which was
unrelated to the actual package being tested. Since systemd-vconsole
is not needed anyway, this commit removes it from the test config.
[1] https://gitlab.com/buildroot.org/buildroot/-/jobs/12363929666
[2] d98d9ba28f
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
[Julien: reword the commit log]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 287d06f5d7)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Python 3.14 (not yet in Buildroot) introduced colors, enabled by
default, when the output is a terminal. This behavior can make the
pexpect pattern matching more difficult in some cases. See:
https://docs.python.org/3.14/using/cmdline.html#controlling-color
This commit globally disables the Python interpreter colors in the base
runtime Python test, by setting the NO_COLOR=1 environment variable.
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 3a6e2b4a03)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Enhance the Xen python tests to exercise block devices: this boils down
to switching from ramdisks to disk partitions for the domains rootfs.
(Refer to the comments in the python script for block devices details.)
- Add support for PCI and Xen block to the Linux kernel configurations.
- Add a few commands to list the xvda block device for good measure.
- Generate two partitions with the rootfs in the disk images; we use the
same rootfs contents twice, once for each domain.
- Add a paravirtualized block device to the Xen dom1 configurations and
adjust both domains kernel command lines, to specify the rootfs
locations.
- Build host-qemu for Arm v7, to workaround an issue with 32b Arm and
old Qemu versions, which is what we have on CI currently.
- While at it, bump Linux kernel to 6.18.4 and U-Boot to 2026.01.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 09baeb4653)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The run log of this ltp-testsuite test shows:
INFO: runltp script is deprecated, try kirk
https://github.com/linux-test-project/kirk
This commit updates this test to replace this deprecated runltp
shell script with the newer kirk Python script.
The logic of this runtime test remains the same: it runs a small number
of 'read' system call tests, and checks there is no failures and at
least one test succeed.
Cc: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Acked-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 43e254a646)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The ddresue runtime test is using the `dmsetup` command provided by the
dmraid package. This package is outdated and will be removed. This
command is also provided by the lvm2 package, which is still maintained.
This commit replaces the dmraid package by lvm2 in the test config.
Signed-off-by: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(cherry picked from commit 4fc6e8637b)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The tests check if all supported hash algorithms are usable in
mkimage, for both host and target packages. Additionally, as a
necessary tool, it verifies the previous fix for FIT output from
dumpimage.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Julien: use builtin kernel for faster testing]
Signed-off-by: Julien Olivain <ju.o@free.fr>
(cherry picked from commit 2dbe71dba6)
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
The 5.4.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Bump kernel version in test_zfs.py.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since version 256, systemd will taint the system if /usr/bin and
/usr/sbin are not merged, known as merged-bin:
# systemctl --no-pager status
● buildroot
State: running
Units: 166 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Mon 2025-07-07 19:48:05 UTC; 19s ago
systemd: 257.7
Tainted: unmerged-bin
CGroup: /
├─init.scope
[...]
Although this is not yet an error, it will be in the future.
To be as ready as we can be when that happens, forcibly enable
merged-bin, like we did when we initially added merged-usr (except
this time we carry the select from systemd, even though it is not
yet strictly required, rather than from the init entry).
Extend the runtime test to catch any tainted flag.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Sen Hastings <sen@hastings.org>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The test tests.package.test_xen.TestXenArmv7 has become unstable after
commit 24ff258905 ("support/testing: test_xen: add networking"),
leading to a ~50% chance of failure on gitlab CI.
This seems to happen only with 32b (not with the 64b TestXenAarch64),
only with Qemu < 9.1, and when this happens the test will hang during a
step involving the simulated network and the dom1 (DHCP or ping).
The root cause is suspected to be a bug in the virtio-net hardware
emulation of the qemu version 7.2.15 included in the Buildroot docker
image.
As a workaround, remove all network interactions between dom1 and the
simulated network:
- Instead of the gateway, ping dom0 from dom1.
- Instead of using DHCP, configure the network with fixed IP addresses,
so that we know the IP address of the dom0.
A possible solution could have been to compile a host-qemu within the
test, by adding BR2_PACKAGE_HOST_QEMU=y and
BR2_PACKAGE_HOST_QEMU_SYSTEM_MODE=y in the test configuration.
This would have used the current Buildroot version (10.1.0) not affected
by this issue, but this would also have significantly increased the test
compilation time.
Since the DHCP is not really needed here to test the Xen networking
capability, this is why the network configuration simplification was
preferred here.
After those changes both Xen tests are stable on CI and locally.
Fixes: https://gitlab.com/buildroot.org/buildroot/-/jobs/11871454648
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds a package for Snagboot, the open-source
vendor-neutral recover and reflashing tool for embedded targets. We
install the dependencies needed for snagrecover and snagflash, but we
don't bother installing the dependencies of the GUI-based snagfactory,
as that would require Kivy on the host, which is Qt based.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds a new host package for python-pyfatfs, which is
needed by Snagboot.
Homepage: https://pypi.org/project/pyfatfs/
A small test doing some minimal verification that pyfatfs works is
also added.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds a host package for the Python 'fs' module, needed as
a dependency of pyfatfs, itself needed by Snagboot.
Homepage: https://pypi.org/project/fs/
In addition, a very simple test case is adding to check that
host-python-fs is minimally working.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The host variant of python-xmodem will be needed by Snagboot, so this
commit enables it. We also add a very simple test case that simply
makes sure we can import the module. Testing xmodem more extensively
is difficult without an actual serial port to open.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The host variant of python-pyusb will be neded for Snagboot, so it is
enabled with this commit. In addition, we're adding a very simple test
case to validate that host-python-pyusb minimally works.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
A host variant of python-tftpy will be needed for Snagboot, so enable
it, and add a very simple test for the host package. We considered
adding a test that actually starts a TFTP server with tftpy and then
downloads from that server with the client-side of tftpy, but
allocating an available UDP port reliably is tricky, so we kept the
test case very simple for now.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Colin Foster <colin.foster@in-advantage.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This quickly tests that the host-python-serial package at least
minimally works.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This commit adds a new host only package for the crccheck Python
module, which is a dependency of Snagboot.
Homepage on PyPi: https://pypi.org/project/crccheck/
This commit also adds a very basic test case that allows to verify
that the Python module can be imported and that some minimal
functionality works.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The getunconfirmedbalance rpc call was marked as deprecated
in [1] (included in v0.19.0, released on 2019-11-08) and removed
in [2] (included in v30.0, released on 2025-10-09).
This commit replaces the old getbalance/getunconfirmedbalance rpc
calls with the new call getbalances (plural) returning a json
object containing all the data.
This commit is needed before updating bitcoin to v30.0.
[1] facfb4111d
[2] c3fe85e2d6
Cc: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When the test was introduced in [1], a comparison of the source and
the destination file was added, with a typo (the method ".cmp" name is
missing).
The test is failing with error such as in [2]:
Traceback (most recent call last):
File "/root/sample_python_scp.py", line 15, in <module>
assert filecmp("/etc/hostname", "/tmp/hostname")
~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'module' object is not callable
This commit fixes that.
[1] 7470587cfa
[2] https://gitlab.com/buildroot.org/buildroot/-/jobs/11781378510
Cc: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a basic test involving a local SSH connection (based on dropbear
server). The test validates that we are able, through python-scp, to
fetch the /etc/hostname file.
The test needs some basic key initialization to allow connecting to the
dropbear server, hence the custom run_sample_scripts method.
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
[Julien:
- remove unneeded os import in test script
- execute setup commands with assertRunOk()
- create /root/.ssh with 0700 mode
- run sample scripts using super()
- check in the sample file that copied files are the same
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The test is using the django integration of whitenoise as it's the most
common setup and allows to model the test case after the django one as
well.
The setup we need to do is a bit more complicated though and follows
the whitenoise getting started documentation [1].
We then request a .css file from the django admin app that is enabled
by default in template project. Due to running django's development
server with --nostatic we ensure that static file handling is taken over
by whitenoise.
[1] https://whitenoise.readthedocs.io/en/stable/django.html
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Enhance the Xen python tests to exercise networking:
- Add the networking support we need to the Linux kernel configurations.
- Add a virtual network interface to the Xen dom1 configurations.
- Update the test in the following way:
* Start the emulator with restricted networking.
* Create a network bridge in dom0.
* Check that networking is functional in both domains by ping'ing the
gateway.
(Refer also to the diagram in the python script.)
- While at it, bump Linux kernel to 6.17.1 and U-Boot to 2025.07.
We also need to adjust the DTB address in the Arm 32b U-Boot script to
accommodate the new U-Boot version, which does not have enough free space
around the control DTB anymore.
We disable IPv6 in both kernel configurations to make the 32b test pass
on gitlab CI.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Policy booleans allow adjusting certain policy rules at runtime
(including whether changing policy booleans is allowed). The new
option allows setting their defaults at build time.
A monolithic policy (like built by package/refpolicy) does not support
persistent changes to policy booleans, so changing the defaults is
required to make changes across boots. Adjusting policy/booleans.conf
after "make conf" is intended for that purpose [1, 2].
[1] https://github.com/SELinuxProject/refpolicy/pull/355#issuecomment-792758725
[2] 4d97523c71/README (L186-L191)
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
Signed-off-by: Julien Olivain <ju.o@free.fr>
TestGitHash and TestGitRefs are failing on Gitlab-CI since 2025-08-18
(first runtime-test failures report for master) [1] due a new Gitlab-CI
security settings that prevents the any use of localhost (127.0.0.1) on
the Gitlab-CI runner [2]:
"To prevent exploitation of insecure internal web services, all webhook
and integration requests to the following local network addresses are
not allowed:
Private network addresses, including 127.0.0.1, ::1, 0.0.0.0,
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and IPv6 site-local
(ffc0::/10) addresses."
Gitlab suggest using a second container as a Services [3] since each
containers have access to one another and can communicate when running
the job. But this is really not practical to run git daemon since the
service is started before the Buildroot git tree is fetched and git
daemon needs git-remote directory content.
See [4]:
"If you have your service that tries to write to CI_PROJECT_DIR
immediately after it's started - it will not work and fail with an
error like '/builds/nknapp/gitlab-ci-test/': No such file or directory
error. Because that directory is most probably not there yet, as the
job step that creates it is yet to be executed!"
Also, using Gitlab-CI services requires to handle GitTestBase setUp
differently on Gitlab-CI than local use of run-tests.
So Gitlab-CI services is not an option.
We could move support/testing/tests/download/git-remote to our Gitlab
group (https://gitlab.com/buildroot.org) but since it's only intended
for testing the git download backend, we don't really want to do that.
So the only remaining choice to clone the repository from the Buildroot
git tree (local machine).
To do so, we have to do the following changes:
- Replace all "git://localhost:$(GITREMOTE_PORT_NUMBER)" by
"$(GITREMOTE_DIR)". GITREMOTE_DIR will contain the absolute path to
tests/download/git-remote directory.
- Force to use git download backend using "SITE_METHOD = git" otherwise
the download infra will fall back using wget download backend.
- Cloning a git repository with submodules using the "file://" protocol
needs to be allowed from git config. It's disabled by default:
"fatal: transport 'file' not allowed"
Use a local gitconfig file generated by GitTestBase before starting
TestGitHash and TestGitRefs with:
[protocol "file"]
allow = always
This is considered safe since we are using a git repository from the
Buildroot git tree.
- Running TestGitHash and TestGitRefs on Gitlab-CI requires additional
git config settings to disable ownership check of the git tree [5].
Thanks to Arnout for advices about GIT_CONFIG_GLOBAL.
Runtime tested:
https://gitlab.com/kubu93/buildroot/-/jobs/11428504450 (TestGitHash)
https://gitlab.com/kubu93/buildroot/-/jobs/11428490035 (TestGitRefs)
[1] https://lore.kernel.org/buildroot/68a3ee65.500a0220.397724.30db@mx.google.com/
[2] https://docs.gitlab.com/security/webhooks/#allow-requests-to-the-local-network-from-webhooks-and-integrations
[3] https://docs.gitlab.com/ci/services/
[4] https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25982#note_2139685797
[5] a016b693f7
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124174 (TestGitHash)
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124173 (TestGitRefs)
Cc: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
As reported on the mailing list [1] while investigating the
TestZfsUclibc Gitlab-CI failure, the python 3.13 interpreter itsef
segfault at runtime:
Fatal Python error: _PyThreadState_Attach: non-NULL old thread state
Python runtime state: preinitialized
Thread 0xSegmentation fault
This issue is related to the python 3.13 version bump [2] were several
internal changes were added [3] to support PEP 703 [4].
PEP 793 is about CPython’s global interpreter lock (“GIL”) removal
for multi-threads support that requires a working C11 "thread_local"
for thread-local storage [5].
The new uclibc-ng 1.0.55 release contains a fix for this issue [6].
This version is included in Buildroot commit [7].
Since the prebuilt Bootling aarch64 uclibc stable 2025.08-1 is based
on previous uClibc-ng release (1.0.54) we have to use the internal
toolchain backend to build a new uClibc-ng toolchain using uclibc-ng
1.0.55. Note: the toolchain config defined in this commit reflects
the options enabled in the Bootling aarch64 uclibc external
toolchains.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124859 (TestZfsUclibc)
[1] https://lore.kernel.org/buildroot/7a4d245d-1556-43c9-8997-6b1f791afbfe@gmail.com/ (TestZfsUclibc)
[2] d63e207eb8
[3] 6e97a9647a
[4] https://peps.python.org/pep-0703/
[5] https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Thread-Local.html
[6] 94c1297d52
[7] 5250bba8e5
Cc: José Luis Salvador Rufo <salvador.joseluis@gmail.com>
Tested-by: José Luis Salvador Rufo <salvador.joseluis@gmail.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Julien:
- add link to buildroot commit updating uclibc-ng to 1.0.55
- add a note in the commit log about the toolchain config
]
Signed-off-by: Julien Olivain <ju.o@free.fr>
The SBSA Reference Platform was updated to neoverse-n2 (armv9.0a)
in Qemu v9.1 [1].
The Armv9-A and Neoverse N2 core support was added in Buildroot
commit [2].
Since the test_edk2 uses the Qemu sbsa-ref machine, this commit
aligns it to use the neoverse-n2 cpu.
[1] b1d592e7b0
[2] 9845bd4541
Signed-off-by: Julien Olivain <ju.o@free.fr>
The SBSA Reference Platform was updated to neoverse-n2 (armv9.0a)
in Qemu v9.1 [1].
The Armv9-A and Neoverse N2 core support was added in Buildroot
commit [2].
Since the test_fwts uses the Qemu sbsa-ref machine, this commit
aligns it to use the neoverse-n2 cpu.
[1] b1d592e7b0
[2] 9845bd4541
Signed-off-by: Julien Olivain <ju.o@free.fr>
Luvi 2.14.0 fails to build with GCC 14.x for several reasons due to
too old lua-openssl 0.8.2-0 submodule:
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c: In function 'openssl_ocsp_request_read':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/ocsp.c:124:29: error: passing argument 1 of 'PEM_ASN1_read_bio' from incompatible pointer type [-Wincompatible-pointer-types]
124 | OCSP_REQUEST *req = pem ? PEM_read_bio_OCSP_REQUEST(bio, NULL, NULL)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| char * (*)()
Fixed in lua-openssl by [1].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c: In function 'openssl_push_general_name':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/x509.c:377:45: error: passing argument 2 of 'openssl_push_asn1type' from incompatible pointer type [-Wincompatible-pointer-types]
377 | openssl_push_asn1type(L, general_name->d.x400Address);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~
| |
| ASN1_STRING * {aka struct asn1_string_st *}
Fixed in lua-openssl by [2].
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/openssl.c: In function 'luaclose_openssl':
TestLuvi/build/luvi-2.14.0/deps/lua-openssl/src/stdatomic.h:387:9: error: implicit declaration of function '__c11_atomic_fetch_sub'; did you mean '__atomic_fetch_sub'? [-Wimplicit-function-declaration]
387 | __c11_atomic_fetch_sub(object, operand, order)
Fixed in lua-openssl by [3].
Instead of fixing one by one each issues, update to the latest release
that include lua-openssl 0.9.0-0. Luvi v2.15.0 still have some GCC 14.x
issues, backport two additional patches.
Download luvi sources using git method since the release archive
no longer include the release version in its name [4].
Luvi switched to PCRE2 [5], update the optional dependency.
Update TestLuvi to select PCR2 package.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11271124430 (TestLuvi)
[1] bfeedbe8c0
[2] e5b5420cc5
[3] cfcaa16d1a
[4] https://github.com/luvit/luvi/releases/download/v2.15.0/luvi-source.tar.gz
[5] https://github.com/luvit/luvi/releases/tag/v2.15.0
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
This toolchain is more than 7 years old now, and not maintained anymore.
Let's therefore remove it from Buildroot. There are still some
alternatives in-tree, such as ARM and Bootlin toolchains
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
[Romain:
- rename TestExternalToolchainLinaroArm to TestExternalToolchainArmGnu
- update toolchain prefix arm-linux-gnueabihf to arm-none-linux-gnueabihf
- replace BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM by BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7_EABIHF_GLIBC_STABLE
since the ARM toolchain can't be enabled due to missing NEON support
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This toolchain is more than 7 years old now, and not maintained anymore.
Let's therefore remove it from Buildroot. There are still some
alternatives in-tree, such as ARM and Bootlin toolchains
Signed-off-by: Titouan Christophe <titouan.christophe@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Since commit 947dbc92a2 the Bootlin
stable toolchain uses headers 5.4, which can lead to build outputs
incompatible with older kernels. Update to the latest 5.4 kernel to
avoid this. The kernel config is updated according to the requirements
of current Docker, runc, and crun.
Additionally switch the CPU of the test VM to Haswell, to avoid
dockerd failing to start with a "This program can only be run on AMD64
processors with v3 microarchitecture support" error.
Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
TestRelroPartial is broken since the last checksec update to 2.7.1 [1]
(Buildroot 2024.08) due to a relro check fix [2] that doesn't work for
powerpc architecture where .got.plt doesn't exist for some reasons
(that's why the expected result "full" is replaced by "Partial").
From [3]:
if ${readelf} -d "${1}/exe" 2> /dev/null | grep -q 'BIND_NOW' || ! ${readelf} -l "${1}/exe" 2> /dev/null | grep -q '\.got\.plt'; then
echo_message '\033[32mFull RELRO \033[m ' 'Full RELRO,' ' relro="full"' '"relro":"full",'
else
echo_message '\033[33mPartial RELRO\033[m ' 'Partial RELRO,' ' relro="partial"' '"relro":"partial",'
checksec tool is problably tested upstream on more common architectures
like x86_64 or aarch64 than powerpc64 e5500. This may explain why
checksec broke on powerpc64 e5500 target.
Also, the Booltin powerpc64-e5500--glibc--stable-2018.02-2 toolchain
used by test_hardening tests was not updated since the hardening tests
were introduced back in 2018.11 release.
So, switch to the current Bootling aarch64 stable toolchain
(currently Bootlin aarch64 glibc stable 2025.08-1).
Checked that all 6 hardening tests pass with this new toolchain:
tests.core.test_hardening.TestFortifyConserv
tests.core.test_hardening.TestFortifyNone
tests.core.test_hardening.TestRelro
tests.core.test_hardening.TestRelroPartial
tests.core.test_hardening.TestSspNone
tests.core.test_hardening.TestSspStrong
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/11176773995 (TestRelroPartial)
[1] 6150564974
[2] 1c80e39c49
[3] 1c80e39c49 (diff-9e8d1b28dfaf1c704560ac51a5613b70d70de2dcd84e87b9fa20f28811e6484aL1491)
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
