snapd.seeded.service blocks for a long time preventing cloud-init from completing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Invalid
|
Undecided
|
Unassigned | ||
snapd |
In Progress
|
High
|
Paweł Stołowski |
Bug Description
We use qcow2 images to install baremetal servers, our datasource is to have a little partition as ConfigDrive with meta_data.json and vendor_data.json is necessary.
The vendor_data.json provides informations about default user password settings.
This actually works well for every linux distrib we use unless cloud-init is 19.1.
The modules steps are no longer working:
cat /run/cloud-
{
"v1": {
"datasource": "DataSourceConf
"init": {
"errors": [],
"finished": 1561465042.7556307,
"start": 1561465042.1868145
},
"init-local": {
"errors": [],
"finished": 1561465035.4210315,
"start": 1561465034.724825
},
"modules-config": {
"errors": [],
"finished": null,
"start": null
},
"modules-final": {
"errors": [],
"finished": null,
"start": null
},
"modules-init": {
"errors": [],
"finished": null,
"start": null
},
"stage": null
}
}
and we can see in the /var/lib/
Changed in cloud-init: | |
status: | Incomplete → Triaged |
Changed in snapd: | |
status: | In Progress → New |
Changed in snapd: | |
status: | New → In Progress |
Thanks for filing a bug.
Could you run 'cloud-init collect-logs' and attach the tarball it creates?