Ian Jackson [Thu, 2 May 2019 15:59:16 +0000 (16:59 +0100)]
mg-repro-flight: Provide --rebuild to make variant build jobs too
This allows a single command to repro a particular job with a variety
of different source code.
The implementation technique is:
- run the build job in a separate flight, so that it can run
with a separate task which gives its host up after the build
- do much of the heavy lifting of runvar fiddling etc. in
a new helper routine in cs-adjust-flight
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: Add a missing `continue' (without which everything goes quite wrong)
Ian Jackson [Wed, 1 May 2019 10:43:08 +0000 (11:43 +0100)]
Drop Xen 4.5 and earlier
These releases are out of security support. They are known not to
build on Debian stretch, which is what we are using, and we do not
intend to ever update them to fix that.
Xen 4.6 is also out of security support but we want osstest to be able
to continue to build it so that we can test 4.6->4.7 migration, for
the purposes of testing Xen 4.7, which is still supported right now.
So we have recently applied some build fixes to the 4.6 tree, and for
now we retain 4.6 in osstest so that build fixes applied to
staging-4.6 can propagate to stable-4.6.
CC: committers@xenproject.org Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 26 Apr 2019 14:58:47 +0000 (15:58 +0100)]
cross builds: Build armhf kernels on amd64 hosts
Our armhf hosts are devboards and very slow, as well as scarce. It
takes 17ks or so for a kernel build. This will go *much* faster on
an amd64 box and we have lots of those too.
standalone-generate-dump-flight-runvars shows that the only change is
to change host_arch from armhf to amd64 in build-armhf-pvops jobs.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> CC: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Julien Grall <julien.grall@arm.com>
---
v2: Fix typo in commit message.
Ian Jackson [Fri, 26 Apr 2019 14:22:55 +0000 (15:22 +0100)]
cross builds: mfi-common: Prepare for kernel cross building
Introduce job_create_build_crossable, which takes a target->host
architecture map in its arguments, and use it for build-kern,
passing an empty architecture map.
Overall functional change is only to add
host_arch=$arch
to the kernel build jobs, which has no ultimate effect because it's
the same as the arch=$arch. (Difference in flight construction
verified with standalone-generate-dump-flight-runvars.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 26 Apr 2019 13:44:04 +0000 (14:44 +0100)]
arch replumbing: ts-debian-di-install: Use $gho->{Arch}
This is just tidying up. The only effect is that now these would
honour $r{all_guest_arch} as a fallback. But right now,
$r{GUEST_arch} will always be set, and that is what ends up in
$gho->{Arch}.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This comment was lamenting the very problem we are fixing now. It
would now be possible to test i386->amd64 tools migration, by writing
an appropriate test job with different src_host_arch and
dst_host_arch etc.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 26 Apr 2019 13:27:12 +0000 (14:27 +0100)]
arch replumbing: Replace many $r{arch} with $[g]ho->{Arch}
No functional change with existing flights. But the effect is that
now, generally, ts-* scripts and the support code will honour
host_arch, if it is set, in preference to arch.
This patch contains only replacements of $r{arch} with $ho->{Arch} or
$gho->{Arch}. In fact, perhaps surprisingly, there were no locations
where $gho was wanted rather than $ho (I have double checked this).
Exceptions, where we left $r{arch} alone, are:
* make-flight: a comment, which we are about to deal with;
* ts-kernel-build: we are going to support cross building and
$r{arch} is going to be the architecture of the kernel we want
rather than of the build host.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 26 Apr 2019 13:07:08 +0000 (14:07 +0100)]
TestSupport: target_var: Use host_V for host variables
Change `target_var' to set `IDENT_V' rather than just V. For
compatibility with older flights and older flight construction,
look for plain V too when looking up the variable.
And, we now look at all_host_V before V. This has no functional
change with existing flights, because existing flights only have
all_host_suite
all_host_di_version
all_host_os
and we never set the corresponding V form of those variables.
So with existing flights the only functional change is a change to
synth runvars, to add HOST_ to the name.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 16 Apr 2019 14:30:29 +0000 (15:30 +0100)]
starvation: Abandon jobs which are unreasonably delaying their flight
Sometimes, due to a shortage of available resources, a flight might be
delayed because a handful of jobs are waiting much longer than the
rest. Add a heuristic which causes these jobs to be abandoned.
We consider ourselves starving if we are starving now, based on the
most optimistic start time seen in the last I.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Wed, 18 Jul 2018 12:21:27 +0000 (13:21 +0100)]
starvation: Infrastructure for jobs which are delaying their flights
Provide hostalloc_starvation_* in Osstest::Executive, and a comment
saying what we are going to do. And provide a demo utility which
prints the effect of some particular runvar value on a range of
situations.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Wed, 18 Jul 2018 12:20:39 +0000 (13:20 +0100)]
starvation: Use "starved" for hostalloc_maxwait_max
Previously this was "broken".
We mustn't just call `broken' inside attempt_allocation because that
runs in a db transaction. Instead, we arrange that attempt_allocation
returns 2, which threads its way back out to the return value from
alloc_resources, and then call broken there.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Tue, 16 Apr 2019 10:51:16 +0000 (11:51 +0100)]
tcl/JobDB-Executive: Do not squash "starved" status
ts-hosts-allocate is going to set the job status to `starved'
sometimes, and then die. `starved' needs to be added to the list of
job statuses that sg-run-job leaves alone.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 16 Apr 2019 17:46:42 +0000 (18:46 +0100)]
step handling: Preserve step states set by ts-* scripts
sg-run-job would unconditionally set the step state to the value it
calculated, which would usually be `pass' or `fail' or
`broken' (according to the recipe).
Relax this interface somewhat to allow a test script to set the step
status itself: specifically, do not overwrite an existing status of
aborted broken starved
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Thu, 18 Apr 2019 16:18:53 +0000 (17:18 +0100)]
starvation: Teach archaeologists about starved job state
sg-report-flight is a bit awkward. It thinks mostly about step
status, not job status. So, when justifying, if we don't find a step,
and the job state is starved, we treat the step as starved.
If there are only starved steps, then we don't have evidence that this
is a regression, because the test wasn't run in the baseline.
If there are other steps we look at those instead.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Thu, 18 Apr 2019 12:17:50 +0000 (13:17 +0100)]
starvation: Teach sg-report-flight about starved step state
We are going to use this for situations where the resources to run the
test weren't available. In general we are going to treat this as not
a regression.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 20 Jul 2018 15:11:37 +0000 (16:11 +0100)]
alloc_resources: Support special abandonment values
This gives a way for the caller's $resourcecall to signal something
interesting, back to its main loop. This is useful for calling
broken, for example: that can't be done within $resourcecall because
$resourcecall operates within the allocation db transaction (which
ought to be rolled back...)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Thu, 25 Apr 2019 15:04:56 +0000 (16:04 +0100)]
builds: Run i386 builds on amd64 kernels
Most hardware that supports i386 supports amd64 too. When doing
builds we do need the right userland, but we don't actually care what
the kernel is doing. With Linux 32-on-64 is good for that.
Especially, there is a kernel regression (evident in the Debian
stretch kernel, but not present in jessie's) where 32-bit Linux
mismanages the memory on hosts with moderately large amounts of
RAM (ie, significantly more RAM than can be addressed at once),
resulting in what amounts to a near-stall of the paging system. Since
the paging system is used for filesystem writes too, the effect is
that commands run by builds can take totally unreasonable amounts of
time. Ie, this version of Linux is broken when i386 PAE is needed.
In practice this is causing significant trouble in the Xen Project CI.
This kernel bug probably won't affect our test jobs because
(i) we use our own kernels, so we would probably detect this
regression when switching kernel branches etc. (ii) test jobs
run with a dom0_mem setting which avoids the preconditions for the
particular bug.
CC: Juergen Gross <jgross@suse.com> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com> CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Thu, 25 Apr 2019 14:58:00 +0000 (15:58 +0100)]
Debian: preferred arch: Apply setarch to sshd
Many build systems (including Xen's, and autoconf) use uname to try to
discern the system's architecture. When running i386 userland on an
amd64 kernel, this gives the wrong answer. These build systems then
go off and try to do a sort of cross compile thing, and, generally,
fall over.
The uname -m value (which is what is at issue) is an inherited process
property. Linux provides a utility `setarch' which changes this. We
need to apply this to all builds; and it is not really convenient to
add an adverbial command to every build via the existing ssh build
shell rune mechanisms.
A fairly simple way to get the right behaviour is to wrap sshd
instead. sshd doesn't mind what `personality' it sees. Replacing
/usr/bin/sshd with a wrapper shell script might break
start-stop-daemon's attempts to shut down or restart sshd but we don't
care about that in osstest (certainly not on build installs, where
this feature is to be used).
Nothing uses this yet.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Thu, 18 Apr 2019 11:18:10 +0000 (12:18 +0100)]
cr-daily-branch: ovmf: "usually" use xen-tested-master
This branch is supposed to be suitable for all versions of Xen.
Conversely, older versions of OVMF do not build on newer compilers (as
provided, eg, in stretch).
So, for "branches" other than xen-unstable and xen-unstable-smoke, use
the usual "determine_version" machinery, which will select
xen-tested-master for branches other than the ovmf branch itself.
No change for the ovmf "branch", nor for xen-unstable*. The effect is
to switch xen-*-testing, qemu-*, linux-*, etc., to all use ovmf
xen-tested-master.
Verified with standalone-generate-dump-flight-runvars. In detail:
In these flights:
examine freebsd-master libvirt linux-*
osstest qemu-* seabios xen-4.* xtf
in these jobs
build-amd64
build-arm64
build-armhf
build-i386
change
revision_ovmf to the output of ./ap-fetch-version-baseline ovmf
tree_ovmf to git://xenbits.xen.org/osstest/ovmf.git
(each being previously set to the empty string).
Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Wed, 17 Apr 2019 16:14:41 +0000 (17:14 +0100)]
Debian: Work around Debian stretch bug with disk device names
The Debian stretch i386 installer does not have Xen PV-on-HVM drivers.
When we run the HVM guest installer, it therefore sees /dev/sda (the
emulated IDE). But the booted system *has* the drivers and sees
/dev/xvda.
The Debian installer is supposed to put UUID= in the bootloader config
and so on in the installed system. However, this does not work due to
a bug (Debian #852323). Work around it.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Wed, 17 Apr 2019 14:05:32 +0000 (15:05 +0100)]
ts-debian-hvm-install: Use ---, and no longer duplicate $gconsole
In October 2014, debian-installer was updated to honour `---' in the
way it previously honoured `--': #762007. If we use that instead,
we don't need to duplicate $gconsole any more.
In principle this ought to be changed only in "recent enough" Debian
suites, but certainly at least jessie has the fix and jessie is quite
broken now, so let's not bother with making it conditional.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 16 Apr 2019 18:33:35 +0000 (19:33 +0100)]
debianhvm tests: Re-permute guest architecture
Firstly, change the smoke flight to use amd64, not i386.
Secondly, make the other flights have a mixture of i386 and amd64, not
just amd64.
It was always wrong to test only one guest architecture in the main
flights.
The context for changing the smoke flight is that there seems to be a
problem affecting Debian i386 guests. This is rather a nuisance but
it is not a Xen regression so we probably want to do an amd64 guest
instead so we have some HVM tests in the smoke flights.
Checked with standalone-generate-dump-flight-runvars. Differences
are as follows:
1. Generally, to change the guest arch from amd64 to i386 in:
In all cases, this implies a variety of changes to runvars, including
the ISO to be used, the install timeout, etc.
Usually I would introduce new jobs first, and then, after an overlap,
remove old ones. But the regression, due to the i386 hvm stretch
problem, is already with us.
I expect this change to unblock the xen-unstable-smoke flights by
dropping the failing job and replacing it with a passing one.
The other flights will now start to fail, though. I will need,
separately, to develop a workaround for the stretch i386 hvm guest
bug.
CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Juergen Gross <jgross@suse.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Mon, 15 Apr 2019 11:46:09 +0000 (12:46 +0100)]
ts-host-install: Do not force MAC address of Xen vifs
For some broken hosts we explicitly force the mac address in
software. (This is controlled by the ForceMacAddress host property.)
We achieve this by writing a udev rule (which ends up both in the
installer and in the initramfs) which calls `ip link set ... address'.
However: in some cases we share the initramfs with guests. In
particular, the `xen-tools' package likes to use the host initramfs.
In stretch at least, this rule, empirically, applies in the guest too.
The result is that with ForceMacAddress, the guest ends up with the
same mac address as the host, breaking everything.
Fix this by explicitly excluding Xen network interfaces. These all
get a proper mac address from xenstore (ultimately, from osstest
itself via the guest config, or in other configurations from libxl).
I don't know why this apparently worked on jessie. Startup order
changes are a possibility.
CC: Julien Grall <julien.grall@arm.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 9 Apr 2019 16:52:58 +0000 (17:52 +0100)]
Debian: Fix /lib/udev/ifupdown-hotplug in guests from debootstrap
The ifupdown-hotplug problem just described affects guests too.
Empirically, this occurs only with the guests from xen-tools. In my
osstest stretch series development tests this resulted in occasional
failures of ts-guest-start. The problem is not deterministic; and it
may be that it is a race between the guest's random dhcp retry and
osstest's timeout, or something. The race affected both x86 and ARM.
I conjecture that it only affects xen-tools created guests because
those guests use sysvinit. Presumably the other guests have systemd
which has some different ordering. I conjecture that the sysvinit
boot arrangements were damaged by some changes made in stretch to
shared components (udev, probably) to support systemd.
An alternative explanation for seeing the failure only with xen-tools
created guests might be that all guests are affected, but only
xen-tools created guests are booted with a short timeout; whereas the
d-i created ones have a long timeout for firstboot at least. I don't
believe this theory because all guests are restarted with
ts-guest-start and a short timeout.
So: in ts-debian-fixup, execute the sed rune to fix
/lib/udev/ifupdown-hotplug. This then happens before first boot.
Debian guests installed via d-i are not affected by this patch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 9 Apr 2019 16:43:33 +0000 (17:43 +0100)]
Debian: Fix /lib/udev/ifupdown-hotplug to not run if / is ro
Empirically, without this, on Debian stretch:
1. udev starts before / is remounted rw
2. udev spots eth0 and runs /lib/udev/ifupdown-hotplug
3. ifupdown-hotplug runs ifup which runs isc-dhcp-client
4. isc-dhcp-client talks to the dhcp server to get an address
5. isc-dhcp-client tries to write the lease and run the hook
scripts but something here fails with EROFS
6. isc-dhcp-client sends DHCPDECLINE to the server
7. GOTO 4
This loop continues for several seconds, until / is remounted rw.
None of this is appears in any of the guest's logs because syslog is
not running yet, and none of this stuff goes to the console either.
But it does appear in the dhcp *server* logs so that a conscientious
administrator will suffer consternation and concern.
It is not ever sensible to run /lib/udev/ifupdown-hotplug with /
mounted ro. (Maybe it is not sensible to run udev so early.)
Skipping it is fine because the boot sequence contains an explicit
call to ifup which occurs *after* / is remounted, and that will
collect any interfaces which were skipped earlier.
In my osstest stretch series development tests I don't think I saw any
actual host install failures due to this situation. The timeouts are
generous enough not to matter, and of course when we install Xen we
reconfigure the host networking to have a static IP address so then
the problem goes away.
In this patch we do this for the host. We provide a function to
return the appropriate rune which we will use in a moment.
I have not yet reported this situation to the appropriate Debian
channels. That's on my backlog. But in any case I have limited the
workaround to stretch so we will revisit this for buster.
The approach to fixing this is somewhat awkward.
Firstly, since the bug is in /lib/udev/ifupdown-hotplug we want to
edit that script. But we need to do it in the installer environment
as a late_command, because after first boot, via ssh, is too late.
The installer environment has no `patch'. I didn't want to just
supply a whole new script. So instead we use sed and mv.
Secondly, as for the contents of /lib/udev/ifupdown-hotplug: I wasn't
able to think of a convenient shell command which will tell us the
errno value from trying to write a file. Plenty will print the
strerror but I balked at LC_MESSAGES=C and grep. Perl, however, can
do this, and is always available on Debian. So perl it is.
Thirdly, the code has a bad case of toothpicks (lots of \), because it
needs to pass through (i) perl (ii) the shell (iii) sed's regexp
syntax and/or i command.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 5 Apr 2019 15:33:11 +0000 (16:33 +0100)]
ts-xen-install: Install libpciaccess0
In "ts-xen-build-prep: install packages for suites >jessie",
libpciaccess-dev was added for the benefit of qemu. libvirt needs it
too.
We also need the runtime library. Without it, libvirt does not start:
2019-04-04 22:35:36.760+0000: 3623: error : virModuleLoadFile:53 : internal error: Failed to load module '/usr/local/lib/libvirt/connection-driver/libvirt_driver_nodedev.so': libpciaccess.so.0: cannot open shared object file: No such file or directory
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
In
dm restrict audit: install newer chiark-scripts for fishdescriptor
arrangements were made to install suitable chiark-scripts for
for jessie and stretch.
For buster and later, the mainline Debian version of chiark-scripts is
indeed sufficient, but nothing installed it. Do that.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 5 Apr 2019 13:55:53 +0000 (14:55 +0100)]
dm restrict audit: actually install fishdescriptor in host
In
dm restrict audit: install newer chiark-scripts for fishdescriptor
arrangements were made to install a backport of chiark-scripts
but the code was mistakenly placed in preseed_create_guest but
of course it's needed in the host.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 5 Apr 2019 13:04:26 +0000 (14:04 +0100)]
dm restrict audit: actually install right package for fishdescriptor
In
dm restrict audit: install newer chiark-scripts for fishdescriptor
a locally-provided chiark-scripts_6.0.2_all.deb was installed for
jessie. For stretch a backport was installed, but mistakenly
of chiark-utils-bin rather than chiark-scripts.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 5 Apr 2019 12:31:07 +0000 (13:31 +0100)]
Debian: set partman-lvm/device_remove_lvm_span
Web searching[1] suggests that this suppresses this error:
!! ERROR: Unable to automatically remove LVM data
Because the volume group(s) on the selected device also consist of
physical volumes on other devices, it is not considered safe to
remove its LVM data automatically. If you wish to use this device
for partitioning, please remove its LVM data first.
It doesn't, though. I am only experiencing it now because the ad-hoc
disk-erasing (25erase-other-disks) is broken for other reasons. But
let's have it anyway as it sounds like a thing we might want.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 5 Apr 2019 12:24:52 +0000 (13:24 +0100)]
Debian: partman scripts: Run right away too
We are switching the installation of these to partman/early_command
which runs as a result of a /lib/partman/init.d hook. That means that
things we install don't get picked up, so run them right away (too).
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 2 Apr 2019 15:24:08 +0000 (16:24 +0100)]
preseed_base: chmod ssh host private keys to placate sshd
Otherwise:
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for '/etc/ssh/ssh_host_ed25519_key' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_ed25519_key
This seems to start happening with stretch. Presumably stretch is
more annoyingly picky than jessie.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 30 Nov 2018 16:42:26 +0000 (16:42 +0000)]
TestSupport: target_somefile_leaf rename and change a variable
Rename this function. `getleaf' contains `get' which makes it sound
like the function copies something, or returns answers suitable for
getting, or something.
Also rename `$rdest' to `$rfile' since it might be a source too.
(Although we are not about to make it a source...)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Julien Grall [Fri, 30 Nov 2018 15:23:42 +0000 (15:23 +0000)]
ts-xen-build: Enable ITS driver in Xen
The ITS driver was added in Xen 4.10 as a technical preview feature.
However, it is required in order to boot Xen as Thunder-X because
PCI devices don't support legacy interrupt.
Ian Jackson [Thu, 29 Nov 2018 16:00:56 +0000 (16:00 +0000)]
persistent-net: Include initramfs script to copy to target
This is the piece which actually copies the installer's network names
to the target. It should not appear on the installed system, so it's
not in overlay-persistent-net.
Technically this is only useful when the installer has the
overlay-persistent-net in it, which is done only in ts-host-install
and not in all the places where setup_netboot_firstboot is used.
But without overlay-persistent-net it is harmless, and it is most
convenient to put it here.
The little script fragment was copied out of a jessie debian-installer
initramfs environment.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 27 Nov 2018 14:33:41 +0000 (14:33 +0000)]
persistent-net: Add overlay in installer >= stretch
We are going to need this in the installer so that the interface names
from the installer environment are captured so that they can be the
same on the host.
This prepares the ground for turning off net.ifnames. The actual
rules are gated on net.ifnames so right now there is no change.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
projects / people / iwj / osstest.git / log