Re: [atomic-devel] We are looking at using OSTree as a backend for sharing file systems into an OCID Container runtime

[Colin Walters <walters verbum org>]

On Fri, Oct 14, 2016, at 02:37 PM, Daniel J Walsh wrote:

> If we block the creation of the devices when exploding a OCI Image
> Bundle, we end up with something that is different then what is
> downloaded and this could potentially cause problems with mtree checking
> of the image on disk versus the image as shipped.

https://github.com/ostreedev/ostree/pull/443
would be a good place to discuss this.

> Is there a reason OSTree does not work with Device Inodes? 

Yes, I think there's no good reason to include devices in OS or container
images.  For OS images (i.e. ostree-as-base), all modern systems
use devtmpfs. 

(Also for that matter, a bit more strictly, FIFOs either.
 OSTree very intentionally only supports regular files and
 symlinks)

For the Ubuntu Docker image, the user can't even see them
because Docker (correctly) mounts over /dev/ with
the "API devices" as systemd calls them.

So basically...my proposal would be that we
ignore them, and that's indeed what the proposed OSTree
API above does.

If we implement any other verification layer like mtree, it
should then just skip devices and FIFOs (or more generally
anything except regular files and symlinks).