The source screen now includes a checkbox that makes Subiquity search
for third-party drivers in a later stage.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
In order we place:
* the arguments that are for client & server
* the arguments for the client only
* the arguments for the server only
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
A scenario that should happen nearly always for guided direct, when we
add_boot_disk from partition_disk_handler we must update the gap or the
target partition is at the wrong offset.
When a HTTP client sends a query but closes the socket before an answer
is received, aiohttp signals it on the server end by raising an
asyncio.CancelledError in the associated query handler.
By default, when a task is cancelled with asyncio, the task(s) that it
is currently awaiting on are cancelled as well.
The GET handler for /drivers?wait=true awaits on the "list drivers"
task. Therefore, if the GET handler gets cancelled, so will be the "list
drivers" task.
When that happens, any subsequent call to GET /drivers?wait=true will
make the server raise an asyncio.CancelledError because the "list
drivers" task has already been cancelled. This results in:
* the socket being closed from the server end
* an aiohttp.client_exceptions.ServerDisconnectedError exception raised
on the client end. This type of exception is unhandled and makes the
client crash.
Fixed by preventing the "list drivers" task from being cancelled when
the GET /drivers query handler gets cancelled.
https://bugs.launchpad.net/subiquity/+bug/1968729
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The following commit added an unconditional return statement in the try
block of _move_screen, effectively making the associated else block
unreachable.
a7bcc7fa add a way to wait for something with notification after 0.1s
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
When we reach the storage screens on the installer, if the devices
probing operation has not finished, we:
* display a temporary "Probing" screen.
* create an asynchronous task (a.k.a., probing task) that will
eventually show the "Guide Storage" screen when the probing operation
finishes.
The probing task checks, when it finishes, that the screen currently
visible is the "Probing" screen. This is the expectation and is true in
most scenarios. But in case a different screen is visible, we skip
refreshing the display.
Unfortunately, sometimes, a "Progress" screen is shown for some time
before the "Probing" screen appears. Consequently, we do not refresh the
screen if the probing operation finishes whilst the Progress screen is
visible.
In order to keep the view returned by make_ui() up-to-date and make sure
that the right screen is shown even if the probing operation finishes
early, we use the level indirection that was implemented in make_ui.
https://bugs.launchpad.net/subiquity/+bug/1968161
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The make_ui() function / coroutine returns a BaseView (i.e., a
screen to display to the user).
That being said, when the application calls, make_ui(), it does not come
with a guarantee that the view returned will be displayed to the user
immediately.
One of the reason is that there are multiple await statements before the
we call the ui.set_body function. Therefore, tasks running concurrently
cannot reliably expect that they execute after the display is refreshed.
Perhaps more importantly, when the make_ui() function takes more than .1
second to execute, we display a "Progress" screen that stays visible for
at least one second. This can effectively delay a lot the moment when
the view returned by make_ui() is shown to the user. A lot can happen in
the meantime.
As the result, the view returned by make_ui can be outdated by the time
we show it on the screen.
One way to work around this problem is to store in the controller a
reference to the view that it returns in make_ui(). This way, the
controller can modify the view and keep it up-to-date until it gets
shown to the user.
Unfortunately, some controllers (e.g., the storage controller) do not
modify / mutate the existing view object when a modification is needed ;
but instead instantiate a new view object.
This patch introduces a level of indirection that can be used by these
controllers. Instead of returning a view object from make_ui(), the
controllers are now allowed to return a callback ; which in turn will
return a view object.
https://bugs.launchpad.net/subiquity/+bug/1968161
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>