Currently we do not insert the config read from image labels into the overall config data structure, so if you ask for a yaml file it will not include this info directly, only implicitly.

Better to make it all explicit in the generated version. This means moving how the configs are merged quite a bit.

I was excited to try a moby build -hyperkit 😁

I was upset to see it ignored and qemu was used instead 😕

I was even more confused to see that the hyperkit bool is completely ignored https://github.com/moby/tool/blob/master/cmd/moby/linuxkit.go#L129 😖

It'd be nicer to warn the user if it isn't supported or perhaps drop the flag until such time as it's implemented.

Looking at the YAML files in https://github.com/linuxkit/linuxkit there is an awful lot of repetition across them. We have discussed to simplify this with each package providing a template/default values which the user can override in the YAML file. In the best case the user then only needs to add two lines for a package either in the onboot or the services section containing the name and the reference to the image. This would greatly reduce the complexity of the YAML files while still allowing users to customise the settings to their needs.

It seems appropriate to store the default configuration in a label along with the image. The moby tool would then populate the internal representation of the package configuration from the label, before applying any overrides from the YAML file.

The proposal is to add a (optional) label org.mobyproject.config which contains a subset of the image specification in YAML format, very much like they are currently present in the YAML files, but without the name and the image entries. The moby tool would take the label contents and override them with any entries specified in the YAML file before passing it to the validator and further processing.

An alternative would be to provide each entry as a separate label, but this seems to complicate processing.

Example

Let's use the dhcp package as an example. The Dockerfile for the package would contain (may need some escaping of "s):

LABEL org.mobyproject.config="\
    binds:
     - /var:/var
     - /tmp/etc:/etc
    capabilities:
     - CAP_NET_ADMIN
     - CAP_NET_BIND_SERVICE
     - CAP_NET_RAW
    net: host
...

The a YAML file using the DHCP server in one-shot mode would look like:

...
onboot:
  - name: dhcpcd
    image: "linuxkit/dhcpcd:48e249ebef6a521eed886b3bce032db69fbb4afa"
    command: ["/sbin/dhcpcd", "--nobackground", "-f", "/dhcpcd.conf", "-1"]"
...

or if the user would like to start the dhcpd daemon as a service:

...
services:
  - name: dhcpcd
    image: "linuxkit/dhcpcd:48e249ebef6a521eed886b3bce032db69fbb4afa"
...

This is a feature request.

It would be great to have a variable system in the Linuxkit configuration file.

Of course an alternative is to use sed before building the image but I don't want to do that.

- Use case

My VM is in a custom network where 1.2.3.4 is the ip of my host. As you can see in my example, a DNS server and a Docker registry are bind to that ip.

linuxkit.yml:

services:
[...]
files:
  - path: /etc/docker/daemon.json
    contents: |
      {
        "insecure-registries": ["1.2.3.4:5000"],
        "dns": ["1.2.3.4"]
      }

My idea is to use a variables or args key in the configuration and then be able to reference them, like in the following example:

linuxkit.yml:

variables:
  hostip: "1.2.3.4"

services:
[...]
files:
  - path: /etc/docker/daemon.json
    contents: |
      {
        "insecure-registries": ["${hostip}:5000"],
        "dns": ["${hostip}"]
      }

Technically it could be a first pass during configuration parsing to "search and replace" these pattern. Another solution would be to replace them as you need to use the values but that would add unnecessary to every piece of the codebase.

If you don't want the replacement, you should be able to escape by adding a backslash before: \${hostip}.

Edit:
i'm using a Docker daemon to be able to start arbitrary images dynamically in the VM. Not a weird hack.

- A picture of a cute animal (not mandatory but encouraged)

Pulling an unsigned image when you have said you only want signed returns a very generic 401 error, it should specifically say the image is not signed, preferably with more details eg once we anable pinning.

cc @deitch who reported this

