Ensures that when a plugin is removed that it doesn't interfere with
other plugins mounts and also ensures its own mounts are cleaned up.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 5017b5bef55c31db4c04c8058ef7db8597b11341
Component: engine
Even though it's highly discouraged, there are existing
installs that are running overlay/overlay2 on filesystems
without d_type support.
This patch allows the daemon to start in such cases, instead of
refusing to start without an option to override.
For fresh installs, backing filesystems without d_type support
will still cause the overlay/overlay2 drivers to be marked as
"unsupported", and skipped during the automatic selection.
This feature is only to keep backward compatibility, but
will be removed at some point.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 0a4e793a3da9ba6d20bccfb83f7c48e20a76d895
Component: engine
Support for running overlay/overlay2 on a backing filesystem
without d_type support (most likely: xfs, as ext4 supports
this by default), was deprecated for some time.
Running without d_type support is problematic, and can
lead to difficult to debug issues ("invalid argument" errors,
or unable to remove files from the container's filesystem).
This patch turns the warning that was previously printed
into an "unsupported" error, so that the overlay/overlay2
drivers are not automatically selected when detecting supported
storage drivers.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 0abb8dec3f730f3ad2cc9a161c97968a6bfd0631
Component: engine
The fsmagic check was always performed on "data-root" (`/var/lib/docker`),
not on the storage-driver's home directory (e.g. `/var/lib/docker/<somedriver>`).
This caused detection to be done on the wrong filesystem in situations
where `/var/lib/docker/<somedriver>` was a mount, and a different
filesystem than `/var/lib/docker` itself.
This patch checks if the storage-driver's home directory exists, and only
falls back to `/var/lib/docker` if it doesn't exist.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: f9c8fa305e1501d8056f8744cb193a720aab0e13
Component: engine
Failed out otherwise:
```
---> Making bundle: dynbinary (in bundles/dynbinary)
Building: bundles/dynbinary-daemon/dockerd-17.09.0-dev
Package libudev was not found in the pkg-config search path.
```
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 4d8e8855d1008f4705ea6db17e5cd5bc90bd2d81
Component: packaging
Seems `docker-edge` was removed as label on jenkins.dockerproject.org.
This removes that label and just puts the x86_64 label
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 6765382587e31a93b1e65d2d169b00a42d183ee2
Component: packaging
* add aarch64 support
* use go 1.9 for arm64 support
* fixtypo
* add backports on jessie
* fix path
* delet yakkety
* rm golang-go
* use arm64v8/ images
* fix error made in merge
* remove double architecture
* use arm64v8/
* use go 1.8.5
* Update aarch64 builds to 1.9.2
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 03eac425534002445e666ce0352f1c666151dc89
Component: packaging
Setting to something that will not be confused with a version number
that will ever be released. Also, this is required for the deb packages
to build properly
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Upstream-commit: 0de78bd1251958a9d8916c3944b8f51d0ffb49b7
Component: packaging
They don't function correctly and they're not worth it
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 3f5a6f288ad7e134abb4ac99e56cbbca17bfae88
Component: packaging
Previously, the code would set the mtime on the directories before
creating files in the directory itself. This was problematic
because it resulted in the mtimes on the directories being
incorrectly set. This change makes it so that the mtime is
set only _after_ all of the files have been created.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Upstream-commit: 77a2bc3e5bbc9be3fe166ed8321b7cd04e7bd097
Component: engine