Closed cjwatson closed 7 months ago
FWIW it's not a recent change in Debian unstable, since incus launch images:debian/bookworm/amd64 test
behaves the same way.
You must likely have conflicting/overlapping entries for the root user in /etc/subuid and/or /etc/subgid
We fixed our idmap parsing package with Incus 0.5 as older versions were incorrectly only picking the first entry for every user, causing issues for those needing to split the allocation due to having reserved chunks of uids and gids for things like remote authentication.
The downside of this fix is that if your root user has multiple ranges that are at least 65k id large, then they'll all be picked up, if those overlap, then the kernel will say no.
Here's my /etc/subuid
(/etc/subgid
is similar):
root:1000:1
root:100000:65536
statd:110000:10000
postgres:120000:10000
[local users redacted]
lxd:165536:65536
root:165536:65536
# empty default subuid/subgid file
[another local user redacted]
root:1000000:1000000000
I deleted all but the last of those entries for root, restarted incus.service
, and it works now, but that was quite weird. According to my etckeeper logs, all but the last of those entries date back to before June 2017 (when I installed etckeeper on this machine); the last one was created automatically when I switched to Incus.
Could this be retroactively added to https://discuss.linuxcontainers.org/t/incus-0-5-has-been-released/18814, maybe? I looked there before filing a bug, and I'm guessing I'm not the only one with bits inherited from several years ago ...
Yeah, I'll add a mention to the announcement as we've indeed had maybe 3-4 people reach out so far with similar issues
Added now.
Thanks you, I just go the same issue here.
same issue here (bookwork 0.6-1~bpo12+1)
Required information
Issue description
I switched from LXD to Incus a while ago, and things were working fine with 0.4.0. As far as I know I haven't changed anything other than applying routine upgrades, and am now on Incus 0.5.1. I tried to start a container this afternoon and it failed with
newuidmap failed to write mapping "newuidmap: write to uid_map failed: Invalid argument"
; I don't seem to be able to get any container to start, even a new one with no interesting configuration.As far as I know I'm not doing anything custom with ID mapping, at least not in my default profile.
Steps to reproduce
Information to attach
dmesg
shows nothing at all in the relevant time period.The main daemon log just says
time="2024-01-31T13:12:14Z" level=error msg="Failed starting instance" action=start created="2024-01-31 13:12:13.26877479 +0000 UTC" ephemeral=false instance=test instanceType=container project=default stateful=false used="1970-01-01 00:00:00 +0000 UTC"
.incus --debug start test
andincus monitor --pretty
seem to just reproduce the information above in different forms, but I can provide them if needed.