On new Ubuntu 22.04 images, stopping systemd-resolved to get the dhclient script override resolv.conf doesn't work anymore. I originally used that hack to avoid introducing a delay which is needed when running it on TCG. Keep systemd-resolved running instead, and wait for it to be ready by retrying to resolve a domain a few times before installing packages, so that we don't add another ugly delay that might unnecessarily slow down things even further. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
We start getting prompts about restarting outdated services: we're using daily images but they might have been cached for a while now. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
We've recently converted most of our tests to use socat instead of nc/netcat/ncat, because socat is more powerful and we don't need to deal with the several possible variants of netcat. We still use nc or ncat for the distro tests. Because there we control the guest environment and can pick our tools, there isn't the same reason to switch to socat. However, using socat here as well makes the tests a bit easier to read, and doesn't require people reading or modifying them to become familiar with an additional tool. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: keep using netcat-openbsd in Ubuntu 16.04 ppc64 test, as socat is unavailable there] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Distribution packages reasonably expect to have a human-readable Markdown version of the README under /usr/share/doc/, but all we have right now is a heavily web-oriented version. Introduce a ugly hack to strip web-oriented parts from the current README and install it. It should probably work the other way around: a human-readable README could be used as a source for the web page. But cgit needs a file that's in the tree, not something that can be built, and https://passt.top/ is based on cgit. It should eventually be doable to work around this in cgit, instead. Reported-by: Benson Muite <benson_muite@emailplus.org> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
A couple of days ago, we started running out of space there as we're about to install gcc -- about 50 MiB are missing. Given that virt-resize (which could be conveniently invoked by the Makefile for tests) reorders partitions if we expand the first one, resize the image using qemu-img from the test script itself, and then take care of expanding root partition and filesystem online later. This is probably a temporary hack, so I'm not looking for a more generic or elegant solution at the moment. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
The Fedora test file extracts some information from the host resolv.conf into a DNS6 variable which is then never used. Remove this unnecessary step, which is presumably a leftover from an earlier iteration. This was the only user of 'head' and 'sed' in the test file, so those can also be removed from the required tools. The debian and ubuntu test files also listed 'head' and 'sed' as tools, although they don't use them, I'm guessing because of an earlier version which had the same DNS6 code. Remove those as well. The opensuse test file still actually uses DNS6, so leave it there for now. The DNS handling and network config handling for SuSE looks to be kind of broken, but fixing that is a job for another day. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Before booting the guest images, the distro test cases need to modify the guest images, using virt-edit and guestfish, to boot in the way we need. At present this gets repeated on every test run, even though it's not really doing anything we want to test for. In addition many of the images have the same preparation steps leading to a lot of duplicated stages in the tests. A number of additional images can be prepared using common steps, even if the ones used now have small differences. Therefore move the preparation of most of the guest images to the asset build phase, where they can be done a single time for multiple test runs, using a common preparation script. We can even avoid making a copy of the disk image for booting, by using qemu's -snapshot option. A few of the distros (openSUSE and older Ubuntu) do need different steps. For now we don't chage how they are run, they could possibly be handled more like this in future. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Rather than directly download distro images from the test scripts, handle all the downloads during the test asset build, then just clone them for the tests themselves. This avoids repeated downloads which can be very slow when debugging failing tests. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> [sbrivio: Add OPENSUSE_IMGS to DOWNLOAD_ASSETS in Makefile, and note that xzcat doesn't take a -O option in test/distro/opensuse] Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Apparently qemu's ARM virt machine needs to be explicitly given a firmware image, rather than just supplying a sane default. Unfortunately the EDK2 firmware image we need isn't in the same place on all host distros. Currently the test scripts hardcode the Debian location, meaning it will break on hosts that have it somewhere else. This patch searches multiple locations for the firmware, and creates a local link during the asset build phase, which the tests can then use. For now it only searches the locations used by Debian and Fedora, but that's a small improvement in robustness already, and can be later improved further if we need to. Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A lot of tests and examples invoke qemu with the command "kvm". However, as far as I can tell, "kvm" being aliased to the appropriate qemu system binary is Debian specific. The binary names from qemu upstream - qemu-system-$ARCH - also aren't universal, but they are more common (they should be good for both Debian and Fedora at least). In order to still get KVM acceleration when available, we use the option "-M accel=kvm:tcg" to tell qemu to try using either KVM or TCG in that order A number of the places we invoked "kvm" are expecting specifically an x86 guest, and so it's also safer to explicitly invoke qemu-system-x86_64. Some others appear to be independent of the target arch (just wanting the same arch as the host to allow KVM acceleration). Although I suspect there may be more subtle x86 specific options in the qemu command lines, attempt to preserve arch independence by using $(uname -m). Signed-off-by: David Gibson <david@gibson.dropbear.id.au>