Default config is restricted ptrace, processes can only ptrace
related processes, such as child processes, rather than any process
with the same uid.
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>
Regenerated the kernel config from container, which bumped the kernel
version and included some other fixes. Also bumps the check-config
container to check for VSYSCALL_NATIVE
Signed-off-by: Riyaz Faizullabhoy <riyaz.faizullabhoy@docker.com>
128 CPUs seems plenty for now and it allows for the
debug kernels to boot on Hyper-V without modifications. It may
also have the added benefit of reducing some data structures
allocated per CPU (in particular for Debug kernels).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Azure only uses the Hyper-V framebuffer, so we should not need this.
Simplify setup for graphics options we are not using.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
I think this may have got mangled in the kernel upgrade/downgrade.
diff file is still messy due to version changes.
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>
In particular vsock causes issues with virtio vsock
We are not supporting VMWare platform at present so not relevant..
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The ability to unload kernel modules helps with rapid development of kernel
modules or Moby-integrated functionality. It has no negative side effects
as far as I am aware.
Signed-off-by: David Sheets <dsheets@docker.com>
Increase the number of hypervisors where Moby can run and detect
the disks. With this change, I'm able to boot under KVM and see
the disk detected, formatted and mounted as expected.
When running moby under other hypervisors, requiring troubleshooting on
the serial port can be painful. This change enables console support on
tty1 similar to the way prior boot2docker images worked.
DOS filesystems are handy for embedded development. ISO FS was
requested/suggested somewhere on a forum.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@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>
