install: configure docker to NOT use containerd-snapshotter

[Williangalvani]

That caused incompatibilities with DinD and increased disk usage

fix #3917

image for testing is available at https://github.com/Williangalvani/BlueOS/actions/runs/27427008535

Summary by Sourcery

Build:

• Add Docker daemon configuration to disable the containerd snapshotter feature during installation.

Summary by Sourcery

Build:

• Add Docker daemon configuration file to turn off the containerd-snapshotter feature on install.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• Writing a new /etc/docker/daemon.json unconditionally will overwrite any existing Docker daemon configuration; consider merging with an existing file or appending this feature flag in a safer, non-destructive way.
• The comment mentions two ways the containerd image store breaks BlueOS but only describes one; either clarify the second issue or adjust the comment so it accurately reflects the behavior being documented.
• You may want to guard this configuration by Docker version (e.g., only when Docker >= 29) to avoid setting an unsupported or unnecessary feature flag on older Docker installations.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Writing a new /etc/docker/daemon.json unconditionally will overwrite any existing Docker daemon configuration; consider merging with an existing file or appending this feature flag in a safer, non-destructive way.
- The comment mentions two ways the containerd image store breaks BlueOS but only describes one; either clarify the second issue or adjust the comment so it accurately reflects the behavior being documented.
- You may want to guard this configuration by Docker version (e.g., only when Docker >= 29) to avoid setting an unsupported or unnecessary feature flag on older Docker installations.

## Individual Comments

### Comment 1
<location path="install/install.sh" line_range="170-177" />
<code_context>
+# That store breaks BlueOS in two ways: the booted docker.service talks to the
+# system containerd (a different data-root), so images baked into the image during
+# the build are invisible at runtime;
+mkdir -p /etc/docker
+cat <<'EOF' > /etc/docker/daemon.json
+{
+    "features": {
+        "containerd-snapshotter": false
+    }
+}
+EOF
+
 if [ $RUNNING_IN_CI -eq 1 ]
</code_context>
<issue_to_address>
**issue (bug_risk):** Avoid blindly overwriting an existing /etc/docker/daemon.json

Unconditionally rewriting `daemon.json` will drop any existing Docker configuration (registry mirrors, log options, cgroup driver, etc.), potentially breaking customized setups. Please check whether `/etc/docker/daemon.json` exists and either merge in `features.containerd-snapshotter=false` (e.g., via `jq`) or only create the file when it doesn’t exist, instead of always overwriting it.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[github-actions]

Automated PR Review

0. Summary

• Verdict: DOES NOT SAIL 🪨
• Critical items to address: 1.1

Writes /etc/docker/daemon.json during install.sh with features.containerd-snapshotter: false, so Docker 29+ stops defaulting to the containerd image store. The stated motivation is to keep build-time images visible to the booted docker.service and to avoid the disk-usage / DinD incompatibilities of the containerd snapshotter.

1. Correctness & Implementation Bugs

• 1.1 [major] install/install.sh:165-176 — daemon.json is written, but the docker daemon is never restarted before the script proceeds to use it. On systemd hosts, get.docker.com (line 155) starts dockerd with its default config (snapshotter=true on Docker 29+); the new daemon.json only takes effect on the next daemon start. Everything between this block and the final reboot (line 297) still talks to the old daemon: docker pull $BLUEOS_BOOTSTRAP / docker pull $BLUEOS_CORE (lines 239–240), docker image tag (line 246), and docker create ... blueos-bootstrap (line 249) all land in the containerd snapshotter store. After the post-install reboot, the docker.service comes up with snapshotter=false and cannot see those images / the blueos-bootstrap container — which is precisely the failure mode the PR comment describes ("images baked into the image during the build are invisible at runtime"). Add systemctl restart docker (and wait for it to be ready) immediately after the EOF heredoc, before the docker operations later in the script. If the assumption is that dockerd is not yet running at this point in the BlueOS image build, please document that — but the explicit systemctl enable docker next door suggests the author expects a running daemon.

8. Documentation

• 8.1 [nit] install/install.sh:166-169 — the comment promises "two ways" the snapshotter store breaks BlueOS, but only describes one (build/runtime data-root mismatch) and trails off with a semicolon. Either finish the second reason (the PR description hints at DinD incompatibility and increased disk usage) or drop the "in two ways" framing.

Generated by PR Review Bot. This is advisory, a human reviewer must still approve.

[Williangalvani]

• 1.1 [major] install/install.sh:165-176 — daemon.json is written, but the docker daemon is never restarted before the script proceeds to use it

this is not a regular system. this is running within pimod in a chroot. Docker only starts after running the DinD script.
the difference between the pi4 working images and the not-working pi5 images is that after booting, the docker deamons try to get images from different places. which is the issue this PR addresses

[patrickelectric]

I'm going to release a new version of BlueOS to also test the new image generation.
@Williangalvani please cherry-pick this change to 1.4 as well if necessary.