Rasdaemon was added in previous patch.
Add a test_rasdaemon that allows to test it.
Test is done on x86. It first checks the daemon's version, then mounts
debugfs and finally ensures that the init script allows to
start/restart/stop the daemon.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
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>
Add new runtime test for python-varlink.
As always when we need to start a separate server process inside a test
case this gets slightly fiddly.
We override the test_run() function to first start the varlink example server,
then call the packages cli interface to do a varlink call against the
server. The cli defaults to pretty printing the result, which makes it
more annoying to compare to the expected result in the test case, so we
un-prettyprint it with python's builtin json.tool module.
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
Some host commands need to call other host commands: For example,
"mkimage" from host-uboot-tools needs to run "dtc". This would fail or
call system commands without adding the host bin dir to PATH.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
[Julien: use python functions/constants to build path]
Signed-off-by: Julien Olivain <ju.o@free.fr>
Add a simple test ensuring that
- libldns is correctly built and installed
- drill is correctly built and installed
- drill is able to execute on the target
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Runtime test cases are currently mostly used to test target packages,
and the BRTest class is perfect for that as we can easily feed a
Buildroot configuration, boot it under Qemu and run commands inside
the emulator.
A few tests use the more basic BRConfigTest when they have special
needs that don't match with BRTest.
However, as we are going to add a number of tests to verify the proper
functionality of some host only packages, which have no visible
menuconfig option, it makes sense to add another BRHostPkgTest class
that allows to easily trigger the build of "make host-<foo>
host-<bar>", and then run some commands on the host machine. Such
tests could be done by using BRConfigTest, but that would require a
bit of duplicated boilerplate, which BRHostPkgTest allows to remove.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
When run_cmd_on_host() runs a command that fails, we only get an
exception with no details to debug what happened. Let's improve that
by catching the exception, and printing the command output. This
requires redirecting stderr to stdout (instead of /dev/null) and
asking to get the output in text format.
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>
