Container.bin contains hardcoded references to external volumes

Incus
1

I’m trying to import a backup of a container, and I get an error like:

Error: Failed importing backup: Failed creating instance record: Failed initializing instance: Failed add validation for device “bar”: Missing source path “/foo/bar” for disk “bar”

I seem to remember fixing this in the past by unpacking the backup file and then modifying index.yaml to correct the path, then packing it back up and importing it, but this time that doesn’t seem to work. I have changed all occurences of /foo/bar in the yaml file, but I still get the same error, and indeed by running xxd and grep I can confirm the path occurs in container.bin itself

Has this changed, and if so why? I was under the impression that the container bin file was simply the disk of the container, while the yaml contained whatever metadata necessary to spin it up, but that doesn’t seem to be the case.

Unfortunately in my case it seems like this now means this backup is now broken, unless I do something like temporarily ensure this path exists only to make the import succeed so I can fix the yaml, which seems unnecessarily annoying rather than being able to change it manually before importing it.

2

We have Allow overriding instance properties during backup restore (similar to `incus copy`) · Issue #1928 · lxc/incus · GitHub which should eventually fix that up cleanly.

index.json normally contains what we need to validate the import, though it’s not impossible that we have codepaths that also look at backup.json following the unpack of the data from container.bin. I don’t remember us doing much in the way of changes in that part of our logic though.

3

I did something similar yesterday to work around an issue with a missing volume. It worked but felt like a hack. In general I should remember to migrate instances instead of exporting and then importing them. I think that would be a cleaner solution.