Pull image: linuxkit/compose-dynamic-example:de453299b70435f19372dc0b983d018a9501bc72
FATA[0148] Failed to extract root filesystem for linuxkit/compose-dynamic-example:de453299b70435f19372dc0b983d018a9501bc72: Could not pull image linuxkit/compose-dynamic-example:de453299b70435f19372dc0b983d018a9501bc72: Trusted pull for linuxkit/compose-dynamic-example:de453299b70435f19372dc0b983d018a9501bc72 failed: you are not authorized to perform this operation: server returned 401.
make: *** [dynamic] Error 1

cc @riyazdf

Friendlier if we have our own types (as we mostly do) as can handle special cases like user names etc.

It would be useful to be able to override the images that are specified in a config file.

In linuxkit, we want to do this in order to test changes to a package without having to manually update our growing number of configuration files.

It was suggested in linuxkit/linuxkit#2003 (comment) that an additional YAML file with the following format could be used to acheive this.

- source: linuxkit/dhcpcd
  substitute: linuxkitci/dhcpcd:testbuildhash

I've started an implementation (which I'll push shortly) that implements the above and makes the following assumptions:

1. The file will always be called override.yml
2. The override.yml is always specified after the main configuration file

If it's agreed that this feature is useful I'll be happy to update the implementation according to any design desicions that are made in this thread.

Terminology

