docs(troubleshooting): fix reserved 'default' name in buildx recovery

2026-04-24 22:02:27 -04:00
parent e0f074cd8c
commit 709e152ccf

@@ -91,23 +91,23 @@ for m in $(mount | awk '$3 ~ /buildkit-mount/ {print $3}'); do
done done
rm -rf ~/.docker/buildx/activity rm -rf ~/.docker/buildx/activity
sudo systemctl start docker sudo systemctl start docker
docker buildx create --use --name default docker buildx use default # the bundled builder still exists — just point at it
docker buildx inspect --bootstrap
``` ```
The `umount -l` step is the one most recipes online miss. The `umount -l` step is the one most recipes online miss.
**Fix — driver corruption (count == 0).** **Fix — driver corruption (count == 0).**
If `mount | grep -c buildkit-mount` already prints 0 and you still hit the wedge, the buildx driver state itself is inconsistent. Rebuild it: If `mount | grep -c buildkit-mount` already prints 0 and you still hit the wedge, the buildx driver state itself is inconsistent. Rebuild it under a non-reserved name:
```bash ```bash
docker buildx rm default 2>/dev/null rm -rf ~/.docker/buildx/activity ~/.docker/buildx/instances/*
rm -rf ~/.docker/buildx/activity ~/.docker/buildx/instances/default docker buildx create --name decnet-builder --use --bootstrap
docker buildx create --use --name default docker buildx inspect
docker buildx inspect --bootstrap
``` ```
`default` is reserved by Docker for the bundled builder — `buildx create --name default` errors out. Pick any other name.
**How DECNET handles it.** The engine's `_compose_with_retry`: **How DECNET handles it.** The engine's `_compose_with_retry`:
* Pre-flights leaked mounts before every build; if the count crosses 10, refuses to start and emits the leaked-mount recipe. * Pre-flights leaked mounts before every build; if the count crosses 10, refuses to start and emits the leaked-mount recipe.