Per LP: #1962025, the update screen can get stuck in test automation.
Cancel the task waiting to see if there is an update, which makes sense
more broadly anyhow in that if a regular UI user has declined the
update then the check task is no longer helpful.
We now provide implementation for different interfaces to list and
install drivers using ubuntu-drivers. The implementations are outside
the drivers controller.
We have:
* the normal interface that calls ubuntu-drivers in the root directory
specified (i.e., in /target or an overlay).
* a dry-run interface that calls the system's ubuntu-drivers for
listing the drivers available (but does not install anything).
The listing of drivers will fail if --recommended is not an available
option in the system's ubuntu-drivers implementation.
* a dry-run interface that returns an hard-coded list of drivers and
does nothing on installation.
* a dry-run interface that returns an empty list of drivers.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Using run_curtin_command, we have no way to specify the encoding or
something like universal_newlines=True. This is actually not supported
by asyncio.create_subprocess_exec(...).
We have partial support for this in Subiquity when using arun_command()
but run_curtin_command() actually relies on astart_command() + wait().
Therefore, we now decode the output at the very end, just before reading
the outout of ubuntu-drivers.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In the reponse to the /a/drivers GET call, we now include a list of
packages / drivers instead of just storing a boolean telling if any
driver has been found.
Each element from the list corresponds to the name of a package to
install.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The drivers GET call returned only the value of "has_drivers" (when
known). In order to have the client be able to know the current value of
install/do_install, we now embed the value into the response as well:
Before, the call would return either:
true -> meaning that there are drivers available to install
false -> meaning that there are no drivers available to install
null -> retry later - we don't know yet
Now we have:
{
"has_drivers": boolean or null if we don't know yet
"install": boolean
}
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The autoinstall data for the drivers was only constituted of a boolean,
e.g.:
drivers: true
or
drivers: false
It was not immediately clear that the boolean value meant (install/don't
install the drivers).
We now store the boolean in the "install" sub-element instead, e.g.:
drivers:
- install: true
drivers:
- install: false
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
os-prober is leaving around invalid devices and we don't know what to do
about it yet, but we do know that we don't require os-prober for
20.04.4. Back this out. LP: #1961640 LP: #1961628
AptConfigurer.setup_overlays() used to accept either a single Lower
directory or a sequence of them. It oftentimes felt confusing so we now
accept only a sequence of Lower's. If we want to pass a single Lower, we
can just pass a list with a single element.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
Dan Bungert