Anthony PERARD [Thu, 22 Jun 2023 09:09:18 +0000 (09:09 +0000)]
ts-xen-build-prep: force use of git protocol v2
Recent version of QEMU (to be 8.1) started to use meson subproject to
clone extra repo. With the example of the subproject "dtc", they do a
shallow clone with a sha1. Meson end up running:
This command fails. I think the error message is something like "the
remote end hung up unexpectedly", on Debian Buster. A more useful
message with more recent version of git seems to be "couldn't find
remote ref".
If we allow git to communicate with the protocol v2, then the shallow
clone works. But git on buster still use v1 by default. Force it to
use v2.
This needs a git-cache-proxy version that can allow to switch to v2 of
the protocol. A bug is open upstream to track this change:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040476
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Anthony PERARD [Mon, 19 Jun 2023 14:37:14 +0000 (14:37 +0000)]
Use updated mirror for buster armhf, and update debian-installer
This reverts commit b838a9daeb3b ("production-config: Use a snapshot
for buster armhf")
Installation now fails with "Invalid Release signature", while
downloading the "Release" file of a repo.
But, using the main mirror for armhf boxes seems to work fine now.
To use the live mirror, we need to update the debian-installer as
there's a newer version of the kernel. Otherwise, installation fails
with the installer not able to find the disk.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Anthony PERARD [Mon, 22 May 2023 13:54:48 +0000 (13:54 +0000)]
ts-xen-build-prep: Install python3-venv for QEMU
Since QEMU commit 81e2b198a8cb ("configure: create a python venv
unconditionally"), a python venv is always created and this new package
is needed on Debian.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Current usage of Werror=switch-enum by default for libvirt builds out
of the git tree causes issues when new items are added to libxl public
API enums if those are used in a switch statement in libvirt code.
This leads to libvirt build failures for seemingly unrelated libxl
changes.
In order to prevent those errors from blocking the push gate, disable
Werror for libvirt builds when not in a libvirt specific flight.
The errors will be reported on the libvirt flight, and block the
pushes there. So the author of the changes in libxl is still expected
to send a fix to libvirt code. This is no ideal, but the other option
is to just disable Werror for all libvirt builds and let libvirt
developers fix the breakage when they notice it.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Changes since v1:
- Use -Dwerror=false instead of -Dgit_werror=disabled
--- Cc: Ian Jackson <iwj@xenproject.org> Cc: Anthony PERARD <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org>
Anthony PERARD [Thu, 19 May 2022 10:55:25 +0000 (11:55 +0100)]
ts-xen-build-prep: Install newer NASM version, to build OVMF
Recent versions of OVMF now need a version of NASM that is newer
than the one available on Debian oldstable/buster. They want to use
NASM 2.15.05 [1], which is available in Debian stable/bullseye. The
need to use a newer version started with d3febfd9ade3 ("MdePkg:
Replace Opcode with the corresponding instructions.").
There is no backport package available but the nasm package from
Debian Bullseye can easily be installed on Buster as it has few
dependencies and are already satisfied.
Or else all interrupts will get bound to (v)CPU 0.
This doesn't cause issues on small boxes, but boxes with a non-trivial
amount of CPUs can struggle without interrupts being balanced across
available vCPUs, as the number of vCPUs offered to dom0 matches the
number of physical CPUs.
For example sabro boxes (Xeon Silver 4114 x 2 sockets) would sometimes
report timeouts which seem to be solved by using irqbalance in dom0.
irqbalance is also available on Arm, so install unconditionally.
Reported-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Just disabling cron in rc.d is not enough. There's also anacron which
will get invoked during startup, and since apt-compat has a delay of
up to 30min it can be picked up by the leak detector if the test
finishes fast enough:
To prevent this disable anacron like it's done for cron.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Changes since v1:
- Don't fail if the service is not present.
Ian Jackson [Tue, 14 Dec 2021 14:51:05 +0000 (14:51 +0000)]
daily-cron-email-real-*: Temporarily drop osstest-admin
Roger has agreed to take on osstest admin for the moment. Someone who
intents to take on the role long term will probably want to get CC's
of these flight reports, but it's fairly noisy. So for now, send them
only to the lists.
Signed-off-by: Ian Jackson <iwj@xenproject.org> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Roger Pau Monne [Thu, 25 Nov 2021 15:06:46 +0000 (16:06 +0100)]
ts-xen-install: enable timestamp on guests logs
Enable the timestamp feature of xenconsoled so guests logs have a time
reference. Can be helpful when debugging boot related slowness.
This requires using the XENCONSOLED_ARGS option and setting both the
log and the timestamp options. Note that setting XENCONSOLED_TRACE
will override any options in XENCONSOLED_ARGS, so they can not be used
in conjunction.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Ian Jackson <iwj@xenproject.org>
Ian Jackson [Fri, 22 Oct 2021 15:21:27 +0000 (16:21 +0100)]
examination: skip memdisk on non-BIOS hosts, run per-firmware on x86
This is a combination of two changes:
ts-memdisk-try-append: skip memdisk test on non-BIOS hosts
make-flight: examine: Insist on -bios and -uefi tests on x86
This will let us skip ts-memdisk-try-append on non-bios platforms
without risking regression. It will also definitely spot
regressions which will occur on any uefi host.
standalone-generate-dump-flight-runvars reveals the changes are as
follows:
New jobs
test-amd64-i386-examine-bios test-amd64-i386-examine-uefi
test-amd64-amd64-examine-bios test-amd64-amd64-examine-uefi
added everywhere that has the corresponding plain job, namely
osstest
linux-*
xen-unstable
These jobs are just like the plain jobs, except that one of
,PropEq:Firmware:bios:bios
,PropEq:Firmware:bios:uefi
has been added to the end of all_hostflags.
Signed-off-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
Ian Jackson [Wed, 24 Nov 2021 14:34:47 +0000 (14:34 +0000)]
mg-repro-setup: Make ordinary alloc: work again
In e7febe5f6edc, we hosted an error earlier in the script. But in the
old location, OSSTEST_TASK would always be set if statictask was. In
the new one, that hasn't been done yet.
No release implications since it touches a by-hand utility only.
Fixes: e7febe5f6edc "mg-repro-setup: Promote an error test to before builds (nfc)" CC: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
Ian Jackson [Mon, 22 Nov 2021 11:51:01 +0000 (11:51 +0000)]
allow.all: Treat freeBSD memdisk-try-append failures as nonblocking
In practice this currently fails on some of our hosts. We don't seem
to have resources to investigate properly, and this will be blocking
recomissioning of hosts if we don't get it out of the way.
Signed-off-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Ian Jackson [Wed, 27 Oct 2021 10:53:50 +0000 (11:53 +0100)]
ts-xen-build: Pass --enable if --disable found in usage, and v.v.
The existing code works in practice if the usage message always lists
the non-default, since the unlisted-in-usage options that would be
supported, but are elided, are in any case the default.
But configure might *compute* its defaults. In which case it will
list only one of them in the usage message. If the computed default
is not the same as the usual default (the one implied by listing the
opposite in the usage message) we would wrongly not pass the option.
So grep for both enable and disable.
Signed-off-by: Ian Jackson <iwj@xenproject.org> Reviewed-by: Juergen Gross <jgross@suse.com>
Juergen Gross [Tue, 26 Oct 2021 13:56:45 +0000 (15:56 +0200)]
osstest: explicitly set either enable or disable qemu-traditional
Instead of setting "--enable-qemu-traditional" or not, switch to
setting "--enable-qemu-traditional" or "--disable-qemu-traditional".
This avoids a latent bug in the disable case, as the availability
of the option is tested via grep, which will otherwise grep for
nothing.
Reported-by: Ian Jackson <iwj@xenproject.org> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <iwj@xenproject.org>
Ian Jackson [Thu, 9 Sep 2021 15:46:27 +0000 (16:46 +0100)]
fmtarches: Use dom0arches, not hardcoded arch list
This will make us reallocate fmt tests when the arch list changes.
It's not ideal because it means tests jumping about across arches and
might let regressions go through but it's better than just dropping
them, and doing a better approach is complex.
Ian Jackson [Thu, 19 Aug 2021 12:46:21 +0000 (13:46 +0100)]
make-flight: Drop pvgrub (pvgrub1) tests
This is obsolete. In 2017 in 6abb2f113025 we wrote:
A consequence is that this test will test jessie forever. Eventually
jessie will rot so badly that this test fails and then we will no
longer be testing pvgrub1. Hopefully by then no-one will be using it.
This has now occurred.
I have verified with
OSSTEST_CONFIG=standalone-config-example eatmydata ./standalone-generate-dump-flight-runvars
that the only change is to drop jobs test-amd64-amd64-*-pvgrub.
CC: Jan Beulich <jbeulich@suse.com> CC: Juergen Gross <jgross@suse.com> CC: Jan Beulich <jbeulich@suse.com> Signed-off-by: Ian Jackson <iwj@xenproject.org>
Now (postgresql 11) start_value is in a different table. We don't
really care about it very much and mostly care about the last value,
so we fix that (and launder the for-db comparison dumps).
* psql transaction behaviour has changed so that now we want to
use the -1 option. This obviates a few BEGIN and COMMITs.
* SET implicitly starts a transaction and DROP and CREATE DATABASE
aren't transactional and now complain if they are run in a
transaction. So we must add COMMIT after SET.
Ian Jackson [Wed, 10 Feb 2021 16:41:12 +0000 (16:41 +0000)]
Disable updates for ssapshot.debian.org
security updates are a separate apt source.
The point of using snapshot is to avoid pulling in uncontrolled
updates, so we need to disable security updates.
The non-security SUITE-updates are disabled by this too. But
everything is on fire and I don't want another iteration while I
figure out the proper syntax for disabling only the security updates.
Ian Jackson [Tue, 9 Feb 2021 13:03:32 +0000 (13:03 +0000)]
mg-debian-installer-update: Honour redirect for dtbs
When using snapshots, we can get a redirect and then we don't
recurse. There doesn't seem to be a suitable option for wget, so do
this by hand before we call wget -m.
Ian Jackson [Fri, 22 Jan 2021 15:11:01 +0000 (15:11 +0000)]
make-flight: Stripy xenstored
Previously, we let the Xen build system and startup scripts choose
which xenstored to use. Before we upgraded to Debian buster, that
gave us C xentored tests on ARM. Since then, armhf and arm64 have
both had enough ocaml support and we haven't been testing C xenstored
at all !
Change this, by selecting between C xenstored and Ocaml xenstored
"at random". Actually, this is based on the job name. So the same
job in different branches will use the same xenstored - which helps
avoid confusion.
I have diffed the output of standalone-generate-dump-flight-runvars.
As expected, this addes a variable all_host_xenstored to every job.
To make sure we have enough diversity, I eyeballed the results. In
particular:
* The smoke tests now have 2 C and 2 Ocaml, one of each on
ARM and x86.
* XTF tests have 2 oxenstored and 3 C xenstored.
* The ovmf flight has one of each
* The seabios and libvirt flights look reasonably mixed.
Most other flights have enough jobs that I think things are diverse
enough without looking at them all in detail.
I think this lack of testing needs fixing for the Xen 4.15 release.
So after review I intend to push this to osstest pretest, and may
force push it even if shows regressions.
CC: Edwin Török <edvin.torok@citrix.com> CC: Andrew Cooper <Andrew.Cooper3@citrix.com> CC: Jürgen Groß <jgross@suse.com> CC: Wei Liu <wl@xen.org> Signed-off-by: Ian Jackson <iwj@xenproject.org> Release-Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
Ian Jackson [Thu, 19 Nov 2020 16:55:48 +0000 (16:55 +0000)]
sg-report-flight: Actually look at retest flights (part 2)
To avoid going down ratholes (especially for jobs which reuse outputs
from their previous selves), the primary flight/job finder in
sg-report-flight does not recurse indefinitely through build jobs.
Instead, it restricts the build jobs investigated to those within the
same flight as the job which might be of interest.
As a result, retest jobs are, unfortunately, discarded at this stage
because we insist that the build jobs we find did use the tree
revision we are investigating.
Fix this by recursing into the corresponding primary flight too.
In the $flightsq->fetchrow loop that's $xflight.
For the primary flight, ie the first half of the UNION, that's just
the fligth itself. So there this has no change.
For the retest flights, it is the flight that all the build jobs refer
to. Despite the CROSS JOIN, this will be unique for any particular
"retest flight", because the query on the runvars insists that all of
the (at least some) buildjob runvars for f1 point to f0. Ie, f1 has
no build jobs and refers to f0 for build jobs; so it can't refer to
any other f0' in the cross join.
With this change, a -retest flight can now actually be used to justify
a push.
Ian Jackson [Thu, 19 Nov 2020 16:24:32 +0000 (16:24 +0000)]
sg-report-flight: Actually look at retest flights (part 1)
The existing approach does not find retest flights. This is because
it starts by looking for flights whose runvars say they built the
version in question, and then looks to see if they contain the
relevant job.
Retest flights don't contain build jobs; they reuse the builds from
the primary flight.
Rather than making a fully general recursion scheme (which would
involve adding another index so we could quickly find all flights
which refer to this one), we add a one-level recursion.
This recursion is restricted to the flights named on the command line.
This means it takes nearly no time (as opposed to searching the whole
db for things that might be relevant - see above re need for an
index).
We filter the command line flights, looking ones which refer to the
only the primarily found flights as build jobs.
Ian Jackson [Fri, 13 Nov 2020 17:34:32 +0000 (17:34 +0000)]
cr-daily-branch: Sort out retest build reuse
Retest flights ought to reuse precisely the builds from the flight
which prompts the retests.
mg-adjust-flight-makexrefs is the wrong tool for this job. It can
often leave the retry flights with no build jobs and no references to
the main flights' build jobs, so the results are just broken jobs.
Ian Jackson [Fri, 23 Oct 2020 16:08:02 +0000 (17:08 +0100)]
host reuse fixes: Properly clear out old static tasks from history
The algorithm for clearing out old lifecycle entries was wrong: it
would delete all entries for non-live tasks.
In practice this would properly remove all the old entries for
non-static tasks, since ownd tasks typically don't releease things
until the task ends (and it becomes non-live). And it wouldn't remove
more than it should do unless some now-not-live task had an allocation
overlapping with us, which is not supposed to be possible if we are
doing a host wipe. But it would not remove static tasks ever, since
they are always live.
Change to a completely different algorithm:
* Check that only us (ie, $ttaskid) has (any shares of) this host
allocated. There's a function resource_check_allocated_core which
already does this and since we're conceptually part of Executive
it is proper for us to call it. This is just a sanity check.
* Delete all lifecycle entries predating the first entry made by
us. (We could just delete all entries other than ours, but in
theory maybe some future code could result in a siutation where
someone else could have had another share briefly at some point.)
This removes old junk from the "Tasks that could have affected" in
reports.
Ian Jackson [Thu, 22 Oct 2020 14:38:12 +0000 (15:38 +0100)]
starvation: Do not count more than half a flight as starved
This seems like a sensible rule.
This also prevents the following bizarre behaviour: when a flight has
a handful of jobs that cannot be run at all (eg because it's a
commissioning flight for only hosts of a particular arch), those jobs
can complete quite quickly. Even with a high X value because only a
smallish portion of the flight has finished, this can lead to a modest
threshhold value. This combines particularly badly with commissioning
flights, where the duraation estimates are often nonsense.
Ian Jackson [Thu, 22 Oct 2020 14:02:18 +0000 (15:02 +0100)]
host reuse fixes: Do not break host-reuse if no host allocated
If host allocation failed, or our dependency jobs failed, then we
won't have allocated a host. The host runvar will not be set.
In this case, we want to do nothing.
projects / osstest.git / log