Incus admin recover fails on custom storage volume

Incus
1

I try to recover the default pool from a broken incus server. The zpool is fine but when incus tries to recover the found containers it fails due to a missing custom volume although the volume is in the found volumes:

The recovery process will be scanning the following storage pools:
 - EXISTING: "pool1" (backend="zfs", source="pool1")
 - NEW: "default" (backend="zfs", source="/dev/sdd")
Would you like to continue with scanning for lost volumes? (yes/no) [default=yes]:
Scanning for unknown volumes...
The following unknown storage pools have been found:
 - Storage pool "default" of type "zfs"
The following unknown volumes have been found:
 - Container "alf-test" on pool "default" in project "default" (includes 0 snapshots)
 - Container "dms" on pool "default" in project "default" (includes 22 snapshots)
 - Container "dms-test" on pool "default" in project "default" (includes 5 snapshots)
 - Container "rproxy" on pool "default" in project "default" (includes 22 snapshots)
 - Volume "alfdata-20160428" on pool "default" in project "default" (includes 0 snapshots)
 - Volume "alfdata-20160516" on pool "default" in project "default" (includes 0 snapshots)
 - Volume "var" on pool "default" in project "default" (includes 0 snapshots)
 - Volume "alfdata" on pool "default" in project "default" (includes 30 snapshots)
 - Volume "images" on pool "default" in project "default" (includes 0 snapshots)
 - Container "alf-appliance-5" on pool "default" in project "archive" (includes 0 snapshots)
 - Container "alf-appliance-74" on pool "default" in project "archive" (includes 0 snapshots)
Would you like those to be recovered? (yes/no) [default=no]: yes
Starting recovery...
Error: Failed import request: Failed creating instance "alf-appliance-5" record in project "archive": Failed creating instance record: Failed initializing instance: Failed add validation for device "alfdata": Failed loading custom volume: Storage volume not found

Has anyone an idea how to work around this? Maybe this is a side effect of the new dependant volumes?
Is there a way to overwrite/bypass/manipulate that config, so I could just import as it is?

2

You mention dependent volumes. Is that something you’re using in this scenario?

3

The container dms uses the custom storage volume alfdata as additional disk device, but it’s not marked as dependent.
I wonderered if there is not a way to modify the instance config before retrying the restore.

Since we only need that custom volume to recover: There is no way to only restore parts from the zpool, right?
I first tried to import the zpool with a different name not to conflict with the running incus, but then the recover for the containers failed to name mismatch of the pool name (still expecting pool default)

4

Can you file an issue about this? It may just be some ordering issue we need to sort out.

5

sure. In this case I fiddled the data directly from the zfs volume but I will keep the vm for some time to test any changes later and additionally will create a more simplified testcase.

It would be a nice feature add something like a filter and/or an overwrite to the recover command
Thanks!