Comment 3 for bug 1853018

Right! That was pretty obvious from the curtin logs, less so from the subiquity logs. The problem was that this was on ppc64el and I was using archive.ubuntu.com instead of ports.ubuntu.com.

Switching to the correct mirror allows the installation to complete, *however* the tracebacks are still there, e.g.:

2019-11-18 23:03:54,528 ERROR block-discover:210 load_probe_data failed restricted=False
Traceback (most recent call last):
  File "/snap/subiquity/1335/lib/python3.6/site-packages/subiquity/controllers/filesystem.py", line 207, in _probe_done
    self.model.load_probe_data(probe.result)
  File "/snap/subiquity/1335/lib/python3.6/site-packages/subiquity/models/filesystem.py", line 1378, in load_probe_data
    self.reset()
  File "/snap/subiquity/1335/lib/python3.6/site-packages/subiquity/models/filesystem.py", line 1202, in reset
    config = storage_config.extract_storage_config(self._probe_data)
  File "/snap/subiquity/1335/lib/python3.6/site-packages/curtin/storage_config.py", line 1249, in extract_storage_config
    tree = get_config_tree(cfg.get('id'), final_config)
  File "/snap/subiquity/1335/lib/python3.6/site-packages/curtin/storage_config.py", line 274, in get_config_tree
    for dep in find_item_dependencies(item, sconfig):
  File "/snap/subiquity/1335/lib/python3.6/site-packages/curtin/storage_config.py", line 244, in find_item_dependencies
    _validate_dep_type(item_id, dep_key, dep, config)
  File "/snap/subiquity/1335/lib/python3.6/site-packages/curtin/storage_config.py", line 192, in _validate_dep_type
    'Invalid dep_id (%s) not in storage config' % dep_id)
ValueError: Invalid dep_id (raid-md1p1) not in storage config

I can attach the logs of an installation with the correct mirror set up.

It would be to add a "no tracebacks in the installer logs" step in the ISO testing jobs, what do you think?