Refactor code to build the initramfs and kernel as user, instead of
running related code as root. Put the smoke_test.log into /tmp instead
of the cache dir, so we don't write as root into the cache dir. We cat
it on error anyway, so we don't need to have it in the workspace.
Change-Id: I1670dd86f2670f42eb99e4527d483965d8222402
The previous versions happened to work too in my testing with
osmo-ggsn. Use the correct loop variable.
Fixes: 0660fc4e ("scripts/kernel-test: adjust to usr-merge")
Change-Id: I0c0ca91116a8cd156b185bb53512371bbcb76515
Set init= so the kernel doesn't try to run other scripts if /init
fails:
[ 2.946381] Run /init as init process
[ 2.948885] Failed to execute /init (error -2)
[ 2.949051] Run /sbin/init as init process
[ 2.949329] Run /etc/init as init process
[ 2.949566] Run /bin/init as init process
[ 2.949795] Run /bin/sh as init process
Change-Id: I063c7625acaa15130d8361d4e944c3773c9b37c4
In debian bookworm, the /usr merge has been implemented:
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
The initramfs filesystem layout is derived from the paths of the
binaries and libraries in the full system. Create the same symlinks and
adjust initrd_add_bin so it does not trip over the symlinks.
I've also considered to change all input for initrd_add_bin to point at
the /usr/… paths. But this is not possible, for example ldd/lddtree will
point at libraries in /lib and /lib64, and this gets passed to
initrd_add_bin.
Without this patch, the init script and all binaries called from it
cannot be executed.
Related: OS#6057
Related: https://wiki.debian.org/UsrMerge
Change-Id: I975d3af0fa88869688673936a08189de800fba29
As "docker kill" / "docker container kill" (alias) doesn't block until
the given container stops, make sure to always run "docker wait"
afterwards.
Closes: OS#5928
Change-Id: I0242ece96541d8036ebbf8b0f498ebf231db26b5
Try multiple subnet numbers until successfully creating a network. This
way we can run the same ttcn3 testsuite multiple times in parallel
without conflicts (e.g. once against latest, once against nightly). Also
we don't need to make sure each new testsuite has a unique subnet
number anymore.
I've considered also adjusting network_bridge_create, but that gets used
exclusively by osmo-ran/jenkins.sh, a script which we don't actually run
in jenkins. It seems that in this script it makes more sense to not get
a random subnet number.
Related: OS#5802
Change-Id: I57152b08ef0f38e17e7019a8df032189b03f56cf
Add a $SUBNET parameter and use it throughout the script, similar to
other ttcn3-*/jenkins.sh scripts. This is in preparation for figuring
out a free network in network_create() automatically in a future patch.
Related: OS#5802
Change-Id: I3bda4bd7280469ad5ee02104295134a2e0b768e3
Get rid of -nodefconfig, it has been removed in qemu 3.1. We are
supposed to use -no-user-config instead, which we already do.
Fix for this error we see since migrating to debian-bullseye:
qemu-system-x86_64: -nodefconfig: invalid option
Related: OS#4969
Related: https://qemu.readthedocs.io/en/stable/about/removed-features.html#nodefconfig-removed-in-3-1
Change-Id: I4a00f90980bf6d141ef8d86786e08d405db6db0b
If the checked out git repository already has a remote with the name
KERNEL_REMOTE_NAME, make sure that the KERNEL_URL matches the remote
URL.
Motivation for this change is osmo-ci
I5d4202a67a24d9c15a5b211fa29ce9d5b5a9d9c1, which will expose the
parameters in the jenkins job.
Related: OS#3208
Change-Id: I18b29011e3e8e2577bdf1a9c64c4370309cc8399
Disable KVM if /dev/kvm is missing, as it is apparently the case on our
jenkins nodes. This makes the tests run a bit slower, but not much. Add
kernel_test_wait_for_vm to sleep until the VM is booted up (~5s instead
of ~1s without KVM), so the first test in the testsuite does not fail
when using KVM.
The variable is useful to test the non-KVM code path even if KVM is
available on the host.
Related: OS#3208
Change-Id: I1f337af1e2de6db05b22636bc31a535404235559
Make it possible to run ttcn3-ggsn-test against osmo-ggsn with the GTP
kernel module. This feature is enabled by environment variables
explained in ttcn3-ggsn-test/jenkins.sh, and can either use the
pre-built kernel from Debian, or build a kernel from source.
The kernel runs inside QEMU inside the usual osmo-ggsn-master docker
image.
Thanks to Pau for providing the kernel config and kernel-test scripts
that this patch is based on! I ended up modifying them quite a bit to
fit the docker use case, and to build the initrd (so we can use the
stock debian kernel).
Related: OS#3208
Change-Id: I54e752048eed2a170a1cf4e0fd410de255b9de5d
We previously only allocated IPv4 sub-nets to the network segments
created with 'docker network'. Let's fix that by assigning both
IPv4 and IPv6 address ranges to each docker network.
Related: OS#4700
Change-Id: I8802208fddcce1ffa57e5626575d23d02b320d99
Previously we were using 178.18.12.0/24 which could have conflicted with
the osmo-bsc sccplite TTCN3 tests.
Change-Id: Ib5ab391ebb21ce2455fbb1ae47dd01ed53cd2e41
Change default from osmo-interact-vty.py to osmo_interact_vty.py, which
is the name of the script in osmo-python-tests.git.
Check if that script is in PATH before building and running the docker
container.
Change-Id: I763c7379b710160e0155f1fde091137754141335
The osmo-nitb-master image can run not only osmo-nitb, but also
osmo-bsc_nat. In that case we can't use the default command from
Dockerfile, but should provide our own. This argument makes it possible
to do so.
Change-Id: I52c3cb2cdcfb143e71ac2c1aa40bb466e41a0f5c
Related: OS#1700
This script needs access to the VTY interface, so I changed some
remaining config files to bind the VTY interface to 0.0.0.0.
There are a couple of services that do that already.
Related: OS#1700
Change-Id: Ic5cf7f59de0c18d4c5568b89433c2b11db2a72a5
Oliver Smith
Harald Welte
Daniel Willmann