filesystem: probe NVMe controllers when running the restricted probe

[ogayot]

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.

LP:#2063162

I intend to mention this bug in the release notes for 24.04.1.

[mwhudson]

sure. the correct thing to do is of course delete the concept of restricted probing but this is better than the status quo

[elehcim]

sure. the correct thing to do is of course delete the concept of restricted probing but this is better than the status quo

Yes, I also have the same problem with error related to sda (as reported here).

ValueError: Invalid dep_id (partition-sda1) not in storage config

[elehcim]

sure. the correct thing to do is of course delete the concept of restricted probing but this is better than the status quo

Yes, I also have the same problem with error related to sda (as reported here).

ValueError: Invalid dep_id (partition-sda1) not in storage config

I found out that the issue was due to the fact that the USB had been created with the wrong tool (see here). Would it be possible to make the installer a bit more resilient on this?

[ogayot]

Yes, I also have the same problem with error related to sda (as reported here).

ValueError: Invalid dep_id (partition-sda1) not in storage config

I found out that the issue was due to the fact that the USB had been created with the wrong tool (see here). Would it be possible to make the installer a bit more resilient on this?

@elehcim the original issue filed was related to the use of NVMe drives. However, I'm interested to know more about the "tool" you used that produced the wrong result for you. Could you elaborate on that? Which tool worked and which tool didn't?

[elehcim]

@ogayot, thanks for the reply! I had the issue when creating the USB via the Disks app (using Restore Partition Image option, probably wrongly). Creating the USB with the usb-creator-gtk tool solved the problem. Now I'm able to install the OS

[ogayot]

@ogayot, thanks for the reply! I had the issue when creating the USB via the Disks app (using Restore Partition Image option, probably wrongly). Creating the USB with the usb-creator-gtk tool solved the problem. Now I'm able to install the OS

Thanks for the info. I've filed https://bugs.launchpad.net/subiquity/+bug/2083924 to track progress. If you still have the logs for the failed installation, I'd appreciate if you could comment on the bug whether the "Validation error: ...... does not match ..." error is found in the Subiquity log file. Thanks!