2 ILCompiler issues in latest VMR build

[NikolaMilosavljevic]

There are 2 ILCompiler issues in latest VMR build which contains the fix for nuget.client non-determinism (dotnet/installer#19074).

Alpine319_Offline_PreviousSourceBuiltSdk_x64:

    /vmr/src/runtime/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj : error NU1101: Unable to find package runtime.linux-musl-x64.Microsoft.DotNet.ILCompiler. No packages exist with this id in source(s): prebuilt, previously-source-built, reference-packages, source-built-command-line-api, source-built-emsdk, source-built-source-build-externals, source-built-transport-arcade, source-built-transport-cecil, source-built-transport-emsdk [/vmr/src/runtime/Build.proj]

CentOSStream8_Online_PreviousSourceBuiltSdk_x64:

      ILCompiler -> /vmr/src/runtime/artifacts/bin/coreclr/linux.x64.Release/ilc/ilc.dll
      Generating native code
      Unhandled exception. System.CommandLine.CommandLineException: Target OS 'centos' is not supported
         at System.CommandLine.Helpers.GetTargetOS(String) + 0x4da

CentOSStream8_Offline_PreviousSourceBuiltSdk_x64:

    /vmr/src/runtime/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj : error NU1101: Unable to find package runtime.linux-x64.Microsoft.DotNet.ILCompiler. No packages exist with this id in source(s): prebuilt, previously-source-built, reference-packages, source-built-command-line-api, source-built-emsdk, source-built-source-build-externals, source-built-transport-arcade, source-built-transport-cecil, source-built-transport-emsdk [/vmr/src/runtime/Build.proj]

@jkoritzinsky

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkoritzinsky]

Cc: @tmds I think these failures are related to the "non-portable ILCompiler" PR.

Cc: @jkotas, @agocke

[tmds]

Yes, that's dotnet/runtime#99148.

The issues seem to be in the PreviousSourceBuiltSdk case, which I think I had verified as well ...

I'll take a look.

[tmds]

@NikolaMilosavljevic where can I find the logs that you copied the errors from?

[NikolaMilosavljevic]

@NikolaMilosavljevic where can I find the logs that you copied the errors from?

It's the internal build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2406298&view=results

[tmds]

I don't think I can access those. I've started a build locally.

I only verified the offline case, so I probably missed something for the online case.

For the offline case, I'm surprised to see the portable rid show up in these error messages. It should try to restore the non-portable rid from the "PreviousSourceBuiltSdk".

[NikolaMilosavljevic]

I don't think I can access those. I've started a build locally.

I only verified the offline case, so I probably missed something for the online case.

For the offline case, I'm surprised to see the portable rid show up in these error messages. It should try to restore the non-portable rid from the "PreviousSourceBuiltSdk".

Here are the runtime logs.
Alpine319_Offline_PreviousSourceBuiltSdk_x64.runtime.log
CentOSStream8_Offline_PreviousSourceBuiltSdk_x64.runtime.log
CentOSStream8_Online_PreviousSourceBuiltSdk_x64.runtime.log

[NikolaMilosavljevic]

Binlogs:
binlogs.zip

[tmds]

Thanks for sharing the logs! I should be able to find and fix the issue tomorrow.

[tmds]

My build didn't reproduce the issue.

I assume it may be because that when I do a build that uses a "PreviousSourceBuiltSdk", that SDK is a newly bootstrapped version that includes dotnet/runtime#99148.

Do the PreviousSourceBuiltSdk jobs use an SDK that doesn't yet include dotnet/runtime#99148?
The issue may be due to that SDK not yet understanding how to use the non-portable rid ILCompiler.

This is for the offline jobs. I'll do an --online build tomorrow and see how it behaves.

[tmds]

The online build also completed successfully.

Based on my previous comment, the issue should be gone once the SDK used to build the VMR includes dotnet/runtime#99148.

@NikolaMilosavljevic is this something that will happen automatically?

For distro-maintainers, it means they won't be able to use the previous source-built preview SDK to build the new one. I assume that, since we're in early previews, it's acceptable for them to have to re-bootstrap.

[omajid]

For distro-maintainers, it means they won't be able to use the previous source-built preview SDK to build the new one. I assume that, since we're in early previews, it's acceptable for them to have to re-bootstrap

I was told that it's expected that re-bootstrapping may be required by distro maintainers at any point during the preview releases. The situation changes with RC and GA releases.

[MichaelSimons]

Do the PreviousSourceBuiltSdk jobs use an SDK that doesn't yet include dotnet/runtime#99148?

Yes, the PreviousSourceBuiltSdk jobs are using the previously SDK from the previous preview release so they don't include your runtime change. This change requires use to re-bootstrap but doing so is currently blocked on #4206

[NikolaMilosavljevic]

This issue was fixed in Preview 3 branch with re-bootstrapping: dotnet/installer#19085

Re-bootstrapping for main is in progress: dotnet/installer#19145

[NikolaMilosavljevic]

Fixed with re-bootstrapping: dotnet/installer#19145