This way if the network is not working, then the update will just
fail and use the old version
This also tags the addon images with the semver properly
When we disable systemd-resolved, the system goes into a state
where no DNS queries work anymore. Even if unbound is installed
right after. Installing 'resolvconf' fixes this.
There is competition even for this tiny package! (openresolv)
It looks on some VPS, the grub then asks the user to re-install
since the disk name has changed/moved (presumably because the
image was created on a server with a different disk name)
on some VPS like scaleway this is not installed.
This is why docker with devicemapper was using ext4 and not devmapper
devmapper: XFS is not supported in your system. Either the kernel doesn't support it or mkfs.xfs is not in your PATH. Defaulting to ext4 filesystem"
This will anyways happen once a new EC2 instance is created from the ami
and this ensures we do not encounter an SSH disconnect error when
running the cloudron-setup script during image creation
The following packages will be DOWNGRADED:
docker-engine
0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
E: Packages were downgraded and -y was used without --allow-downgrades.
One idea was to use docker binary packages. However, docker binaries
are statically linked and are incompatible with devicemapper.
See https://github.com/docker/docker/issues/14035 for more info.
Holding will let the user turn on automatic updates for non-security
packages as well.
Fixes#183
When docker is not passed the --storage-driver option, it tries to
auto detect the storage driver. Roughly:
1. If existing storage paths like /var/lib/docker/aufs exist, it will
choose that driver.
2. It has a priority list of drivers to scan in order (driver.go)
As it stands the ordering is aufs, btrfs and then devicemapper.
3. Docker will attempt to "init" each driver. aufs, for example,
tests for insmod'ing aufs and also looks into /proc/filesystems.
The fact that we installed aufs-tools and linux drivers (for aufs
driver) was a programming error since we want docker to use devicemapper.
However, what is curious is why docker still ended up choosing devicemapper
despite having all aufs requirements (as we do not pass --storage-driver explicitly).
The answer is that "apt-get install aufs-tool linux-image-* docker-engine"
can install packages in any order! This means there is a race on how docker
chooses the storage engine. In most cases, since linux-image-* is a big package,
docker gets to install first and ends up using devicemapper since aufs module is not found yet.
For some people, linux-image-* possibly installs first and thus docker
chooses aufs!
Mystery solved.
Part of #183
