[NETE2ESDK] With .NET 8 RC2 SDK pkg/deb/rpm installed, "An issue was encountered verifying workloads. For more information, run "dotnet workload update"." displayed when running the first dotnet command.

[WenJunJi01]

Repro steps:

1. Prepare clean Mac OS or Linux machine.
2. Install .NET 8 RC2 SDK(8.0.100-rc.2.23451.1(runtime-8.0.0-rc.2.23431.9)) from https://github.com/dotnet/installer
   (pkg on Mac OS, deb/rmp on Linux)
3. Open a terminal and run the first dotnet command.

Expected:
It should execute successfully with no errors or warnings.

Actual result:
The following error displayed, "An issue was encountered verifying workloads. For more information, run "dotnet workload update"."
Mac OS:

Linux:

Note:

1. Not repro with exe installed on Windows and tar.gz installed on Mac OS/Linux.
2. Only appears the first time the dotnet command is run.

dotnet --info:
.NET SDK:
Version: 8.0.100-rc.2.23451.1
Commit: dabc29073d

Runtime Environment:
OS Name: Mac OS X
OS Version: 14.0
OS Platform: Darwin
RID: osx-x64
Base Path: /usr/local/share/dotnet/sdk/8.0.100-rc.2.23451.1/

.NET workloads installed:
[wasm-tools]
Installation Source: SDK 8.0.100-rc.2
Manifest Version: 8.0.0-rc.2.23431.9/8.0.100-rc.2
Manifest Path: /usr/local/share/dotnet/sdk-manifests/8.0.100-rc.2/microsoft.net.workload.mono.toolchain.current/8.0.0-rc.2.23431.9/WorkloadManifest.json
Install Type: FileBased

Host:
Version: 8.0.0-rc.2.23431.9
Architecture: x64
Commit: 3c48925a6c
RID: osx-x64

.NET SDKs installed:
8.0.100-rc.2.23451.1 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.0-rc.2.23431.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.0-rc.2.23431.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

[dsplaisted]

What happens if you run dotnet workload update after getting this error? Does it display more error information then?

/cc @MiYanni

[MiYanni]

What happens if you run dotnet workload update after getting this error? Does it display more error information then?

dotnet workload update will run down nearly the exact same codepath as was used to verify the workloads on first-run. However, the exceptions or other potential warnings/errors will not be suppressed. The rationale is we don't want the first-run check to block the actual command the user it trying to execute, so we just eat the error. Problems with checking the workloads can happen for various reasons. In testing, I was causing them to intentionally occur by modifying the manifests.

@WenJunJi01 Can you run dotnet workload update to get the actual error? The warning shouldn't appear on a clean install with no workloads.

[WenJunJi01]

@dsplaisted @MiYanni Hi all, the details are as follows:

[MiYanni]

So, I didn't realize until I looked at your original image again that the first command you ran after install was dotnet workload list. I originally had my changes not try to do the workload integrity check if the first command was a workload command. I worked around one known issue but there likely might be others.

Instead of the warning message you saw, you should see a Checking the state of installed workloads... message. If that message isn't appearing, that means there's an issue querying the workloads on your system, which is likely why the dotnet workload list command showed nothing.

For the new screenshot, you're running dotnet workload update as your first command, which won't exhibit the actual problem. The warning you got from the original issue is informing you to run dotnet workload update after encountering the warning to get more details. So, this new screenshot is not useful in this situation. So, if you can cause the original issue with whichever first-command was used and then run dotnet workload update after that, it should show the actual error.

[WenJunJi01]

@MiYanni Here is detail output. It doesn't show the actual error.
#35128.txt

[MiYanni]

@dsplaisted So, looking at the log posted, the first command does not use sudo and the second does. Both commands show the first-time user experience, which means the first call without sudo is not creating the sentinel file. The second run doesn't show the warning, which likely means that interaction with the filesystem is the issue. Any thoughts on how to proceed or if this is just a simple file access issue?

[giggio]

I got to reproduce the error on a Docker image. Here are the steps:

docker run --rm -ti --user 1000:1000 mcr.microsoft.com/dotnet/sdk:8.0-alpine
export HOME=/tmp/user && mkdir $HOME
dotnet workload update
# outputs:
# An issue was encountered verifying workloads. For more information, run "dotnet workload update".
# Inadequate permissions. Run the command with elevated privileges.

Second run of dotnet workload update will only show the second message ("Inadequate permissions. Run the command with elevated privileges").

This is an issue because I'm trying to run dotnet build with a shared volume and user id matters, so that the file permissions on the host are set correctly.

This is also with rc2, latest image.

[marcpopMSFT]

@MiYanni bringing this back up as it appears the first run upgrade path has some issues in some situations.

[MiYanni]

@dsplaisted Do you think this issue is the same/similar situation to the one you just mentioned here? #35912 (comment)

[dsplaisted]

@dsplaisted Do you think this issue is the same/similar situation to the one you just mentioned here? #35912 (comment)

No, I don't think it's exactly the same. But I think it may be a permissions thing... when installed via a deb/rpm package, a normal .NET command won't have permission to update workload manifests. Does it check for this at all? Probably on Linux we should detect if we don't have the right permissions, and skip the automatic update in that case.

[MiYanni]

@dsplaisted

Does it check for this at all?

The check just runs the same logic we have when running a workload update. I don't remember seeing any kind of permission check in that logic. If dotnet workload update checks permissions, it is likely hierarchically above the call to the actual command; which is why it won't happen in the first-run check. I can hunt for the permission logic and see if I can tie it into the first-run check.

[ChenhuiYuan01]

This problem is also reproduced on 9.0.100-alpha.1.23564.26 on Linux.

[v-xiaofchen]

This problem is still reproduced on 9.0.100-alpha.1.24066.10(runtime-9.0.0-alpha.1.24061.26)

[WellspringCS]

I'm here because I'm seeing this behavior in Linux with 8.0.201

[ronaldtmunodawafa]

Is there a workaround for this yet?

[marcpopMSFT]

Triage: This is a non-blocking message that typically means sudo is needed to install the workloads. We should probably detect we're in a state where we don't have access to install workloads and potentially provide a better message (or at least suppress this message) as it's causing confusion

[raddevus]

Just saw this on Ubuntu 22.04.4 LTS for the first time.
Have :
SDK
8.0.300 [/usr/share/dotnet/sdk]
and
Runtimes
Microsoft.AspNetCore.App 8.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[ChenhuiYuan01]

This issue also repro's on 10.0.100-alpha.1.24568.6

[tlunsfordCXP]

This issue occurs when running in the container with a user other than root. This is seen primarily when performing builds on the CI server. I'm just building, so I could run as root, but then because the host is not running as root, I end up with build output files (e.g., test code coverage results) that the host user cannot delete; net result is that the next pipeline run ends up dead in the water (and much confusion ensues).

Guidance on how to work around this would be appreciated.

[ChenhuiYuan01]

This issue also repro's on 10.0.100-preview.3.25153.9(runtime-10.0.0-preview.3.25152.4)