3.17.1 tracker #1886
Assignees
Comments
|
@Snorch could you take a look at the mount-v2 issue? |
|
I believe that it's not an issue of mount-v2 but sort of bad external mounts configuration. If criu dumps two mounts having exact the same shared group on dump, and on restore these mounts appear to have different superblocks due to bad external mount options, criu can't do anything but fail. |
|
Concerning opencontainers/runc#3442: I am a bit afraid that we might break many existing runc/CRIU installation if CRIU is upgraded to 3.17. Maybe we need to think about to default to runc often seems to be tied to the container stack and might not be updated regularly. CRIU might come as a normal OS update and would then break the container checkpoint/restore. @checkpoint-restore/maintainers any comments on defaulting to |
Snorch
added a commit
to Snorch/criu
that referenced
this issue
May 18, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between to mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
|
@adrianreber If we have no other choice yes we can switch to compat by defaul. Though leaving mount-v2 by default will help us track all these tricky cases about which I forgot (didn't though). Please try this w/a #1898 maybe it would help to runc. |
|
Having a fix sounds much better than disabling. I will test your fix tomorrow. Thanks. |
Snorch
added a commit
to Snorch/criu
that referenced
this issue
May 19, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between to mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
|
This works for me. Thanks! @avagin what do you think? PTAL. |
Snorch
added a commit
to Snorch/criu
that referenced
this issue
May 31, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin
pushed a commit
that referenced
this issue
Jun 13, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. #1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
|
We also would want to have #1918 in 3.17.1 once it has been merged. |
adrianreber
pushed a commit
to adrianreber/criu
that referenced
this issue
Jun 20, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Merged
adrianreber
pushed a commit
to adrianreber/criu
that referenced
this issue
Jun 20, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
adrianreber
pushed a commit
to adrianreber/criu
that referenced
this issue
Jun 20, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. checkpoint-restore#1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
avagin
pushed a commit
that referenced
this issue
Jun 22, 2022
…root It's a problem when while restoring sharing group we need to copy sharing between two mounts with non-intersecting roots, because kernel does not allow it. We have a case opencontainers/runc#3442, where runc adds different devtmpfs file-bindmounts to container and there is no fsroot mount in container for this devtmpfs, thus mount-v2 faces the above problem. Luckily for the case of external mounts which are in one sharing group and which have non-intersecting roots, these mounts likely only have external master with no sharing, so we can just copy sharing from external source and make it slave as a workaround. #1886 Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
|
@adrianreber I think we can close this issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are a couple of problems in 3.17 which probably means we need a 3.17.1 release:
The text was updated successfully, but these errors were encountered: