That might be the culprit…
incus config show apps1|grep pool
pool: default
Rebooting to stable now to test…
Nope, it looks like it only does that for new installs.
incus storage ls
+---------+--------+-------------+---------+---------+
| NAME | DRIVER | DESCRIPTION | USED BY | STATE |
+---------+--------+-------------+---------+---------+
| default | zfs | | 10 | CREATED |
+---------+--------+-------------+---------+---------+
Intentional. We want to expose cloud images (eventually), but it requires some additional UI / Backend plumbing to make them properly supported. Right now they are not exposed to avoid users trying to select them and then wondering where the options for cloudinit are and ending up in a situation where they can’t supply SSH keys (for example) to boot-strap an image.
1 Like
After looking through this, I don’t think that’s my issue though.
I’m rebuilding all of my instances to see if something is amiss (I guess that is what’s nice about repeatability and it won’t take me forever!). The config in the OP worked fine on my truenas-vm on stable. So after I hit my head on the desk awhile more, I’m sure I’ll be feeling better… 
So I blew away all my instances and redid them, now I can get into stable and reboot, but I still get this error based on my cloud-init config I posted earlier. I also reinitialized the pool and it’s still default. So that didn’t affect anything since the pool didn’t change on my install. Just posting the error again in case it changed, doesn’t look like it. Instances don’t show up though. I’m kind of at a loss right now, as this worked in RC.1.
pydantic_core._pydantic_core.ValidationError: 4 validation errors for VirtInstanceQueryResult
result.list[VirtInstanceQueryResultItem].2.userns_idmap.uid
Input should be a valid dictionary or instance of IdmapUserNsEntry [type=model_type, input_value=None, input_type=NoneType]
For further information visit https://errors.pydantic.dev/2.9/v/model_type
result.list[VirtInstanceQueryResultItem].2.userns_idmap.gid
Input should be a valid dictionary or instance of IdmapUserNsEntry [type=model_type, input_value=None, input_type=NoneType]
For further information visit https://errors.pydantic.dev/2.9/v/model_type
result.VirtInstanceQueryResultItem
Input should be a valid dictionary or instance of VirtInstanceQueryResultItem [type=model_type, input_value=[{'id': 'apps1', 'name': ..., 'memory': 4294967296}], input_type=list]
For further information visit https://errors.pydantic.dev/2.9/v/model_type
result.int
Instances:
To clarify. This only happens when you have altered the incus configuration from shell?
I guess what I’m trying to get at, what has changed between RC.1 and Stable that has caused the configs that were working perfectly fine, to have changed and caused issues in the current build?
The userns_idmap’s for these were put in with the commands that you gave earlier on, so I don’t think it’s that, even though some of those validations are related to userns_idmap. Those do show up in Stable in the new UI.
What is volatile.idmap.current for your instance that’s breaking it?
1 Like
It’s all of them, but here is one:
[
{
"Isuid": true,
"Isgid": false,
"Hostid": 2147000001,
"Nsid": 0,
"Maprange": 568
},
{
"Isuid": true,
"Isgid": false,
"Hostid": 568,
"Nsid": 568,
"Maprange": 1
},
{
"Isuid": true,
"Isgid": false,
"Hostid": 2147000570,
"Nsid": 569,
"Maprange": 431
},
{
"Isuid": true,
"Isgid": false,
"Hostid": 1000,
"Nsid": 1000,
"Maprange": 1
},
{
"Isuid": true,
"Isgid": false,
"Hostid": 1001,
"Nsid": 1001,
"Maprange": 1
},
{
"Isuid": true,
"Isgid": false,
"Hostid": 2147001003,
"Nsid": 1002,
"Maprange": 457750
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 2147000001,
"Nsid": 0,
"Maprange": 568
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 568,
"Nsid": 568,
"Maprange": 1
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 2147000570,
"Nsid": 569,
"Maprange": 431
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 1000,
"Nsid": 1000,
"Maprange": 1
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 1001,
"Nsid": 1001,
"Maprange": 1
},
{
"Isuid": false,
"Isgid": true,
"Hostid": 2147001003,
"Nsid": 1002,
"Maprange": 457750
}
]
So if your run midclt call virt.instance.get_instance <instance name> all of them crash with ValidationError?
1 Like
Hrm, nope. Only one, apps3.
…and that’s a problem.
incus config show apps3|grep idmap
raw.idmap: |-
volatile.idmap.base: "0"
volatile.idmap.current: '[]'
volatile.idmap.next: '[]'
volatile.last_state.idmap: '[]'
Did you configure this one as a privileged container or something? What is full dump of incus config for apps3?
That was what I was about to say, that one is a one-off especial. It’s privileged because kasm requires it.
incus config show apps3|grep security
security.nesting: "true"
security.privileged: "true"
security.syscalls.intercept.mknod: "true"
security.syscalls.intercept.setxattr: "true"
There you go. We have a ticket to add support for privileged containers – maybe in 25.04.1.
1 Like
can you try to launch an instance with a file mount using shif=true ? I think it’s also a cause of the ui crash.
No, it’s not supported or needed. I took that out of the OP a long time ago. I’m trying to keep the configs in line with what IX is supporting so things don’t break too badly.
/me hides because I broke something badly...
1 Like
Will nesting be also supported ? (In the ui, I mean)
I mainly use Nixos and it require resting to work
You can use nesting, I actually have the enabled in the configs in the OP. Whether it hits the UI, would be a feature request.
Yep, I have seen it work, I am quite new to the truenas community, where can I open a feature request ?