Failed to start virtiofsd error wtih lxd 5.21.1 LTS #13325
Comments
mihalicyn
added a commit
to mihalicyn/lxd
that referenced
this issue
Apr 15, 2024
…mapping only if it's required
Fix diskAddRootUserNSEntry logic to correcly handle case when
we have not-groupped UID/GID mapping like this:
[{true false 1000 0 1} {false true 1000 0 1}]
because right now it assumes that mapping should be like
[{true true 1000 0 1}]
which is logically equivalent.
This become noticable after my change in canonical#12718, before that
this issue in logic was reproducible only if user will do something like this:
cat << EOF
uid $(id -u) 1000000
gid $(id -g) 1000000
EOF
) | lxc config set idmap raw.idmap -
which is an extremely rare usecase.
Fixes: canonical#13325
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
|
Hi @aludman !
Ugh, this is really painful. Sorry about that. I have created a PR with the fix for this problem #13332 |
tomponline
pushed a commit
to tomponline/lxd
that referenced
this issue
Apr 16, 2024
…mapping only if it's required
Fix diskAddRootUserNSEntry logic to correcly handle case when
we have not-groupped UID/GID mapping like this:
[{true false 1000 0 1} {false true 1000 0 1}]
because right now it assumes that mapping should be like
[{true true 1000 0 1}]
which is logically equivalent.
This become noticable after my change in canonical#12718, before that
this issue in logic was reproducible only if user will do something like this:
cat << EOF
uid $(id -u) 1000000
gid $(id -g) 1000000
EOF
) | lxc config set idmap raw.idmap -
which is an extremely rare usecase.
Fixes: canonical#13325
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
|
This is now cherry-picked into the 5.21/stable snap channel. |
tomponline
pushed a commit
to tomponline/lxd
that referenced
this issue
Apr 17, 2024
…mapping only if it's required
Fix diskAddRootUserNSEntry logic to correcly handle case when
we have not-groupped UID/GID mapping like this:
[{true false 1000 0 1} {false true 1000 0 1}]
because right now it assumes that mapping should be like
[{true true 1000 0 1}]
which is logically equivalent.
This become noticable after my change in canonical#12718, before that
this issue in logic was reproducible only if user will do something like this:
cat << EOF
uid $(id -u) 1000000
gid $(id -g) 1000000
EOF
) | lxc config set idmap raw.idmap -
which is an extremely rare usecase.
Fixes: canonical#13325
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
tomponline
pushed a commit
to tomponline/lxd
that referenced
this issue
Apr 17, 2024
…mapping only if it's required
Fix diskAddRootUserNSEntry logic to correcly handle case when
we have not-groupped UID/GID mapping like this:
[{true false 1000 0 1} {false true 1000 0 1}]
because right now it assumes that mapping should be like
[{true true 1000 0 1}]
which is logically equivalent.
This become noticable after my change in canonical#12718, before that
this issue in logic was reproducible only if user will do something like this:
cat << EOF
uid $(id -u) 1000000
gid $(id -g) 1000000
EOF
) | lxc config set idmap raw.idmap -
which is an extremely rare usecase.
Fixes: canonical#13325
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
hamistao
pushed a commit
to hamistao/lxd
that referenced
this issue
Apr 18, 2024
…mapping only if it's required
Fix diskAddRootUserNSEntry logic to correcly handle case when
we have not-groupped UID/GID mapping like this:
[{true false 1000 0 1} {false true 1000 0 1}]
because right now it assumes that mapping should be like
[{true true 1000 0 1}]
which is logically equivalent.
This become noticable after my change in canonical#12718, before that
this issue in logic was reproducible only if user will do something like this:
cat << EOF
uid $(id -u) 1000000
gid $(id -g) 1000000
EOF
) | lxc config set idmap raw.idmap -
which is an extremely rare usecase.
Fixes: canonical#13325
Signed-off-by: Alexander Mikhalitsyn <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Required information
Ubuntu20.04.6 LTSNote that this is from after we have reinstalled 5.20 since I do not want to go back and break ths system just so I can get this information. The problem is very easily reproduced using the steps further below.
lxcinfo.txt
Issue description
We're unable start / exec to our lxd vms after an automatic refresh of lxd snap from 5.20 to 5.21.1.
The error we get is the following:
I was expecting the system to work as before after the automatic update.
Reverting back to 5.20 using
sudo snap revert lxdresulted in lxd not working at all, so we ended up uninstalling lxd completely and reinstalling the 5.20 version and recreating everything from scratch, which resolved our issue.Steps to reproduce
The problem is reproducible on our system by following these basic steps:
The key step is the
lxc config set test raw.idmapstep. If I skip that then the instance starts up just fine.The
lxc config set test limits.cpu=8 limits.memory=4GiBstep is probably not important but it was part our steps, so I've included it.The text was updated successfully, but these errors were encountered: