The logic to detect disks via /proc/partitions didn't cover NVMe disks,
as the regex '[a-z]$' fails for the "nvme0n1" pattern:
| % cat /proc/partitions
| major minor #blocks name
|
| 259 0 500107608 nvme0n1
| 259 1 524288 nvme0n1p1
| 259 2 499582279 nvme0n1p2
| [...]
| 8 0 384638976 sda
| 8 1 384606208 sda1
Instead, let's use lsblk to detect present disks, which works
fine for all kinds of disks, incl. NVMe devices.
Change-Id: I586877da8b4fadf3d05b4e6c8e88bfdeae6d7f15
(cherry picked from commit f27f51c6c8)
Jobs like daily-build-matrix-debian-boxes build plain Debian machines,
not NGCP-based ones. At the moment we're generating the udev-rules for
network renaming unconditionally, so we have to do it consistently,
either both conditionally and not for "plain" systems, or both
unconditionally, so network can be brought up by a correct
/etc/network/interfaces after the devices are brought up with the new
names.
There is a good-ish argument for keeping using eth0, as it is more of a
default, but we're already deviating from the default for several years
and Debian stable releases by having these names and not ones like
"ens18" or "enp4s0f2" which is the default in Debian nowadays, at least
since buster.
So it is probably better to keep it consistent with our other machines
and use "neth*" naming for those too.
Change-Id: I6b3b49a1769894580df768abb817ae5196e65963
(cherry picked from commit a56c4454a3)
The code removed was enabled when $VAGRANT=true, and this happened when
passing "vagrant" parameter to deployment.sh, which is done in places
like proxmox-vm-clone job, the base of many of our tests machines.
VMs do not necessarily have the same hardware configuration, so removing
udev-rules for network devices makes sense in principle. Especially
when since the beginning we were using network devices named "eth*"
everywhere, even if in the last years we had to use net.ifnames=0 and
udev-rules files in hardware to keep using "eth*" names.
However, now with mr9.5 and the move to Debian bullseye we have to start
using different names, and we settled on the direct translation to
"neth*". So we need a way to assign whatever network devices the
machines come with, including VMs, to names "neth*".
(If we used the new-permanent device names like ens18 or enp3s0f1 we
would have to adapt network.yml and files like network interface, and
they would be different across all the different machines (HW and VM) so
this is not a better or faster solution to the problem.)
So, back to the topic of removal of this udev-rules file: in many cases
in our test infra, the machines are built "in place" and then rebooted
for upgrades or tests, in princicple with the same hardware
configuration, so there is no need to remove these files.
In cases where the underlying (virtualized) hardware changes, e.g. to
use like local VirtualBox-based vagrant machines, we will need to adapt
the rules for the existing devices.
Change-Id: I57e39a2ec6849f3b5bb8f6cf518e2a2923ec19cb
(cherry picked from commit eaecf474c2)
Using "eth*" names was discouraged for many years, we've been finding
problems here and there and working around them with the help of
udev-rules (/etc/udev/rules.d/70-persistent-net.rules) to map address
interfaces according to PCIIDs, using "net.ifnames=0" as Linux kernel
boot parameter when booting in GRUB, etc.
Finally we found unsurmountable problems when moving to Debian bullseye
(mr9.5), because as we attempt to rename interfaces in some hardware
systems that we use, we got race conditions and clashes with renaming
that we could not solve in other ways.
We had different alternatives:
- Use names purely deterministic, based on PCI paths (for example
"enp4s0f1"), MAC address or other of the alternatives, which would be
"definitive", but given that we have a diversity of hardware and VM
installations in customers the devices in different systems would be
different, and the fact that it would be easier to mistype or confuse
them makes this not ideal.
- Use names purely based on functionality, like for example "ha0",
"ext0" or "int0". The problem in this case is that we would have to
find names that would satisfy everyone (and there's no time for doing
this at this point), that different of our system types are quite
different (e.g. Pro without bonds, Carrier with bonds and many vlans
by default; using the same hardware), and some customers with
different installations or needs (e.g. using VMs) have also totally
different network configuration -- so any attempt to unify this to
make good use of the functionality-based names would be very
challenging.
- Finally, there's the option to use some symbolic names similar to
traditional names like "eth0", but without being exactly this.
Popular names in general, although there's no wide consensus, are
names like "net0" and "lan0".
Talking with groups involved in deploying and maintaining the system,
the decision was taken to move to names not purely deterministic, and
there's no time for purely symbolic (they also didn't express much
interest on them), and prefer something more traditional that they are
already used too. Instead of names like "net0" or "lan0", they prefer
the more direct mapping to existing interfaces like "neth0".
This is ugly or slighly discomforting to use for some, but since the
main users (among us) of these names prefer them, so be it. It has the
advantage of having a very simple and mechanichal translation based on
the current names, which is an advantage especially at the critical time
of upgrading existing systems to the new name.
Change-Id: I4a168c7d81e40f609749f77a509d2acb72d3a9d3
(cherry picked from commit 44750996be)
This is commit cd50e4934c applied again.
As explained in ab62171c49, the original
change had to be reverted because even if things work perfectly fine, in
the case of Vagrant machines (or when passing "vagrant" parameter to the
script) the udev-rules for persistent-net devices get removed, so then
the network interfaces get "random" names and the configuration in
/etc/network/interfaces doesn't match, the network is not brought up.
This removal happens in the case of {ce,pro,carrier}-trunk.mgm machines
of our tests, which shouldn't be needed, and also in the images created
for Vagrant machines, which is understandable because the machines could
be brought up with different PCIIDs in different versions of VirtualBox,
or due to some other difference -- not sure how we can ensure that the
PCIIDs as written in the udev-rules files will work in that case.
But in principle this change must go ahead when we solve these problems,
so submitting it again to be ready.
Change-Id: Ib39481a2608aa56e6ec6c9255e290787a6ce3af7
(cherry picked from commit a50903a30c)
Run the installer under "eatmydata" to speed up the process. Also add
some more information about timing.
In some VMs that we install daily ({ce,pro,carrier}-trunk.mgm) we have
the following timings:
ce-runner, no eatmydata:
162 seconds, 2 mins 42 secs
ce-runner, with eatmydata:
142 seconds, 2 mins 22 secs
pro-runner, no eatmydata:
246 seconds, 4 mins 06 secs
pro-runner, with eatmydata:
217 seconds, 3 mins 37 secs
So in these machines, for CE we save about 20 seconds, which is not much
in total but it's about 12.5% saving; and in Pro about 30 seconds (and
twice, once per machine, so about a minute in total), which is about
12.2% as well.
In Carrier, which is mostly equivalent to Pro in this respect and
typically at least 8 machines, it would mean about 4 mins in total.
When installing in hardware in previous days, maybe due to the disks
being slower, the total installation time was slightly slower:
pro-hardware (Lenovo ThinkSystem SR250), with eatmydata:
226 seconds, 3 mins 46 secs
Installing without eatmydata was not measured yet in hardware, but given
that the time to install is similar to the case of pro-runner, probably
the performance gain is similar too.
This looks like a relevant saving, the risk of things going wrong are
minimal, so enable it by default.
Change-Id: I8267fad08ff337c02801fb8fad0433d9b6d9f4c2
(cherry picked from commit d6b5097a86)
This reverts commit cd50e4934c.
In principle this works fine when using
/etc/udev/rules.d/70-persistent-net.rules, but it turns out that in the
test infrastructure (including {ce,pro,carrier}-trunk.mgm machines and
build-matrix) we remove the generated rules in many places:
if $VAGRANT; then
...
# MACs are different on buildbox and on local VirtualBox
# see http://ablecoder.com/b/2012/04/09/vagrant-broken-networking-when-packaging-ubuntu-boxes/
echo "Removing '${TARGET_UDEV_PERSISTENT_NET_RULES}'"
rm -f "${TARGET_UDEV_PERSISTENT_NET_RULES:?}"
So in this way, the interfaces that we get are ens18 in our infra for
{ce,pro,carrier}-trunk.mgm machines, and so the generated
/etc/network/interfaces usint the fixed names "eth*" (in process to be
renamed "neth*") cannot be found in those systems, and all
build-install-vm jobs fail.
In a local vagrant machine (ce-trunk from just before the change) we
have names like these for the network devices:
root@spce:~# dmesg | grep rename
[ 2.051263] e1000 0000:00:09.0 enp0s9: renamed from eth1
[ 2.065876] e1000 0000:00:03.0 enp0s3: renamed from eth0
[ 3.950540] e1000 0000:00:03.0 eth0: renamed from enp0s3
[ 4.049842] e1000 0000:00:09.0 eth1: renamed from enp0s9
In this boot session from which the logs above are taken, was booted
with grub without "net.ifnames=0", and udev "70-persistent-net.rules"
generated in place with the right infromation, and then of course things
work fine.
So we need some solution this before moving on with the change now
reverted.
Change-Id: I25d3b9c175b92214670ebb63a7916b60e0e4e5f9
Current trunk installations based on bullseye using recent Grml
environments are broken, as EFI environments running with recent kernel
versions (>=5.10) aren't properly detected anymore.
This is caused by the missing efivars kernel module.
CONFIG_EFI_VARS is no longer available since
20146398c4
(tagged initially as debian/5.10.1-1_exp1 + shipped with kernel package
5.10.1-1~exp1 and newer, incl. 5.10.38-1 as present in current
Debian/unstable). Therefore the kernel module efivars is no longer
available on more recent Debian kernel systems.
Quoting from https://wiki.debian.org/UEFI:
| The older interface was efivars, showing files under
| /sys/firmware/efi/vars, and this is what was used by default in both
| Wheezy and Jessie.
|
| The new interface is efivarfs, which will expose things in a slightly
| different format under /sys/firmware/efi/efivars. This is the new
| preferred way of using UEFI configuration variables, and Debian switched
| to it by default from Stretch onwards.
CONFIG_EFI_VARS is no longer required, instead efivarfs seems to be
available starting with kernel v3.10 and newer (see linux.git):
| commit a9499fa7cd3fd4824a7202d00c766b269fa3bda6
| Author: Tom Gundersen teg@jklm.no
| Date: Fri Feb 8 15:37:06 2013 +0000
|
| efi: split efisubsystem from efivars
|
| This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
| and the system is booted with EFI.
|
| This allows
| *) userspace to check for the existence of /sys/firmware/efi as a way
| to determine whether or it is running on an EFI system.
| *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
| loading any modules.
|
| [ Also, move the efivar API into vars.c and unconditionally compile it.
| This allows us to move efivars.c, which now only contains the sysfs
| variable code, into the firmware/efi directory. Note that the efivars.c
| filename is kept to maintain backwards compatability with the old
| efivars.ko module. With this patch it is now possible for efivarfs
| to be built without CONFIG_EFI_VARS - Matt ]
and:
| commit d68772b7c83f4b518be15ae96f4827c8ed02f684
| Author: Matt Fleming matt.fleming@intel.com
| Date: Fri Feb 8 16:27:24 2013 +0000
|
| efivarfs: Move to fs/efivarfs
|
| Now that efivarfs uses the efivar API, move it out of efivars.c and
| into fs/efivarfs where it belongs. This move will eventually allow us
| to enable the efivarfs code without having to also enable
| CONFIG_EFI_VARS built, and vice versa.
|
| Furthermore, things like,
|
| mount -t efivarfs none /sys/firmware/efi/efivars
|
| will now work if efivarfs is built as a module without requiring the
| use of MODULE_ALIAS(), which would have been necessary when the
| efivarfs code was part of efivars.c.
But we also need to ensure /sys/firmware/efi/efivars is mounted,
otherwise efibootmgr fails to execute:
| # efibootmgr
| EFI variables are not supported on this system.
| # lsmod| grep efi
| efi_pstore 16384 0
| efivarfs 16384 1
| # mount -t efivarfs none /sys/firmware/efi/efivars
| # efibootmgr
| BootCurrent: 0002
| Timeout: 3 seconds
| BootOrder: 0001,0002,0003,0000,0004
| Boot0000* UiApp
| Boot0001* UEFI QEMU QEMU HARDDISK
| Boot0002* UEFI PXEv4 (MAC:02B31C8CA0AA)
| Boot0003* UEFI PXEv4 (MAC:92097BD02A48)
| Boot0004* EFI Internal Shell
FTR: we can't test only for existence of directory
/sys/firmware/efi/efivars, as it exists but is empty by default, so we
need to look inside the directory instead.
See https://github.com/grml/grml-debootstrap/pull/174 for the related
grml-debootstrap upstream change, which is supposed to be released as of
grml-debootstrap v0.97.
But as a) grml-debootstrap v0.97 isn't released yet, b) it's unclear
whether grml-debootstrap v0.97 will make it into bullseye (soonish, or
if at all) and c) we don't have the Grml repositories available via our
approx Debian mirror (as used in our PRO/Carrier environments) and don't
want to update our Grml squashfs system for this change neither, we need
to apply a workaround for this efivars vs efivarfs situation. Otherwise
Debian installation fails in EFI environments using Debian kernel
>=5.10. Thankfully we can work around this using according pre/post
scripts in grml-debootstrap, that's what efivars_workaround() is all
about.
Thanks: Manuel Montecelo <mmontecelo@sipwise.com> for the initial patch and Volodymyr Fedorov <vfedorov@sipwise.com> for underlying research
Change-Id: I5374322cb0a39cfed6563df6c4c30f1eafe560c1
The "Building database of manual pages ..." of mandb(8) is invoked
during Debian package installations, and takes a considerable amount of
time[1]. By disabling this, we can speed up our installation process,
similar to what we already do with all our build environments.
If someone really needs the man-db database (for apropos(1) or
whatis(1) usage), then invoking `systemctl restart man-db.service`
provides that on demand.
FTR: there are also /etc/cron.daily/man-db + /etc/cron.weekly/man-db,
though they don't do anything when running under systemd. There's also
man-db.timer, though we don't have it enabled by default on our NGCP
systems.
[1] Demo from a running PRO system:
| root@sp2:~# rm -rf /var/cache/man
| root@sp2:~# time systemctl restart man-db.service
|
| real 1m18.357s
| user 0m0.000s
| sys 0m0.009s
Change-Id: If98007860490adc5ad954e8c36000abd7281931b
Add options to install bullseye in all places where buster is used, use
it as default when possible, and keep these for the moment.
Switch to bullseye in Dockerfile.
Change-Id: I2f693982ba92a671a6f2254c5a245a1d05231404
The call:
UTS_RELEASE="${KERNELVERSION}" LD_PRELOAD="${FAKE_UNAME}" \
grml-chroot "${TARGET}" /media/cdrom/VBoxLinuxAdditions.run --nox11
fails with:
Running in chroot, ignoring request: daemon-reload
Before 8a54cd1374 it was skipped so hide
it with '|| true'.
Use 'grml-chroot' instead of 'chroot' as 'grml-chroot' is a wrapper
which also cares about required mountpoints.
Use single style for "${TARGET}" variable.
Change-Id: Icc625c9a58b114f62350fc1e540ddac8a4147f28
Quoting from "man bash" about `-E` (AKA errtrace):
| If set, any trap on ERR is inherited by shell functions, command
| substitutions, and commands executed in a subshell environment.
| The ERR trap is normally not inherited in such cases.
To demonstrate the problem see this short shell script:
| % cat foo
| set -eu -o pipefail
|
| bailout() {
| echo "Bailing out because of error" >&2
| exit 1
| }
| trap bailout 1 2 3 6 9 14 15 ERR
|
| foo() {
| echo "Executing magic"
| magic
| }
|
| foo
| echo end
If "magic" can't be executed, then this fails as follows:
| % bash ./foo
| Executing magic
| ./foo: line 11: magic: command not found
But it doesn't invoke the bailout function via trap.
When using `set -eE` (AKA errexit + errtrace), instead of only
`set -e` (errexit), then it behaves as expected though:
| % bash ./foo
| Executing magic
| ./foo: line 11: magic: command not found
| Bailing out because of error
Change-Id: I26396b87d4a391a75997c061e866709daa57870e
grub-pc >=2.04-11 has a new behavior regarding /boot/grub/i386-pc/
handling, where we end up with an empty /boot/grub/i386-pc/ after
*successful* grub-install execution:
| root@grml ~ # vgchange -ay
| 3 logical volume(s) in volume group "ngcp" now active
| root@grml ~ # mount /dev/mapper/ngcp-root /mnt
| root@grml ~ # grml-chroot /mnt /bin/bash
| Writing /etc/debian_chroot ...
| (spce)root@grml:/# cd
| (spce)root@grml:~# grub-install /dev/sda
| Installing for i386-pc platform.
| Installation finished. No error reported.
| (spce)root@grml:~# ls -la /boot/grub/i386-pc/
| total 16
| drwxr-xr-x 2 root root 12288 Dec 16 12:04 .
| drwxr-xr-x 4 root root 4096 Dec 16 12:07 ..
This causes the installed system to fail to boot with:
| GRUB loading..
| Welcome to GRUB!
|
| error: file `/boot/grub/i386-pc/normal.mod' not found.
| grub rescue> _
The underlying issue is that recent grub versions unlink the files
inside /boot/grub/i386-pc, though it doesn't report anything about it
(even under `--verbose` execution).
This is triggered in our situation, as lvm2's vgs binary isn't present
yet. In earlier versions of grub this wasn't causing any problems and
grub-install happily installed the files inside /boot/grub/i386-pc, even
though we installed lvm2 only afterwards via our metapackages. To
ensure lvm2 is available during installation time within
grml-debootstrap, explicitly add to it list of packages to be installed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977544 for further
details regarding the grub bug.
Change-Id: I27a1cd18777526eb26b838fae88d4d87b6e93467
We install virtualbox-guest-additions in the target system for usage
with VirtualBox and shared folders via Vagrant. We invoke the
VBoxLinuxAdditions.run machinery from the running Grml live system. But
the target systems usually has a different kernel package and version
installed, so we have to apply some tricks to get it working. This is
where we rely on fake-uname.so.
Since commit a91baa2 (TT#48647 Ship fake_uname lib in package) we're
relying on fake-uname.so from ngcp-deployment-scripts, instead of
building and shipping it via deployment.sh itself.
But we have ngcp-deployment-scripts available only when installing NGCP
- as we're installing it there and only afterwards invoke
vagrant_configuration() - whereas it's missing when we install a plain
Debian system (like with our debian_bullseye_plain_vagrant.box),
therefore failing with:
| cp: cannot stat '/mnt/usr/lib/ngcp-deployment-scripts/fake-uname.so': No such file or directory
| ERROR: ld.so: object '/usr/lib/ngcp-deployment-scripts/fake-uname.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Change-Id: I639a43c3deafd2fc188350936e15f48482103209
The ensure_packages_installed function ensures that specified packages
are present during runtime. This is used e.g. for installation of
virtualbox-guest-additions-iso Debian package from within
vagrant_configuration(), which is used to execute
/media/cdrom/VBoxLinuxAdditions.run inside the target system.
We can't use random Debian repositories though, as the package
dependencies need to match the running live system. So far we only used
the buster repository, as our current grml-sipwise ISOs are based on
something close to buster.
On the other hand we can't use virtualbox-guest-additions-iso from
Debian/buster in our Debian/bullseye Vagrant boxes, as
/sbin/mount.vboxsf doesn't work then.
So use the bullseye repository if the release of the target system is
bullseye, which seems to work with our current Grml ISOs and current
state of bullseye.
Change-Id: Iaf965daa6ff7a62e2b3bd8c55b8f761abd94c241
Nowadays we only deploy stretch + buster based Debian systems, so drop
those release specific checks to also support bullseye and newer Debian
releases.
Change-Id: Ibf3d1527ccaeba60526a730e6886e6521c08d20e
The /usr/bin/python symlink/binary no longer exists in recent
Grml-Sipwise ISOs and python3 doesn't ship SimpleHTTPServer but
http.server instead.
Change-Id: I6677e8a416b142034d99d5b1d2b11ba74d87a6ec
No need to install this package to non-vagrant system.
Do not add this package to Sipwise-grml image - it's too heavy (86M)
and not needed on real systems.
Change-Id: I9ec9ff76d588f4ced30ba199f05bb167eec5288a
Previously the functions and the code were fixed so it was hard to
understand the flow of execution.
Move all functions to a single section at the beginning of the script
so it's easier to understand the code.
Fix shellcheck warnings:
SC2086: Double quote to prevent globbing and word splitting.
SC2154: efidev1 is referenced but not assigned.
Change-Id: Ie4bf28c166e4a9ff236eff807ee97adae6ecddd0
This variable is used in some ngcpcfg *.services file.
Specifically 'ngcp-provisioning-tools/mysql_values.cfg.services' uses
this variable to specify mysql db host and if it's necessary to reload
kamailio.
Change-Id: Ibf137cdd0ad6f6492a30cfa715c468e4ac22832f
Initially wanted to sync with https://github.com/grml/grml-network/ as
of commit 49409a5587d, though templates/scripts/includes/netcardconfig
existed only to provide the VLAN patch until we had this available from
upstream and our own ISO. Now that everything has been upstreamed and we
have up2date Grml ISOs, let's switch to the one included in upstream
Grml.
Change-Id: I685cd0ad95033ad2b50036e53c2ee9814a776e63
Instead of having to maintain this ISO in our web server off-band,
we switch to use the packaged version, which makes validation
unnecessary as apt gives us that. And it also gives us a newer
version (currently 6.0.4 with Debian buster 10.3 vs the old 5.2.26).
Change-Id: Id89280bbe7fadeb35d391b5dc46e930935017588
From the packages' deps and content POV Pro and Carrier packages are
equal to each other so get rid of this separation.
Change-Id: I587dba3147bdc9b3c0f10da820ba4cdc8a0a0f08
This reverts commit ee2398b6f8.
We've removed mcollective from our infrastructure and ready to update
puppet to the latest available version.
Change-Id: I7a860be9e051ed09bd69c165aaafc2acd1f17cd8
In the past we were associating them by MAC address and only in some cases, like
Pro/Carrier and in Virtual Machine environments.
However, it's beneficial to have this in other scenarios, so we will create udev
rules to pin them down during deployment.
Change-Id: Ic1b397e81af673b974961158a0e9a05ce5b80a69
This file contains the following public keys:
68A702B1FD8E422AAAA1ADA3773236EFF411A836 - jessie, stretch, buster
debian repos, mr3.8-mr8.4 public repos.
F7B8A739CE638D719A078C9859104633EE5E097D - autobuild repos.
8A61E3C73B6987020226079D69D9C21F6D9B587E - new key for mr7.5+.
This very file will be used only for bootstrap purposes and will be
dropped in the end of installer.
Change-Id: I60a903b4b05ab8a0d1a6498773802f756f8e4202
Initially dirmngr package was installed to allow running apt-key inside
deployment.sh to install puppetlabs key. Then after moving puppetlabs
key to local file package installation was removed. But we still need it
for successful first puppet run that also uses apt-key. Otherwise there
is the error: 'Could not find a suitable provider for apt_key'. Puppet
also installs dirmngr package but in such case only the second puppet run
will be successful so we need to install the package before the very
first puppet run.
Change-Id: I28edbd8c91c841074ac1b3f1eb6df16e14daa084
In deployment.sh line 2109:
local puppet_gpg='/root/puppet.gpg'
^-- SC2168: 'local' is only valid in functions.
Change-Id: I628cbac844db6aa1913ab1747906656d7d6d739b
The puppet.gpg is located in Grml-sipwise so no need to download the
hard-coded key but use the local one.
Change-Id: Id57180de96efef4a5a13086e7807c615bd65b886
In the event of network blips, HA switchovers or failure of the servers, there
might be a problem downloading some of the hundreds or thousands of packages
needed for installation.
Set the option to retry 3 times in the case of such failures, to try to minimise
their impact.
This has to be done in several places because mmdebstrap (which uses apt) and
apt-get are invoked at different points.
Change-Id: I5acbd9895fa37452026e582c241ced945fbba3d7
The boot parameter 'ngcpstatus' is used to wait the number of seconds
before ending process so the external system can retrieve the final
status from 4242 port.
Add the value of this parameter as STATUS_WAIT_SECONDS option to
ngcp-initial-configuration config so external system can track the
configuration stage also.
Change-Id: I68d9c65a1cc96bf581305e92d8b9b6bfc34e7ed2
mmdebstrap and debootstrap install any "important" packages in the
standard installation variants, pulling in e.g. libgdbm5 (which was of
priority `important` until #890832 was fixed and it was downgraded to
priority `optional` with libgdbm6).
Same for libusb-1.0-0 vs libusb-0.1-4:amd64:
% apt-cache show libusb-1.0-0 | grep Priority
Priority: optional
% apt-cache show libusb-0.1-4:amd64 | grep Priority
Priority: important
Resulting in having libusb-0.1-4 *and* libusb-1.0-0 installed on
our NGCP systems, while libusb-0.1-4 is completely unneeded and irrelevant.
So this is unnecessary, and all the other packages that are automatically
pulled in via the standard installation should be handled via according
and explicit dependencies elsewhere, JFTR - currently being in
Debian/buster:
| apt-utils bsdmainutils cpio cron debconf-i18n dmidecode dmsetup
| e2fsprogs gdbm-l10n ifupdown init iproute2 iptables iputils-ping
| isc-dhcp-client isc-dhcp-common kmod less libapparmor1 libapt-inst2.0
| libargon2-1 libbsd0 libcap2 libcap2-bin libcom-err2 libcryptsetup12
| libdevmapper1.02.1 libdns-export1104 libelf1 libestr0 libext2fs2
| libfastjson4 libidn11 libip4tc0 libip6tc0 libiptc0 libisc-export1100
| libjson-c3 libkmod2 liblocale-gettext-perl liblognorm5 libmnl0
| libncurses6 libnetfilter-conntrack3 libnewt0.52 libnfnetlink0 libnftnl11
| libpopt0 libprocps7 libslang2 libss2 libtext-charwidth-perl
| libtext-iconv-perl libtext-wrapi18n-perl libxtables12 logrotate lsb-base
| mount nano netbase procps readline-common rsyslog sensible-utils systemd
| systemd-sysv tasksel tasksel-data tzdata udev vim-common vim-tiny
| whiptail xxd
The essential variant lacks apt(-get), while the minbase variant provides
the same base as essential, *plus* apt so we can actually install
further packages, so that's what we're using.
We pull in systemd + systemd-sysv + init explicitly to force its usage,
ngcp-installer is complaining and prompting otherwise.
We pull in isc-dhcp-client + ifupdown to have a working networking/DHCP
setup after reboot, since we don't use systemd-networkd or alike (yet).
Applying this change will result in lacking the following packages in
our Debian/stretch based trunk builds:
* apt-utils
* blends-tasks
* debconf-i18n
* iputils-ping
* isc-dhcp-common
* libapt-inst2.0
* liblocale-gettext-perl
* libtext-charwidth-perl
* libtext-iconv-perl
* libtext-wrapi18n-perl
* libusb-0.1-4
* logrotate
* tasksel
* tasksel-data
* vim-tiny
The ones we want to have available will be handled via explicit
dependencies in NGCP (meta)packages.
Change-Id: I14dac92d99172cf792a0334601a930ce6698dc83
Michael Prokop
Manuel Montecelo
Mykola Malkov
Guillem Jover
Sergii Kipot
Alexander Lutay