Forum Discussion
Hosted Agent ZIP deployment fails because adduser is missing for fuse-zip
Hi,
I am encountering a reproducible issue with a Microsoft Foundry Hosted Agent deployed through the Source Code ZIP deployment path.
Environment:
- Region: West Europe
- Runtime: dotnet_10
- Target framework: net10.0
- Publish runtime: linux-x64
- Dependency resolution: bundled
- Protocol: Responses 2.0.0
- API version: 2025-11-15-preview
The agent version reaches the "active" status. However, the first invocation fails with:
session_not_ready
The relevant session logs are:
Selecting previously unselected package fuse.
Unpacking fuse (2.9.9-5ubuntu3) ...
Selecting previously unselected package fuse-zip.
Unpacking fuse-zip (0.6.0-0ubuntu3) ...
dpkg: dependency problems prevent configuration of fuse:
fuse depends on adduser; however:
Package adduser is not installed.
dpkg: error processing package fuse (--install):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of fuse-zip:
fuse-zip depends on fuse; however:
Package fuse is not configured yet.
dpkg: error processing package fuse-zip (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
fuse
fuse-zip
Successfully connected to containerNo .NET application startup logs appear after this. The application entry point does not appear to be executed, and /readiness never becomes healthy.
I have already verified:
- A clean linux-x64 publish is used.
- The entry DLL is located directly at the ZIP root.
- The ZIP contains no nested bin, obj, or artifacts directories.
- All dependencies are bundled.
- appsettings.json, .deps.json, and .runtimeconfig.json are present.
- The exact published application starts successfully locally.
- The local /readiness endpoint returns HTTP 200.
- The issue is reproducible with newly deployed agent versions and new sessions.
- The current Foundry hosting packages and Responses Protocol 2.0 are used.
The same Source Code ZIP deployment path worked successfully approximately two weeks ago.
Is this a known regression in the managed source-code runtime in West Europe?
Is there a workaround other than switching to the container-based deployment path?
Session and request IDs can be provided privately to the Microsoft product team if required.
1 Reply
Your ZIP layout and dotnet_10 runtime match the documented source-code deployment model, while the logs fail during platform package configuration before the application entry point runs. That makes a managed runtime bootstrap failure more likely than a readiness-endpoint problem, but public documentation does not confirm a known West Europe regression. Download the deployed ZIP, compare its SHA-256 with the uploaded artifact, and verify the active version, runtime, dependency mode, and entry point. Invoke a new session and stream its container logs using the returned session ID. Capture the session ID, region header, response identifier, UTC time, and complete package error. There is no supported customer step for installing a missing operating-system package inside the managed source-code image. For an immediate workaround, use the container deployment path, which gives you control of the runtime image. Otherwise open Azure support with the correlation data and request confirmation of a regional platform fault.