• package: A moby package stored on hub
• repository: Source code repository (not hub repository)
• digest: The docker image digest, ie the SHA256
• git hash: The hash/id of a commit (git rev-parse HEAD)
• git tree hash: The content hash of a given directory, e.g git rev-parse HEAD:../$(notdir $(CURDIR)) in make
• git tag: The tag of the current HEAD if any, ie git describe --exact-match HEAD
  (note, we are using git here, but the proposal should be equally applicable to other modern source control systems, like mercurial.

Problem

The moby packages generated and used in LinuxKit currently use a unique content hash of the source files used to build the package (mostly the git tree hash) as a tag to uniquely identify package versions. We can't use the docker image digest as the builds are not 100% reproducible because the binaries may contain things like build time stamps etc.

We will likely extend this to also use version numbers in tags once we do releases. However for package builds in between releases we still want to use content hashes. We use content hashes (git subtree hashes) to check if we need to rebuild a package, ie if none of the files used to build the package have changed there is not need to rebuild and push a new version. However, we currently have no good and simple way to link a given package to a source code repository and a specific commit in that repository.

Proposal

We assume, though it is not essential, that packages, by default are tagged with the git tree hash (or some other hash), but not with the git hash. The git hash changes with every commit, ie commits which may not affect the contents of a package.

We propose to store the repository and the git hash in labels in the package, specifically under org.mobyproject.repository and org.mobyproject.commit. Note, that this affects the digest of the package.

Then, by inspecting the package (docker inspect), we can extract the repository and the git hash and thus directly link it to a specific version.

To build a package, we first need to check if the package tagged with the tree hash already exist, and only build it if it doesn't already exist. A package is always tagged and pushed with the tree hash.

If we tag a release in the repository, we can simply pull the package based on git tree hash, retag the package with the release tag and push the re-tagged package to hub. This does not affect the digest, nor the git commit stored in the image, so we can easily check if an image changed between releases.

An alternative proposal is to add the git hash (and possibly the repository) as notary metadata.

In linuxkit we have a whole bunch of YAML files which all need updating when hashes/tags change. It would be nice if there's only a few places which need updating. The proposal would be to add support for a .mobytags file which contains an entry per line specifying the tag for a given image. The moby tool would then look in the current directory and the user $HOME for the file and merge the tags into the YAML file before pulling. A command line option to explicitly specify the file would also be useful.

That way we can maintain one file in the top level of the linuxkit repository and maybe another in examples while things like the tests can just use the top-level file.

Currently moby build fails with:

FATA[0008] Failed to build init tarball from foo/bar:123: Could not pull image foo/bar:123: Error response from daemon: pull access denied for foo/bar, repository does not exist or may require 'docker login'

where foo/bar is a private repo on hub and I can docker pull is manually.

Looks like the moby build is not using authentication.

Sometime towards the end of last week moby build always started to pull images from hub even if the image was available in the local docker instance. For example:

% moby version
moby version 0.0
commit: b822bff6adcf03408ec019dfee9401fb58624951
% docker images linuxkit/init:1b8a7e394d2ec2f1fdb4d67645829d1b5bdca037
REPOSITORY          TAG                                        IMAGE ID            CREATED             SIZE
linuxkit/init       1b8a7e394d2ec2f1fdb4d67645829d1b5bdca037   8bf318bfb8fe        32 hours ago        1.46MB
% moby build linuxkit
Pull kernel image: linuxkit/kernel:4.9.x
Extract kernel image: linuxkit/kernel:4.9.x
Pull image: linuxkit/kernel:4.9.x
Add init containers:
Process init image: linuxkit/init:1b8a7e394d2ec2f1fdb4d67645829d1b5bdca037
Pull image: linuxkit/init:1b8a7e394d2ec2f1fdb4d67645829d1b5bdca037
...

This pulled linuxkit/init:1b8a7e394d2ec2f1fdb4d67645829d1b5bdca037 even though its locally available. This slows down moby builds a lot.

I haven't had time to bisect, but I think it was sometime around the trust fixes.

/ping @riyazdf

Ideally we would generate bootable ISOs from Go - writing an ISO filesystem is not horribly complicated. This would be simpler than generating them in Docker or LinuxKit.

Its still a fair amount of work. EFI ISOs are a lot more work than BIOS - needs FAT as well.

(This came from discussion at Edinburgh Docker meetup)

Need to have the ability to build in a container (without Docker socket access). Example is in AWS Codebuild pipeline.

Currently Docker is needed for some output formats, more work needs doing on the linuxkit based outputs but these do work with qemu.

Secondly it is needed to extract image filesystems. We should switch to containerd for these; either using image store, or filesystem as now, or filesystem layers that get mounted later.

Trust is broken on Windows sadly, which we missed as no CI.

If the YAML file specifies trust for specific images or all images from an org, it is harder for developers to test locally modified packages. It'll also be harder for CI systems which would push packages from a PR to a local registry to test them.

I think it would be good to add a way to globally disable content trust checks for builds.

This is a general topic, opened per request by @justincormack, to discuss composition patterns. It also is intended as a general discussion place for the right way to make things capable like #89 opened by @samoht .

/cc: @rn

In docker, if we need to add some binaries (e.g. ssh client or git) to an existing standard image (e.g. nginx), we use a Dockerfile and extend it with FROM.

For building linuxkit images using moby, we may not want or be able to do so with custom extension images. Moby's purpose is a tool to "compose" to "weave" together various OCI images to create a new image. In the case of LinuxKit, that is a bootable OS image (although it could be generalized to other non-OS cases as well).

Moby currently supports the following composition patterns:

• Single kernel, init, onboot, services, files
• files as stacked (all appear on "root" filesystem, sequential)
• init as stacked (all appear on "root" filesystem, sequential)
• onboot and services as separate (each in own filesystem, parallel)

#89 was requesting a new pattern, wherein onboot and/or services can be stacked. Essentially, it is trying to solve the "I need this standard image with the capabilities of a few more mixed in." It is similar to the mixin capabilities of some programming languages.

Another example is tools availability on login. The standard linuxkit/getty and linuxkit/sshd images provide standard services. If someone needs, e.g. the git client or some other tools available at login, the only ways to provide them are messy:

• Install in the underlying host and bind-mount - brittle and pollutes the underlying host filesystem, undesired
• extend the getty or sshd image with your own which adds the tools, and use that in your .yml instead of standard getty or sshd - also brittle and easy to lose track, when all you want is one package

#89 proposed stacking layers for services like we stack for onboot. There are alternate ways of doing this. However, I believe we do need a way for moby to weave together images.

In a larger sense, I think moby needs to be able to weave without config files at all, e.g. moby build https://github.com/foo/bar/foo.yml --std getty,git --files ...

That may not be the best example, and there are ways to change that, but the general sense of weaving together existing "templates" and images without actually extending each one is important. This could be generalized to docker build ... as well?

The #216 PR makes sure created tar files are using PAX format (because Go 1.10 changed the default format to USTAR instead which can't accomodate long filenames), but when processing the incoming image tar, it blindly reuses whatever format the original header format was for a given file.
This is dangerous because either with links or realname the prefix is added and we might cross the USTAR limit (if the incoming file was USTAR encoded), generating an error when adding the file to the archive, as seen here:

DEBU[0046] image tar: docker.elastic.co/elasticsearch/elasticsearch:5.6.10 containers/services/elasticsearch/lower/ add usr/lib/python2.7/site-packages/chardet/charsetgroupprober.pyc
DEBU[0046] image tar: docker.elastic.co/elasticsearch/elasticsearch:5.6.10 containers/services/elasticsearch/lower/ add usr/lib/python2.7/site-packages/chardet/charsetgroupprober.pyo
DEBU[0046] image tar: archive/tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode Linkname="containers/services/elasticsearch/lower/usr/lib/python2.7/site-packages/chardet/charsetgroupprober.pyc" write header error
DEBU[0046] docker rm: 34428aae2600a6cdff5e6c6466177fb4c3671ae38f701f8f95757f0d691f788f
DEBU[0046] docker rm: 34428aae2600a6cdff5e6c6466177fb4c3671ae38f701f8f95757f0d691f788f...Done
FATA[0046] Failed to extract root filesystem for docker.elastic.co/elasticsearch/elasticsearch:5.6.10: archive/tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode Linkname="containers/services/elasticsearch/lower/usr/lib/python2.7/site-packages/chardet/charsetgroupprober.pyc"

A moby build test/test-ltp.yml from the linuxkit/linuxkit sometimes fails with:

Failed to create config.json for linuxkit/poweroff:961412b8ef5c5285de0d40ec076701d955eaa084: fork/exec /usr/bin/docker: cannot allocate memory`

It's not easy to reproduce and but has been seen a few times locally on Docker for Mac (edge) and also on our LinuxKitCI system

Hi there,

Seems it's currently not possible to create empty files in the files section. Moby complains if I omit the contents property, and if I try to put an empty string ''.

I use go get -u github.com/moby/tool/cmd/moby to install moby tool but find something error.

goproject/src/github.com/moby/tool/cmd/moby/trust.go:186: undefined: x509.SystemCertPool

OS distribution
CentOS Linux release 7.3.1611 (Core)

go version
go version go1.6.3 linux/amd64

It would be nice to be able to moby build -o ./_build linuxkit.yml and have the output nicely contained in a folder instead of the pwd.

My use case is for CI and testing of LinuxKit... where I want to build a yml file and place the output in a common directory that can be accessed by other tests.

With the moby tool allowing concatenation of YAML files and various other proposals to compose YAML files (e.g., #101, #95, #92) we should have a way to generate a single YAML file to re-create the output. This "fully qualified" YAML file should have the full hashes as well as the sha256 of each image used as well as the moby tool version and possible command line invocation (#106).

The moby tool should be able to write the YAML and also add it the image.

(this issue supersedes linuxkit/linuxkit#1231)

I did a:

docker run --rm -ti -v $(pwd):/go/src/github.com/moby/tool golang:1.9.2-alpine

and then in the container:

cd /go/src/github.com/moby/tool
apk add --no-cache make git
go get -u github.com/alecthomas/gometalinter
gometalinter --install

Then:

/go/src/github.com/moby/tool # make
gometalinter --config gometalinter.json ./...
../../../../../usr/local/go/src/net/lookup_unix.go:80:24:warning: undeclared name: cgoLookupHost (interfacer)
../../../../../usr/local/go/src/net/lookup_unix.go:95:24:warning: undeclared name: cgoLookupIP (interfacer)
../../../../../usr/local/go/src/net/lookup_unix.go:107:23:warning: undeclared name: cgoLookupPort (interfacer)
../../../../../usr/local/go/src/net/lookup_unix.go:123:24:warning: undeclared name: cgoLookupCNAME (interfacer)
../../../../../usr/local/go/src/net/lookup_unix.go:190:23:warning: undeclared name: cgoLookupPTR (interfacer)
../../../../../usr/local/go/src/net/lookup_unix.go:80:24:warning: undeclared name: cgoLookupHost (unconvert)
../../../../../usr/local/go/src/net/lookup_unix.go:95:24:warning: undeclared name: cgoLookupIP (unconvert)
../../../../../usr/local/go/src/net/lookup_unix.go:107:23:warning: undeclared name: cgoLookupPort (unconvert)
../../../../../usr/local/go/src/net/lookup_unix.go:123:24:warning: undeclared name: cgoLookupCNAME (unconvert)
../../../../../usr/local/go/src/net/lookup_unix.go:190:23:warning: undeclared name: cgoLookupPTR (unconvert)
../../../../../usr/local/go/src/net/lookup_unix.go:80:24:warning: parameter undeclared name: cgoLookupHost (unparam)
../../../../../usr/local/go/src/net/lookup_unix.go:95:24:warning: parameter undeclared name: cgoLookupIP (unparam)
../../../../../usr/local/go/src/net/lookup_unix.go:107:23:warning: parameter undeclared name: cgoLookupPort (unparam)
../../../../../usr/local/go/src/net/lookup_unix.go:123:24:warning: parameter undeclared name: cgoLookupCNAME (unparam)
../../../../../usr/local/go/src/net/lookup_unix.go:190:23:warning: parameter undeclared name: cgoLookupPTR (unparam)
make: *** [Makefile:29: lint] Error 1

and:

/go/src/github.com/moby/tool # make GOOS=darwin
gometalinter --config gometalinter.json ./...
?   	github.com/moby/tool/cmd/moby	[no test files]
?   	github.com/moby/tool/src/initrd	[no test files]
fork/exec /tmp/go-build200172941/github.com/moby/tool/src/moby/_test/moby.test: exec format error
FAIL	github.com/moby/tool/src/moby	0.004s
?   	github.com/moby/tool/src/pad4	[no test files]
make: *** [Makefile:32: test] Error 1

I get the same error when using the gometalinter SHA used in circleci

I tried to add a private image to my .yml file but the moby build fails with Error response from daemon: repository <image> not found: does not exist or no pull access. If I manually docker pull <image>:<tag> it first then it works fine.

I notice the moby tool supplies an empty ImagePullOptions where we could in theory fill in a PrivilegeFunc. I don't know whether the moby tool should try to re-use the same mechanisms and credentials as the docker CLI or do its own thing.

Per @justincormack comment on linuxkit/linuxkit#1847, re-raising here.

Given multiarch support is to be used for the containers that feed into building an image, how is architecture selected if "cross-building" (that is, running the moby tool on architecture A to create an image to boot architecture B)?

My proposal would be ability to set a list of architectures to build in the config, defaulting to the host architecture if unspecified. Something like

arch: [ arm64, x86_64 ]

...though whether as a top-level key or made as a subkey TBD. (And I'm not a YAML expert so there may be better syntactic forms.)

In terms of repeatability, it seems better to me to make it a config file thing rather than a command line thing, but YMMV :)

If I specify a Runtime section in my yml then it overrides the entire runtime provided by the pkg in the org.mobyproject.config label on the image, even though the image defines only runtime.mkdir and the yml only overrides runtime.bindns.

Looking at the code in config.go it looks like oci.Linux is handled properly by unpacking one level. Should runtime do the same? It looks like Resources might be in a similar situation too.

I wonder if it would be possible to write a generic struct merger using reflection or if such a thing already exists.

Previously we had hashes for these but since #137 there is a multi arch one which is signed so we should enable content trust. Just a matter of plumbing through the trust config to docker run.

We should allow for pinning the root key for trust repos, ex: all individual official images are signed with differing root keys and all of linuxkit's repos are signed with the same root key.

This could manifest itself in the configuration as a subkey under invidivdiual image and org subsection entries in trust

Still determining the best format, but perhaps something like this which will let us further expand the trust section:

trust:
  org:
    - name: linuxkit
    rootKey: 1908a0cf4f55710138e63f65ab2a97e8fa3948e5ca3b8857a29f235a3b61ea1b
  image:
    - name: nginx
    rootKey: d2f02ea35ebffce87d31673efbff44c199b1af0be042989d4655a176e8aad40d

Currently we can specify multiple layers for the init image, but not for onboot or services images. Would be great to allow this as well.

We currently unconditionally untar kenrel.tar from the kernel docker images into the initrd root filesystem. On some systems, like the LCOW utility VM, we don't need the kernel modules so having an option to not include them would save significant amount of space with current LinuxKit packages.

This is a bit of a hack and probably should be more generally addressed by implementing more specialised kernels in LinuxKit but it seems like a good short term fix which shouldn't do much harm to other builds to initially provide it with moby

Description

For a less surprising developer experience capabilities: none could be supported to mirror the capabilities: all setting.

Steps to reproduce the issue:

Add capabilities: none to a LinuxKit YML file.

Describe the results you received:

Invalid for target.

Describe the results you expected:

Acts in the same way as if nothing was supplied. If none is one of the options then this should be mutually exclusive with any other option.

cc @justincormack

I saw the schema supports "strings" - so the error is probably not coming from the validator.

https://github.com/moby/tool/blob/master/cmd/moby/schema.go

I think this would change - to mirror the 'all' behaviour:

https://github.com/moby/tool/blob/master/cmd/moby/config.go#L312

Happy to take a stab at this change myself.

For some kernel debugging, in particular with perf, it would be useful to optionally include the uncompressed/unstripped vmlinux file to the rootfs if present in the kernel package

This commit: bb7cbce
is pretty much breaking when moby build an ISO for both bios and efi.

It results in a 0-size iso file.

Maintaining a bunch of yaml files is really mess: linuxkit/linuxkit#1701

So I suggest supporting inheritance (see also https://learnxinyminutes.com/docs/yaml/)

Example

{{import ./minimal.yml minimal}}
services:
  <<: *minimal_services
  - name: additional-foobar
     image: "additional-foobar/baz:deadbeef"
     ...

My linuxkit configuration YAML file:

[...]
files:
  - path: /etc/hosts
    contents: |
      10.0.0.0       foo

I expected this configuration to modify the /etc/hosts file but it seems that the moby build command is already providing one:

and It can't be modified.

Is there any reason behind this? Or could we remove it?
For my use case it would suffice to just being able to appending new lines to the file.

Should analyse package metadata for a spec and output license information.

This will need additional metadata in packages, as we have stripped the apk info from the packages, will probably need to put some back.

See also the previous license tooling that is in the linuxkit git history.

The aim should be sufficient to include BSD style acknowledgements, plus source code links for GPL code, as a minimum.

I have a file-entry in system.yml:

files:
- path: var/lib/tftpboot/boot.ipxe
  source: snponly.efi

On moby build system.yml I get the following error:

The configuration file is invalid:
- source: Additional property source is not allowed
FATA[0000] Invalid config: invalid configuration file

Recent builds of the moby tool aren't working properly with my LinuxKit images. Everything appears to build ok, but when I run the output, all of the containers fail to start. They all fail with errors similar to this:

FATA[0000] failed to create task error="rpc error: code = Unknown desc = runtime create failed: runc create failed: target os mismatch with current os linux" service=rngd

Screen shot:

I see the same result with the example yml files in the linuxkit repo. The yml file I'm using here is just the linuxkit.yml file in the base linuxkit/linuxkit directory (swapping tty0 and ttys0 around so I get output in virtualbox):

kernel:
  image: linuxkit/kernel:4.9.36
  cmdline: "console=ttyS0 console=tty0"
init:
  - linuxkit/init:14a38303ee9dcb4541c00e2b87404befc1ba2083
  - linuxkit/runc:2310ad9d266cf5d9c4d07613bd2135ed7eb8a21f
  - linuxkit/containerd:c977f27c234d55b85172813b8451f67ea86be4a3
  - linuxkit/ca-certificates:67acf038c44bb191ebb704ec7bb39a1524052cdf
onboot:
  - name: sysctl
    image: linuxkit/sysctl:d1a43c7c91e92374766f962dc8534cf9508756b0
  - name: binfmt
    image: linuxkit/binfmt:0bde4ebd422099f45c5ee03217413523ad2223e5
  - name: dhcpcd
    image: linuxkit/dhcpcd:4b7b8bb024cebb1bbb9c8026d44d7cbc8e202c41
    command: ["/sbin/dhcpcd", "--nobackground", "-f", "/dhcpcd.conf", "-1"]
services:
  - name: getty
    image: linuxkit/getty:5ab31289889d61a5d2ecbeea8e36ce74ac54737c
    env:
     - INSECURE=true
  - name: rngd
    image: linuxkit/rngd:1516d5d70683a5d925fe475eb1b6164a2f67ac3b
  - name: nginx
    image: nginx:alpine
    capabilities:
     - CAP_NET_BIND_SERVICE
     - CAP_CHOWN
     - CAP_SETUID
     - CAP_SETGID
     - CAP_DAC_OVERRIDE
files:
  - path: etc/containerd/config.toml
    contents: |
      state = "/run/containerd"
      root = "/var/lib/containerd"
      snapshotter = "io.containerd.snapshotter.v1.overlayfs"
      differ = "io.containerd.differ.v1.base-diff"
      subreaper = false

      [grpc]
      address = "/run/containerd/containerd.sock"
      uid = 0
      gid = 0

      [debug]
      address = "/run/containerd/debug.sock"
      level = "info"

      [metrics]
      address = ":13337"
trust:
  org:
    - linuxkit
    - library

Build command is:
moby -v build -name linuxkit -output dynamic-vhd linuxkit.yml

I've tried with output types vhd, dynamic-vhd, and vmdk. All produce the same result.

I went through the moby tool git history by commit and built/tested with different versions of the tool. It starts failing when commit c3edfec75915d993c76e4a52dcffb4d2278e1da3 was added. All builds before that commit work fine. Any idea what's causing this? Seems like runc is expecting something that doesn't exist.

The current tool supports iso-efi and raw. raw works only with bios, while iso-efi only works on CD/DVD media (or something that can read it. Booting iso-efi off of a flash drive, e.g. will not work.

We should support EFI bootable disk drives. It can be one of:

• make iso-efi bootable as disk (there is a way to do it, not fresh in my mind at the moment but can find it)
• make a new output format efi-disk (or efi-raw?) that has a drive image with an EFI partition
• make a new output form efi-disk (or efi-raw?) where the kernel itself is an efi image and thus directly bootable
• some other way?

We need this file as internal legal approval(for inbound license or agreement for contributions to project), but this file is missed in moby/tool project. Can anyone help us out that?

Hi,
I'm building RaspberryPI3 images with linuxkit through linuxkit-server.
To make building the sdcard as easy as possible, I added to linuxkit-server capability to request the output in img-file what users can easily flash to sd-card for example with dd.

I would like to build support for defining disk partitions in the linuxkit yaml-file, but cannot because linuxkit build fails because it doesn't allow any extra fields to exist in the yaml-file.

My options are:

1. Change moby/tool schema to allow extra fields (change here additionalProperties=true)
2. unmarshal yaml, drop extra fields, marshal back to []byte and call Moby
3. Something else?

It's quite common for example in JSON APIs to ignore extra fields, so maybe also, in this case, it make sense. What do you think? It would allow the community to build extra features on top of Moby/Linuxkit what is not suitable to be merged into the core.

I tried to use Runtime.Mnt to make a service's root appear as /run/mntns/cri as part of an experiment but trying to use it fails:

# nsenter -m/run/mntns/cri ash -l
nsenter: reassociate to namespace 'ns/mnt' failed: Invalid argument

I also tries making the mount point a directory (by default it is a file) but that didn't help.

https://stackoverflow.com/questions/34783391/why-i-couldnt-use-mount-bind-proc-pid-ns-mnt-to-another-file-in-ubuntu suggests the bind mounting /proc/N/ns/mnt to somewhere is more complicated than the other ns's (thankfully it appears to be unique to mnt namespaces).

I would like to "bundle" a local Docker image into my final image. Currently only pulls from public registry is supported:

I also tried to use a temporary private registry instead but ended up with: #104.

Relevant comment I found in the source:

Apart from that I don't see any technical restrictions, I hope there isn't some marketing for the public registry involved.

Edit:
I have the following error when I'm trying to build the image: FATA[0032] Failed to extract root filesystem for smth:latest: Could not pull image smth:latest: Trusted pull for smth:latest failed: you are not authorized to perform this operation: server returned 401.

Use, for example linuxkit.yml (with cmdline changed to just "console=ttyS0") and then moby build -output iso-efi linuxkit.yml on both macOS and Windows.

The iso build on Windows will not get a console while the one build on macOS will. Tested with linuxkit run linuxkit-efi.iso on Windows and linuxkit run hyperkit -iso -uefi linuxkit-efi2.iso on hyperkit. In fact it looks like none of the system containers are started (no INFO[0000] shim containerd-shim started messages)

This was first report here: linuxkit/linuxkit#2401

While adding trust entries for packages as part of linuxkit/linuxkit#1909 I noticed that some YAML files had entries which did not match any images listed in the image.

I think we should make the build error out in this case as it forces tighter, more correct YAML files

@riyazdf WDYT?

The trust code that reads the system cert pool will need to be refactored for a _windows.go platform that handles the certificate pool differently, since crypto/x509.SystemCertPool is not supported on Windows:

C:\code\linuxkit\blueprints [master ≡]> moby -v build lcow.yml
DEBU[0000] Outputs selected: [kernel+initrd]
DEBU[0000] validating output: [kernel+initrd]
INFO[0000] Extract kernel image: linuxkit/kernel:4.11.9
DEBU[0000] image tar: linuxkit/kernel:4.11.9
DEBU[0000] docker pull: linuxkit/kernel:4.11.9
DEBU[0000] pulling linuxkit/kernel:4.11.9 with content trust
DEBU[0000] failed to reach https://notary.docker.io notary server for repo: docker.io/linuxkit/kernel, falling back to cache: crypto/x509: system root pool is not available on Windows
FATA[0000] Failed to extract kernel image and tarball: Could not pull image linuxkit/kernel:4.11.9: Trusted pull for linuxkit/kernel:4.11.9 failed: client is offline

cc @friism

At present only kernel+initrd and tarball builds work. Fix the others to use multiarch images.

Sally and Jim both work off the same repo, and therefore identical .yml file. Both run moby build <file>. Outputs could be non-identical because of different moby versions.

Do we want to indicate a required or minimum moby tool version in the .yml file, similar to how some language packaging frameworks indicate a minimum or absolute language version (e.g. engines field in package.json).

This could get messy with #96 , although to be fair, I think if two .yml files specify conflicting moby versions, it should fail.

Additionally, it may lead to issues regarding actual versioning.

Finally, it would be nice if we could somehow label the produced images to indicate which moby version was used to build it. There is no standard for adding labels to os images, but even putting it into a file in the build /etc/moby.build or similar would be worthwhile.

Is there a docker image for use for the moby tool?

I'm aware that a lot of people are currently building there own from source but it would be nice to have a "semi-official" image to pull from.

I suggest adding include syntax (as Golang text/template function)

Example usecase

before (https://github.com/linuxkit/linuxkit/blob/master/examples/sshd.yml):

files:
  - path: root/.ssh/authorized_keys
    contents: '#your ssh key here'

after:

files:
  - path: root/.ssh/authorized_keys
    contents: {{include ~/.ssh/id_rsa.pub}}

Path resolution

• Absolute path (including one starts with ~/): resolved to the file specified by the absolute path. Maybe woth adding moby build --disallow-include-absolute-path for security reason
• Relative path starts with ./ (or .\ on Windows): resolved to the file specified by the relative path
• Others (e.g. foo.yaml.snippet, foo/bar.yaml.snippet): resolved to one of the files under the following paths: ~/.moby/include, /usr/local/share/moby/include...