Dev Containers extension: GPG forwarding generates dd bs=0 and stops lifecycle provisioning
- VS Code Version: 1.133.0 (stable)
- Local OS Version: macOS on Apple Silicon
- Remote OS Version: Ubuntu 26.04
linux/arm64 development container
- Remote Extension/Connection Type: Dev Containers
- Dev Containers Version: 0.466.0
- Docker: Docker Desktop 4.73.0
- Insiders build: Not tested
Problem
This is a Dev Containers extension issue: its GPG-forwarding path generates an invalid dd bs=0 command, and the resulting failure prevents lifecycle provisioning from reaching postCreateCommand. I reproduced it end to end on the environment above.
The behavior was first reported at devcontainers/images#1949. That image exposes the failure through Ubuntu 26.04's dd behavior, but it does not generate the command or control the extension's lifecycle error handling, so it's not a error at the devcontainers/images.
The forwarding path emits a final remainder command even when the remainder is zero. For a zero-byte source, that produces dd ... bs=0. Command generation is not Ubuntu 26.04-specific: I instrumented dd in an Ubuntu 24.04 development container and observed:
DD: iflag=fullblock bs=8192 count=0
DD: iflag=fullblock bs=0 count=1
GNU dd on 24.04 returns a normal error with exit 1 and setup continues. uutils dd on 26.04 aborts with exit 134, after which the optional GPG-forwarding failure prevents lifecycle setup from reaching postCreateCommand.
Expected Behavior
- The forwarding path does not generate
dd bs=0.
- A GPG keyring or trust-database forwarding failure is reported as a warning and does not prevent lifecycle commands from running.
Requested Changes
- Skip the remainder transfer when the remainder is zero. For a zero-byte source, create an empty destination directly; for a nonzero size divisible by 8192, issue only the full-block transfer.
- Catch and log GPG-forwarding failures, then continue provisioning and lifecycle commands.
- Add regression coverage for source sizes
0, 8191, 8192, and 8193, plus a forwarding failure that must not suppress lifecycle commands.
Steps to Reproduce
- Follow the attached, manually verified procedure exactly as written in repro.md. It contains the complete setup, Ubuntu 24.04 control, verification, and restoration steps.
Logs
The relevant container-log output from the failing run is:
Start: Run in container: # Copy .../.gnupg/pubring.gpg to /home/vscode/.gnupg/pubring.gpg
Aborted
Exit code 134
Command in container failed: # Copy .../.gnupg/pubring.gpg to /home/vscode/.gnupg/pubring.gpg
(dd iflag=fullblock bs=8192 count=0 2>/dev/null; dd iflag=fullblock bs=0 count=1 2>/dev/null) >>'/home/vscode/.gnupg/pubring.gpg'
The container attaches normally, but there is no Running the postCreateCommand log entry and the post-create sentinel file is absent.
Do let me know if you need any further information about the issue.
Dev Containers extension: GPG forwarding generates
dd bs=0and stops lifecycle provisioninglinux/arm64development containerProblem
This is a Dev Containers extension issue: its GPG-forwarding path generates an invalid
dd bs=0command, and the resulting failure prevents lifecycle provisioning from reachingpostCreateCommand. I reproduced it end to end on the environment above.The behavior was first reported at devcontainers/images#1949. That image exposes the failure through Ubuntu 26.04's
ddbehavior, but it does not generate the command or control the extension's lifecycle error handling, so it's not a error at the devcontainers/images.The forwarding path emits a final remainder command even when the remainder is zero. For a zero-byte source, that produces
dd ... bs=0. Command generation is not Ubuntu 26.04-specific: I instrumentedddin an Ubuntu 24.04 development container and observed:GNU
ddon 24.04 returns a normal error with exit 1 and setup continues. uutilsddon 26.04 aborts with exit 134, after which the optional GPG-forwarding failure prevents lifecycle setup from reachingpostCreateCommand.Expected Behavior
dd bs=0.Requested Changes
0,8191,8192, and8193, plus a forwarding failure that must not suppress lifecycle commands.Steps to Reproduce
Logs
The relevant container-log output from the failing run is:
The container attaches normally, but there is no
Running the postCreateCommandlog entry and the post-create sentinel file is absent.Do let me know if you need any further information about the issue.