unable to determine Windows Server Core base image tag from host system

[alexgeek]

Output of the ue4-docker info command:

ue4-docker info
ue4-docker version:         0.0.96 (latest available version is 0.0.96)
Operating system:           Windows 10 Pro (Build 19044.1620)
Docker daemon version:      20.10.13
NVIDIA Docker supported:    No
Maximum image size:         800GB
Available disk space:       702.77 GiB
Total system memory:        63.93 GiB physical, 73.43 GiB virtual
CPU:                        8 physical, 16 logical (AMD64 Family 23 Model 113 Stepping 0, AuthenticAMD)

Additional details:

• Are you accessing the network through a proxy server? No

Hi,

I've updated my machine due to the EOL of 20H2 (#216 (comment)).
Now when trying to build I get:

[ue4-docker build] Error: unable to determine Windows Server Core base image tag from host system. Specify it explicitly using -basetag command-line flag

If specify -basetag 20H2 then I get:

hcsshim::CreateComputeSystem 430289b44ed2bdd85bc91f792e55a13e59f1a578e3f55874d18029d4940dc0e5: The container operating system does not match the host operating system.
[ue4-docker build] Error: failed to build image "adamrehn/ue4-build-prerequisites:20H2-vs2017".

I can't see much in the docs related to this. It looks like in other issues most of you are building with ltsc, does this still work for Win 10 Pro?

Thanks

[TBBle]

Sadly, Windows 10 21H1 and 21H2 do not have matching Windows Server SAC releases, so there are no container images which will run on these OSs in process isolation. See microsoft/Windows-Containers#117 (comment) for Microsoft's formal position on this.

[slonopotamus]

I wonder why we're not switching automatically to hyper-v isolation on 21H2 host + 20H2 guest =/

[adamrehn]

So, having a look through the code to refresh my memory, the isolation mode selection logic will use process isolation mode where it can, and if it can't then it will fall back to the system's default isolation mode rather than explicitly selecting Hyper-V isolation mode. This seems like an oversight on my part, since we know we need Hyper-V isolation mode in the case of mismatched kernel versions and we can't safely rely on the system default given that it not only varies between client and server versions of Windows but can also be modified by the user (which I'm guessing might be the case for @alexgeek?)

[alexgeek]

So, having a look through the code to refresh my memory, the isolation mode selection logic will use process isolation mode where it can, and if it can't then it will fall back to the system's default isolation mode rather than explicitly selecting Hyper-V isolation mode. This seems like an oversight on my part, since we know we need Hyper-V isolation mode in the case of mismatched kernel versions and we can't safely rely on the system default given that it not only varies between client and server versions of Windows but can also be modified by the user (which I'm guessing might be the case for @alexgeek?)

Hi, sorry I just saw this. No I hadn't modified the default.

On Windows 11, should it just default to ltsc2022 since that's the only thing that works?

[adamrehn]

@alexgeek yes, the base tag should default to ltsc2022 under Windows 11 host systems. I'll add the relevant build number to the lookup table now. Edit: implemented in commit 6db04e5.