Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add support for Windows 10 21H1 #164

Closed
slonopotamus opened this issue May 18, 2021 · 3 comments
Closed

Add support for Windows 10 21H1 #164

slonopotamus opened this issue May 18, 2021 · 3 comments
Labels
awaiting-upstream Awaiting bugfixes or functionality from upstream dependencies enhancement New feature or request

Comments

@slonopotamus
Copy link
Collaborator

Subj, it is already available for download.
@slonopotamus slonopotamus added the enhancement New feature or request label May 18, 2021
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 20, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
1eb495c 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 20, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
ae21bab 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 21, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
a8f4813 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 21, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
64ad6d3 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
@TBBle TBBle mentioned this issue May 24, 2021
Closed
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 25, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
098b5ea 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 25, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
99a5e30 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
@TBBle TBBle mentioned this issue May 25, 2021
Closed
@slonopotamus
Copy link
Collaborator Author

It isn't clear what Windows Server Core image is supposed to be used for 21H1. See microsoft/Windows-Containers#117.

slonopotamus added a commit to slonopotamus/ue4-docker that referenced this issue May 31, 2021
@slonopotamus
resolves adamrehn#164 un-hardcode list of Windows versions
63e911e 
Partially resolves adamrehn#138 (support for insider base image is still missing)

This commit:
1. Drops the list of valid Windows versions. Instead, ue4-docker now trusts user input and will fail during image download if user enters something nonexistent
2. Drops 1603->ltsc2016, 1809->ltsc2019 and 2009->20H2 renaming. Instead, ue4-docker directly maps host OS release to Windows Server Core image tag
3. However, ue4-docker now uses advanced logic to determine host OS release. It tries to use DisplayName registry key and fallbacks to ReleaseId if DisplayName doesn't exist. This allows to properly detect 20H2 and 21H1 releases.

On the negative side, some checks are lost:
1. It is no longer possible to check that container version is newer that host OS. Though is should still be rejected by Hyper-V
2. ue4-docker no longer prevents user from using suffix that collides with Windows Server Core image tags
@slonopotamus slonopotamus added the awaiting-upstream Awaiting bugfixes or functionality from upstream dependencies label Jun 1, 2021
@slonopotamus
Copy link
Collaborator Author

21H1 won't get a matching Windows Server Core ever, see microsoft/Windows-Containers#117. So, the best strategy is to avoid updating your host system to it and stay on 20H2 (or LTSC 2019). Closing and hoping that this messy situation will be fixed in Windows 11.

@adamrehn
Copy link
Owner

adamrehn commented Aug 3, 2021

I've updated the warnings on the Unreal Containers community hub to reflect this: https://unrealcontainers.com/docs/environments/local-windows-10#optimal-performance-warning-for-windows-containers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
awaiting-upstream Awaiting bugfixes or functionality from upstream dependencies enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Un-hardcode list of Windows versions slonopotamus/ue4-docker
2 participants
@slonopotamus @adamrehn