Rather than always assuming it has to be mounted in from the layer to be
installed (snapd will now populate the seed in the target system when
its install API is called if it is empty).
Now that curtin more or less supports NVMe over TCP with the rootfs on
remote storage, relax the contraints set by subiquity.
We still need the /boot (and /boot/efi) partitions on local storage
though.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
A mismatch between the key names in BondConfig's to_config method
and NetworkDev's netdev_info function was causing subiquity to
crash when creating a bond with a valid transmit hash policy and
then later trying to edit it (LP: #2051586).
The correct key name set by the to_config method should be
"transmit-hash-policy" since this later gets passed to netplan
and neither "xmit-hash-policy" nor "xmit_hash_policy" is a valid
key name in pure netplan config.
When running answers-based automation, the SSH controller looks into
more than one section to find ssh-import-id directives.
If the "SSH" section exists, then it is where the ssh-import-id
directives must be placed. However, if the section does not exist, the
controller will also look for ssh-import-id directives in the "Identity"
section.
The answers.yaml file used this special mechanism. This is fine.
However, if one adds a SSH section to customize other settings (e.g.,
install_server, pwauth), then the ssh-import-id directives in the
Identity section suddently get ignored ; which is confusing and looks
as if there is a bug.
Let's move ssh-import-id directives to the SSH section.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
ubuntu-restricted-addons is a multiverse package and is not included in
the pool. Therefore, trying to get it installed when offline leads to an
obvious error.
Instead of making the whole Ubuntu installation fail, we now warn and
skip installation of the package when performing an offline install.
In a perfect world, we should not have offered to install the package in
the first place, but in practice, we can run an offline installation as
the result of failed mirror testing (bad network for instance).
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Even if we are going to ignore a mountpoint, we still need to process
its children...
Add machine config where the installer is running from a partition of a
disk you might want to install to, and an api test.
Note that it may not be possible to create an fsimage to use as a core
installation source (haven't tried, tbh) but I have upcoming changes to
use a disk image as installation source.
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 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>
We used to rely on a version key under apt autoinstall section to
specify if we want the old implementation (i.e., a single candidate
primary mirror) or the new implementation (i.e., multiple primary mirror
candidates).
Instead, we now introduce the apt->mirror-selection autoinstall section,
and move the primary section under it.
If the primary section if under apt, we want the old implementation.
If the primary section is under apt->mirror-selection, we want the new
implementation.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Running ssh-import-id as part of the CI has limitations. First it
requires that we have access to the Internet. Second, it is affected by
github and launchpad service disruptions and or rate limiting policies.
Make sure we don't call ssh-import-id as part of the CI. Instead use a
username that is configured to produce fake successful key imports.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
As part of our integrations tests, we import mwhudson's public SSH
key(s) from GitHub. At the moment, however, the GitHub API is rate
limiting the number of queries from our CI.
Upon exceeding the rate limit, our HTTP queries are responded with a 403:
┌────────────────────────────────────────────────────────────────────────┐
│ Importing keys failed: │
│ │
│ 2023-01-08 23:43:40,562 ERROR GitHub REST API rate-limited this IP │
│ address. See https://developer.github.com/v3/#rate-limiting . │
│ status_code=403 user=mwhudson │
└────────────────────────────────────────────────────────────────────────┘
Currently, upon pushing to GitHub, the CI runs the integrations tests
against 4 different Ubuntu images (focal, jammy, kinetic, lunar).
This ends up doing 4 SSH import queries at roughly the same time ; which
often exceeds the rate limit and makes some of the tests fail.
This patch makes integration tests import SSH keys from Launchpad
instead of GitHub. Maybe a better approach would be to mock the calls to
ssh-import-id in the CI instead.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The list of drivers suggested to the user may vary based on whether we
are installing a server or desktop image / source.
In the current implementation of the drivers controller, the value of
the source variant (e.g., server or desktop) is read early in the
initializer.
This is a problem because it happens before the client gets the
opportunity to tell us if we are installing a server or a desktop image.
If the source variant ever changes, we want to query again the list of
drivers to suggest.
Upon configuring the source, the drivers controller will query (again)
the list of drivers.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>