Unable to build with lxd when using lxd with lvm pool.
Metadata
Current evaluation
Snapcraft 3.8/3.9.2 --use-lxd reportedly assumes a directory-backed LXD pool and fails on LVM pools; the old report has no maintainer triage or follow-up.
Suggested action: needs triage
Reason: The report provides concrete versions, --use-lxd, an exact missing-rootfs error, and an LVM-pool setup, but its hardcoded-path conclusion is unverified. With no labels, maintainer response, comments, or follow-up, it needs assessment against the current provider implementation; its age alone does not justify closure.
Evaluated by: mr-cal-bot
Impact:
45
Quick Win:
15
Complexity:
45
Confidence:
84
Actionability:
62
Issue body
System version: ubuntu 18.04
snapcraft: 3.8(3440) and 3.9.2(3720)
When tring to build snaps with --use-lxd, the following error is shown:
/snap/snapcraft/3440/lib/python3.5/site-packages/pylxd/models/_model.py:116: UserWarning: Attempted to set unknown attribute "type" on instance of "Container"
key, self.__class__.__name__
Stopped
An error occurred with the instance when trying to start with 'LXD': Common start logic: No such file or directory: "/var/snap/lxd/common/lxd/storage-pools/pool1/containers/snapcraft-project/rootfs".
Ensure that 'LXD' is setup correctly and try again.
It seems that the directory is hardcoded toward the /var directory which is the default one I believe.
My lxd is setup with a lvm pool manually.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
15
Complexity:
45
Confidence:
84
Actionability:
62
|
needs triage | Snapcraft 3.8/3.9.2 --use-lxd reportedly assumes a directory-backed LXD pool and fails on LVM pools; the old report has no maintainer triage or follow-up. | |
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
12
Complexity:
61
Confidence:
87
Actionability:
68
|
needs triage | Snapcraft 3.8/3.9.2 reportedly fails with --use-lxd on an LXD LVM pool because it expects a hardcoded directory-backed pool rootfs; the report remains unassessed. | |
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
18
Staleness:
95
Complexity:
40
Confidence:
70
Support Request:
15
|
close stale | Snapcraft 3.8/3.9.2 fails with --use-lxd when LXD uses a custom LVM pool, due to a hardcoded /var/snap/lxd/common path. 6+ years old, no labels, no maintainer interaction, no comments. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
15
Confidence:
90
Support Request:
20
|
close stale | Build fails with LXD when using a custom LVM pool due to a hardcoded path error. Issue is 6+ years old with no maintainer interaction or updates. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
98
Complexity:
35
Confidence:
95
Support Request:
20
|
close stale | Snapcraft fails to detect custom LVM storage pools when building with LXD on Ubuntu 18.04. No activity for over 6 years; affected versions are EOL. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
25
Confidence:
95
Support Request:
30
|
close stale | Snapcraft fails to start LXD containers when using a custom LVM storage pool due to a hardcoded path. Issue is over 6 years old with no activity. |
Update history
| Date | Change |
|---|---|
| created |
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1878513 using lxd provider on s390 fails | snapcraft (launchpad) | closed | LXD builds on s390 required Snapcraft 4.0 from the candidate channel; the report was later expired after 60 days without activity. | |
| #1839399 snapcraft not pulling snap from lxd container | snapcraft (launchpad) | open | Snapcraft 3.7.1 reported a successful --use-lxd build but left the generated snap absent on the host; a maintainer identified possible CWD handling, and the case remains unresolved. | |
| #1825820 Snapcraft doesn't update the `snapcraft-project` disk source when the path is moved | snapcraft (launchpad) | open | LXD builds reportedly fail after moving a project because the instance retains the old disk source. LXD remains supported, but this untriaged report needs verification against the current craft-providers integration. |