state: remove UU_CANCELLING state which is broken and misleading
Last cycle, to make the installation faster, we decided to disable the
unattended-upgrades minimal steps. This prevents proper handling of
unattended-upgrades cancellation so we now drop the feature completely.
Furthermore, the status reported on the text installer UI is misleading
when unattended-upgrades is running.
(cherry picked from commit a39fb0391c49337de7c4dcfc612f95ee7af07cbb)
filesystem: probe NVMe controllers when running the restricted probe
If block probing times out, we rerun it with the restricted set of
probes. Sadly, the restricted set does not include "nvme" so we do not
enumerate NVMe controllers. This leads to the following error if NVMe
storage devices are present:
File "subiquity/models/filesystem.py", line 1492, in reset
self.process_probe_data()
File "subiquity/models/filesystem.py", line 1512, in process_probe_data
self._orig_config = storage_config.extract_storage_config(self._probe_data)[
File "/site-packages/curtin/storage_config.py", line 1420, in extract_storage_config
tree = get_config_tree(cfg.get('id'), final_config)
File "/site-packages/curtin/storage_config.py", line 313, in get_config_tree
for dep in find_item_dependencies(item, sconfig):
File "/site-packages/curtin/storage_config.py", line 283, in find_item_dependencies
_validate_dep_type(item_id, dep_key, dep, config)
File "/site-packages/curtin/storage_config.py", line 230, in _validate_dep_type
raise ValueError(
ValueError: Invalid dep_id (nvme-controller-nvme0) not in storage config
Fixed by also enumerating NVMe controllers as part of the restricted
probe operation.
We currently don't have plans to do anything with the _data_ of the
keys that fail to validate by cloud-init; and trying to access this
data has the potential to crash the installer if it doesn't exist,
at least at the top level (LP: #2062988).
(cherry picked from commit 1ef2b0741ac91110a1bdff8ed948c6d6f286d6ce)
