Running ./install/build_offline_bundle_docker.sh from a checkout on a USB stick
failed with "No Docker socket at /var/run/docker.sock" — advice that cannot be
followed, since Docker Desktop is reached over a named pipe. Three separate
faults sat behind it.
1. Windows was never supported despite the docs claiming otherwise. The socket
test only means something where a socket file is what gets mounted; MSYS also
rewrites the Unix-looking paths in every -v argument. Guard the test, convert
mount sources with cygpath, and set MSYS_NO_PATHCONV so targets, the socket
path and the workdir survive verbatim.
2. Identity mapping broke on Windows. The build starts further containers whose
bind mounts are resolved by the host daemon, so a path must mean the same
thing on both sides. On Linux that is free. On Windows it is not: the daemon
speaks Windows paths and a Linux container cannot have a directory called
C:/Users. Mount inside the container at /run/desktop/mnt/host/<drive>/… —
the form Docker Desktop's VM resolves — and hand the inner script the same.
Without this the APT resolver wrote 106 .debs into a phantom directory and
the build died with "no package index was produced". That check happens to
run host-side; had it run in the container, the result would have been a
bundle that built, self-verified, and was empty.
3. Docker Desktop shares only fixed drives. Removable and exFAT volumes mount as
an EMPTY directory instead of failing. Probe each path with a marker file, and
work around what is found: stage the checkout when the source is unmountable,
and build into staging then copy across when the output is. Writing a bundle
straight to the USB stick it will travel on is the whole point of the tool, and
the host can write there even when the daemon cannot read there.
Verified end to end on Windows/Git Bash from an exFAT checkout: a 978 MB bundle
with 106 .debs and 6 images landed on the removable drive, and
verify_offline_bundle.sh passes against that copy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>