Bug: Cannot build a tar layer on top of a squashfs layer #450
Comments
|
Honestly this makes no sense: We are opening the ${topdir}/oci as ocidir in umoci, then calling oci.PubBlob(), but it ends up trying to chown ${RootfsDir}/sha256_{blob} |
|
Ok, yeah, so the problem is in pkg/overlay/pack.go:generateBlob(), we take in the target layerType. If we are building a tar layer, then we call umoci/oci/layer.GenerateInsertLayer(), if squash then mksquashfs. But if we are building a tar layer from a squashfs source layer, then the overlay/ dir where we start is a mountpoint. Now umoci tries to chmod the parent dir +r, which fails bc it's a mountpoint. This only happens when we are re-building an intermediate layer - one which we already have as squash layer, but are now generating a tar layer for. Easiest is probably to detect the situation (using IsMountpoint()) and then convert slightly differently. |
If the inode is a mountpoint, chmod may just fail. (See project-stacker/stacker#450) Signed-off-by: Serge Hallyn <serge@hallyn.com>
|
Actually hallyn/umoci@922fdb3 fixes it for me |
If the inode is a mountpoint, chmod may just fail. (See project-stacker/stacker#450) Signed-off-by: Serge Hallyn <serge@hallyn.com>
If the inode is a mountpoint, chmod may just fail. (See project-stacker/stacker#450) Signed-off-by: Serge Hallyn <serge@hallyn.com>
If the inode is a mountpoint, chmod may just fail. (See project-stacker/stacker#450) Signed-off-by: Serge Hallyn <serge@hallyn.com> (cherry picked from commit ebe120e)
There is a PR against umoci#main to avoid trying to chmod +r when we don't need to. This will avoid trying to chmod +r on a mountpoint, which is the root cause of project-stacker#450. While we can and should also forward port our umoci dep to point at current main, we should not do that as part of this PR, as that will risk confusion if there are regressions from just the fwd port. Closes project-stacker#450 Signed-off-by: Serge Hallyn <serge@hallyn.com>
There is a PR against umoci#main to avoid trying to chmod +r when we don't need to. This will avoid trying to chmod +r on a mountpoint, which is the root cause of project-stacker#450. While we can and should also forward port our umoci dep to point at current main, we should not do that as part of this PR, as that will risk confusion if there are regressions from just the fwd port. Closes project-stacker#450 Signed-off-by: Serge Hallyn <serge@hallyn.com>
There is a PR against umoci#main to avoid trying to chmod +r when we don't need to. This will avoid trying to chmod +r on a mountpoint, which is the root cause of #450. While we can and should also forward port our umoci dep to point at current main, we should not do that as part of this PR, as that will risk confusion if there are regressions from just the fwd port. Closes #450 Signed-off-by: Serge Hallyn <serge@hallyn.com>
If the inode is a mountpoint, chmod may just fail. (See project-stacker/stacker#450) Signed-off-by: Serge Hallyn <serge@hallyn.com>
stacker version
v1.0.0-rc4-8e267fc
Describe the bug
Building the following stacker.yaml as root or non-root will fail with the stacktrace below.
The problem is with trying to build a tar layer from a source layer that is only published as squashfs.
You can avoid the problem by using
--layer-type=squashfsstacker.yaml:
To reproduce
Expected behavior
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: