A new table shows all the SSH identities/keys that are currently
imported. The user can select one and delete it from the list if he
wants to.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
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>
Previously, on the SSH screen, the ability to enable/disable the SSH
server and the ability to import a SSH identity were both covered by a
single form. Therefore, there was no way to import multiple identities.
This change adds a button "Import SSH key" which opens a new form to
import an identity. The button can be pressed multiple times and the
resulting identities are all submitted when the user clicks on Done.
Furthermore, navigating back to the SSH screen does not "forget" already
imported identities.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The SSHModel contained a ssh_import_id member variable. According to the
comment, it was originally meant to store meta-data about a SSH key ;
and was supposed to allow showing some sort of info back in the SSH view
if the user decides to go back.
I suspect that this variable has been unused for a long time.
Furthermore, it can only hold information about a single SSH key and we
support multiple keys..
Let's get rid of it.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Back when sources.list was always present, we would:
* move the contents of sources.list to sources.list.d/original.list
* write the CDROM info to sources.list so the CDROM cat be used as an
APT source
* restore the original sources.list file when .deconfigure() is called,
effectively discarding CDROM info
Nowadays, there is no guarantee that sources.list exists. So restoring
the contents of sources.list may mean deleting sources.list if it wasn't
present in the first place.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When an error occurs during the execution of a "$ curtin install"
invocation, the associated bug report would be titled:
"install failed crashed with CalledProcessError"
This is not very user friendly and it does not immediately give any
insight on:
With the number of reports that we receive these days, I think
classifying these reports would make our life a bit easier, and possibly
make the users understand better what's going on.
This change adds a wat to detect if a bug report is the result of a
"$ curtin install" invocation failing. If it is, subiquity sets the
title of the bug report accordingly. Examples:
* "partitioning crashed with CurtinInstallError"
* "extract crashed with CurtinInstallError"
* "curthooks crashed with CurtinInstallError"
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We know that running os-prober on some systems is slow, potentially very
slow, especially when multiple removable devices are present.
This results in many bug reports showing "block probing crashed with
TimeoutError".
For now, I suggest we double the probert timeout when os-prober is
involved.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
We backup the sources.list to a file in sources.list.d to be
able to insert our source first; if we do not have a sources.list
this is not necessary.
If an image uses ubuntu.sources, this logic also works fine as
sources.list that we write will be sourced before the ubuntu.sources.
We write out the autoinstall data to make the install repeatable
but this should also include a reference to the autoinstall
documentation to increase usability.
In Python < 3.11, when passing a coroutine to asyncio.wait, it would
automatically be scheduled as a task. This isn't the case anymore with
Python 3.11. Now passing coroutines to asyncio.wait fails with:
TypeError: Passing coroutines is forbidden, use tasks explicitly.
Let's ensure we schedule the coroutines as tasks before passing them on
to asyncio.wait.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Updates the readme to point to the contributing guidelines document.
Include sections about the Ubuntu Code of Conduct, Contributor
License Agreement, where to file bugs, and where to submit
changes.
Signed-off-by: Chris Peterson <chris.peterson@canonical.com>
Booting Desktop and server live installer ISOs comes with different
platform requirements. When running kvm-test, we now accept the name of
a profile via the --profile option.
Profiles provide default settings for memory, disk size and extra QEMU
options. For now, two profiles are hard-coded: "server" - which is the
default and "desktop".
For desktop, we use two vCPU, 8 GiB of RAM, a 20 GiB disk and pass the
-device qxl option.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Olivier Gayot