When building our Debian boxes for buster, bullseye + bookworm (via
daily-build-matrix-debian-boxes Jenkins job), we get broken networking,
so e.g. `vagrant up debian-bookworm doesn't work.
This is caused by /etc/network/interfaces (using e.g. "neth0", being our
naming schema which we use in NGCP, as adjusted by the deployment
script) not matching the actual system network devices (like enp0s3).
TL;DR: no behavior change for NGCP systems, only when building non-NGCP
systems then enable net.ifnames=0 (via set_custom_grub_boot_options),
but do *not* generate /etc/udev/rules.d/70-persistent-net.rules (via
invoke generate_udev_network_rules) nor rename eth*->neth* in
/etc/network/interfaces.
More verbose version:
* rename the "eth*" networking interfaces into "neth*" in
/etc/network/interfaces only when running in ngcp-installer mode
(this is the behavior we rely on in NGCP, but it doesn't matter
for plain Debian systems)
* generate /etc/udev/rules.d/70-persistent-net.rules only when running
in ngcp-installer mode. While our jenkins-configs.git's
jobs/daily-build/scripts/vm_clean-fs.sh removes the file anyways (for
the VM use case), between the initial deployment run and the next reboot
the configuration inside the PVE VM still applies, so we end up with
an existing /etc/udev/rules.d/70-persistent-net.rules, referring to
neth0, while our /etc/network/interfaces configures eth0 instead.
* when *not* running in ngcp-installer mode, enable net.ifnames=0 usage
in GRUB to disable persistent network interface naming. FTR, this
change is *not* needed for NGCP, as on NGCP systems we use
/etc/udev/rules.d/70-persistent-net.rules, generated by
ngcp-system-tools' ngcp-initialize-udev-rules-net script also in VM
use case
This is a fixup for a change in git commit a50903a30c (see also commit
message of git commit ab62171), that should have been adjusted for
ngcp-installer-only mode instead.
Change-Id: I6d0021dbdc2c1587127f0e115c6ff9844460a761