OEM meta-packages have an attribute stating if they want the OEM kernel
or the "default" kernel to be installed alongside them.
That said, in the OEM archive, they expect the "default" OEM kernel to
be the HWE kernel. This is only true for ubuntu-desktop. Let's not
install OEM meta-packages on ubuntu-server for now.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When installing on certified hardware, we now look for the
Ubuntu-Oem-Kernel-Flavour attribute of the OEM meta-package to determine
which kernel flavour we should use. This attribute can take two values:
* oem -> in which case we make use of the override to install the
OEM kernel flavor
* default -> in which case we get the kernel flavor that was originally
configured.
If the attribute is not present or contains any other value, it is
treated the same as if it was "oem".
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Before running curtin's curthooks, we use the kernel model to configure
which kernel meta-package we want to install on the target system.
There are multiple ways to select the kernel flavor, including
autoinstall directives or placing a file in
/etc/subiquity/kernel-meta-package.
That said, if we install Ubuntu on certified hardware, the OEM
meta-package will have something to say about the expected kernel
flavor. When installing the kernel meta-package, it will automatically
pull the kernel that it expects to run on.
Therefore, we should make it possible to override the kernel flavor so
that we don't end up with multiple kernels installed.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
If a cloud-config is sent that adjusts the users but creates no default
user, Subiquity crashes with a exception while mishandling the None.
cloudinit.distros.ug_util.extract_default is documented as returning
None in the event that the default user cannot be found.
Example bad cloud-config:
```yaml
users:
- name: ubuntu-server
```
This requires some tweaks to make the test machinery accept an
autoinstall that doesn't do most of the things we usually expect. Also
set the .target attribute to None when reset-partition-only is true to
catch more issues in the dry-run environment.
When OEM meta-packages are available, install them before running
curthooks. If we are online, we also upgrade the metapackages so that
they are upgraded to their version in the relevant OEM archive. This
will effectively pull the kernel.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When installing third-party drivers, we now pass the --no-oem option to
the ubuntu-drivers install command. Because of LP #1966413, the option
might get ignored, which is not ideal but sort of acceptable - because
we want OEM meta-packages installed unconditionally anyway.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When we want to list third-party drivers, we want to avoid listing OEM
meta-packages as well. The ubuntu-drivers --no-oem list would do it but
we can't reliably use it for now. Let's manually exclude oem-*-meta
packages from the list.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Before starting the actual installation, we make changes to etc/apt
directory in an overlay so that the packages are pulled from the media
instead of the network.
At the end of installation, we need to revert these changes. We used to
replace the etc/apt directory on the target by the etc/apt directory
from the configured overlay.
This is a simple way to revert the temporary changes. Unfortunately, it
also removes configuration files that extra packages may have installed
in etc/apt. For instance, when installing an OEM meta-package, a
etc/apt/sources.list.d/<oem-meta-package>.list gets installed.
If we reset etc/apt to its content from the configured overlay, we lose
this file.
Fixed by selectively discarding changes to the files that subiquity
modified.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When running subiquity in dry-run mode with SUBIQUITY_DEBUG=run-drivers,
we now support using a YAML file describing the hardware in a
umockdev-compatible way. This allows to give some control on what
ubuntu-drivers list will reply.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
These errors are really errors in how the ISO is constructed, so logging
and ignoring seems more appropriate, compared to say encryption being
unavailable because the TPM is in lockout mode.