This is the same as aufs variant, but without AUFS patches. Looks like
GCP may need this, at least initially.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- Add back Linux kernel 4.4.x support, only for AUFS at present.
- Add back config options that are different for 4.4 series
See #923 for discussion on whether we need to do this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
These headers are needed for defining kernel probes etc, tested with
eBPF. Could also be used for perf, building kernel modules etc. Saved
to the media tarball at present, may add to base image or container.
Also rationalise the paths in the headers tarball a little to match.
Will add an eBPF container using these later.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Saves passing too much context, less error prone and should
mean builds are faster if not clean, consistent with elsewhere.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Non AUFS kernels do not create `sbin/` and `/usr` directories as they
do not provide the AUFS directories. Just create empty directories to
avoid a warning.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This seems the best option, although none are great
- build with `make AUFS=1` to build with AUFS support, currently with 4.8 kernel
- default is to build without AUFS support, with 4.9 kernel
This recognises that AUFS supprot is temporary #620 and only there until
we can phase it out on desktop editions, and allow the other editions that
never shipped with AUFS to ship something very close to mainline.
However we do still apply the patches so that the non AUFS branch runs fine on
all platforms, so it can be tested elsewhere.
We may be able to move the kernel versions back in line when 4.9 aufs support is out.
Plan is to shift CI to build both sets of images, and get the Desktop editions to
pick up the aufs set automatically, once this is merged.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- The scanning process was not ignoring the kernel extraversion before,
so was only sometimes picking up issues.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This means that multiple builds will not conflict, so we can
remove the lock from the CI. Also quieter when no errors.
Some still left to do, only done the ones used in build and CI
initially. Some of the others will be cleaned up anyway later.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
See #449. Plan is to use upstream Alpine kernel for Arm, as
does not need vsock, hvsock or aufs.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We want be able to build kernels for different archs without that they
clash with each other so we but the generated files into an $arch subdir.
Signed-off-by: Natanael Copa <natanael.copa@docker.com>
- create an empty dummy file to indicate that docker image is built
- reuse same make rule to extract the different files from docker image
- make sure that we remove empty files on failure
This makes build more robust and improves parallelism.
Signed-off-by: Natanael Copa <natanael.copa@docker.com>
This is less to do with installing modules (which we generally don't expect to
use in Moby) but to populate /lib/modules/`uname -r`/modules.builtin which
turns:
moby:~# modprobe ip_vs
modprobe: FATAL: Module ip_vs not found in directory /lib/modules/4.4.14-moby
moby:~# modprobe nf_nat
modprobe: FATAL: Module nf_nat not found in directory /lib/modules/4.4.14-moby
moby:~#
into:
moby:~# modprobe ip_vs
moby:~# modprobe nf_nat
moby:~#
which reduces the amount noise in the logs, e.g. in docker.log:
time="2016-07-04T11:21:58Z" level=warning msg="Running modprobe nf_nat failed with message: `modprobe: WARNING: Module nf_nat not found in directory /lib/modules/4.4.14-moby`, error: exit status 1"
A fair number of these appear in the logs.
This also stops various tools logging about /lib/modules/`uname -r` not
existing (there was one in the boot log until recently I think)
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Linux xargs calls the command with no arguments if it gets no inputs, which
`docker rmi` complains about. It provides -r / --no-run-if-empty to prevent
this but unfortunately this isn't supported on OSX.
Ignore errors from `docker rmi` so that `make clean` will keep going and clean
up later stuff.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
These are WIP taken from git@github.com:stefanha/linux.git#vsock
(==4c9d2a6be1c6, using "cherry-pick -x") and correspond to RFC v5 of the
frontend patches posted in
http://thread.gmane.org/gmane.linux.kernel.virtualization/27455
There is no corresponding spec proposal update yet, but this set of patches
correspond (roughly) to addressing the feedback on v4 of the spec proposal
http://thread.gmane.org/gmane.comp.emulators.virtio.devel/1062.
kernel_config.arm modifications copied from x86, not tested.
Added /etc/kernel-patches/ directory to the image to be consumed by the
licensing.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
