Allow answers.yaml to specify the console to run the installer on
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| subiquity |
New
|
Undecided
|
Unassigned | ||
Bug Description
Somehow related to LP: #1852730.
By design subiquity starts on all the consoles available on the machine. When running the installer with an answers.yaml and >1 consoles this leads to a "race" between the running instances, and the installation will proceed on the subiquity that managed to lock the answers.yaml. In other words: the install will run on a random console.
This can be confusing for the user, as by monitoring the same console and repeating the installation it appears as the install process sometimes begins and sometimes does not. Even when this issue is understood there is no easy way to predict in which console subiquity will start. I face this issue in ISO testing.
This would be partially solved by allowing the answers.yaml file to specify on which console the installer should run. But subiquity should probably also have a list of (per-arch?) console types in order of priority, so the installation always starts on the same console even if no console is explicitly specified.
Subscribing xnox, as we spoke a couple of times of this issue.
| summary: |
- [autoinstall] allow answers.yaml to specify the console to run the - installer on + Allow answers.yaml to specify the console to run the installer on |
| Michael Hudson-Doyle (mwhudson) wrote | #1 |
| Michael Hudson-Doyle (mwhudson) wrote | #2 |
| Paride Legovini (paride) wrote | #3 |
| tags: | added: easy |
The goal for noninteractive autoinstalls is to have identical progress reporting on _all_ consoles. Where there is any interactivity it's a bit less clear, the subiquity that the user interacts with should run the install. If the user interacts with more than one subiquity, well, that's going to be confusing. It would be nice if we can prevent that somehow but I don't really see how.