subiquity

Client side crash after receiving PROBING storage response status

Bug #1962205 reported by Olivier Gayot on 2022-02-24

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	subiquity	Fix Released	Medium	Unassigned

Bug Description

I quickly went through the first steps of the installation and Subiquity crashed with the below stack when reaching the file-system screen.

SourcePackage: subiquity
Title: Installer UI crashed with TypeError
Traceback:
Traceback (most recent call last):
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquity/client/client.py", line 404, in run
     super().run()
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquitycore/tui.py", line 374, in run
     super().run()
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquitycore/core.py", line 135, in run
     raise exc
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquity/client/controllers/filesystem.py", line 229, in _guided_choice
     self.model.load_server_data(status)
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquity/models/filesystem.py", line 985, in load_server_data
     self._actions = self._actions_from_config(
   File "/snap/subiquity/x1/lib/python3.8/site-packages/subiquity/models/filesystem.py", line 1116, in _actions_from_config
     for action in config:
TypeError: 'NoneType' object is not iterable

As a response to the POST /storage/guided query, the client received a StorageResponse containing the status ProbeStatus.PROBING (and all other fields set to None) ; which it didn't expect.

The client should learn to expect this kind of answer or we should implement a mechanism to have the server wait until it finishes probing before responding.

See original description

Revision history for this message

Olivier Gayot (ogayot) wrote on 2022-02-24:

Stack trace + logs from slient and server Edit (71.5 KiB, text/plain)

description:

updated

Revision history for this message

Olivier Gayot (ogayot) wrote on 2022-03-17 (last edit on 2022-03-17):

The bug occurs when the user clicks on "Done" from the "Guided storage configuration" screen.

By the time we reach this screen, we can expect the original probing operation to be completed (otherwise we would have gotten the "Waiting for storage probing to complete") screen instead.

However, we have a hook on udev events that re-trigger the probing operation. Therefore, we can't reliably expect that no probing operation is ongoing when the user clicks on "Done". One way to reproduce the crash in dry-run mode is to add the following:

```
     async def guided_POST(self, data: GuidedChoice) -> StorageResponse:
         log.debug(data)
+ self._udev_event()
         self.guided(data)
         return await self.GET()
```
this will simulate a udev event when the user clicks on done ; effectively making the probing operation restart. As the result, the HTTP response will have status=ProbeStatus.PROBING.

Revision history for this message

Michael Hudson-Doyle (mwhudson) wrote on 2022-03-18:

Oh I see what's happening. Basically if a block device probe is in progress when you POST to /guided, you get a response back with a state of PROBING and no config. You can only get to this point if at least one probe has completed, so we can just return the results of that. (One alternative would be wait for the pending probe to complete or another would be to do what I really want to do anyway and make handling the results of udev block events much more incremental. But one thing at a time)

Revision history for this message

Michael Hudson-Doyle (mwhudson) wrote on 2022-03-18:

https://github.com/canonical/subiquity/pull/1234

Olivier Gayot (ogayot) on 2022-03-21