Update to WSL2 2.0.1 failed - requires admin, still doesn't update

[rfay]

Windows Version

Microsoft Windows [Version 10.0.22621.2283]

WSL Version

2.0.0.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

5.15.123.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

wsl --update --pre-release

Expected Behavior

It should update. (And has typically done so without admin privs)

Actual Behavior

PS C:\Users\testbot> wsl --version
WSL version: 2.0.0.0
Kernel version: 5.15.123.1-1
WSLg version: 1.0.57
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2283
PS C:\Users\testbot> wsl --shutdown
PS C:\Users\testbot> wsl --update --pre-release
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.0.1.
Update failed (exit code: 1603).
Log file: C:\Users\testbot\AppData\Local\Temp\wsl-install-logs.txt
Error code: Wsl/UpdatePackage/E_ABORT

Diagnostic Logs

I studied the logs at C:\Users\testbot\AppData\Local\Temp\wsl-install-logs.txt and saw that it was insufficient permissions.

So I did it again with admin privs and it ran to completion without an error.

I don't believe wsl --update has required admin before?

However, wsl.exe --version still shows 2.0.0.0 after a reboot.

[westynz]

I have had exactly the same results as @rfay.

[OneBlue]

Thank you for reporting this @rfay. This is indeed a regression and it will be fixed in the next release.

Until it's fixed the workaround is to manually download the update package and install it by opening it in the explorer.

Also yes wsl --update requires administrator access now.

[tinlittle]

The title should read wsl --update --pre-release silently fails. It stays on 2.0.0 albeit prints upgrade successful.

Also, starting with wsl 2.0.0, admin privilege is required to perform wsl upgrades -- a separate disappointing new development.

[blakeduffey]

Also yes wsl --update requires administrator access now.

This is disappointing from a managed-system perspective. Users previously had a one-time interaction with the service desk to install the proper role and then were able to operate independently. I'm sure there are valid technical concerns - but this means any update to WSL will require a service desk interaction.

[elsaco]

Not sure if this issue applies to upgrading from 2.0.0.0 to 2.0.1.0 only. Upgrading from 1.3.17.0 to 2.0.1.0 did work:

PS C:\Users\elsaco> wsl --version
WSL version: 1.3.17.0
Kernel version: 5.15.90.4-1
WSLg version: 1.0.57
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2283
PS C:\Users\elsaco> wsl --update --web-download --pre-release
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.0.1.
PS C:\Users\elsaco> wsl --version
WSL version: 2.0.1.0
Kernel version: 5.15.123.1-1
WSLg version: 1.0.58
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2283

The commands were run from an elevated pwsh session. On a different system with the latest Canary installation upgrading from 2.0.0.0 to 2.0.1.0 failed.

[OneBlue]

Also yes wsl --update requires administrator access now.

This is disappointing from a managed-system perspective. Users previously had a one-time interaction with the service desk to install the proper role and then were able to operate independently. I'm sure there are valid technical concerns - but this means any update to WSL will require a service desk interaction.

You should still be be able to install via the store if you wish so, but you'll need to open the store manually.

[OneBlue]

Not sure if this issue applies to upgrading from 2.0.0.0 to 2.0.1.0 only. Upgrading from 1.3.17.0 to 2.0.1.0 did work:

PS C:\Users\elsaco> wsl --version
WSL version: 1.3.17.0
Kernel version: 5.15.90.4-1
WSLg version: 1.0.57
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2283
PS C:\Users\elsaco> wsl --update --web-download --pre-release
Checking for updates.
Updating Windows Subsystem for Linux to version: 2.0.1.
PS C:\Users\elsaco> wsl --version
WSL version: 2.0.1.0
Kernel version: 5.15.123.1-1
WSLg version: 1.0.58
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2283

The commands were run from an elevated pwsh session. On a different system with the latest Canary installation upgrading from 2.0.0.0 to 2.0.1.0 failed.

Yes this is expected because the bug that breaks the installation was introduced in 2.0.0.

[blakeduffey]

Also yes wsl --update requires administrator access now.

This is disappointing from a managed-system perspective. Users previously had a one-time interaction with the service desk to install the proper role and then were able to operate independently. I'm sure there are valid technical concerns - but this means any update to WSL will require a service desk interaction.

You should still be be able to install via the store if you wish so, but you'll need to open the store manually.

Does the store require admin? If no - why a difference in functionality/privileges required between the store and command line?

[rfay]

@blakeduffey you inspired me to ask:

• Please explain difference between store, distribution, and wsl --update wsl versions #10551

[felipecrs]

BTW one suggestion I have is to automatically ask to elevate privileges when upgrading, instead of requiring the user to reopen the session as admin.

[blakeduffey]

BTW one suggestion I have is to automatically ask to elevate privileges when upgrading, instead of requiring the user to reopen the session as admin.

This would be better than simply failing - but it doesn't solve underlying issue of requiring the user to have local privileges to upgrade when this was required previously.

[OneBlue]

This issue has been fixed in 2.0.2

[castorfou]

I still have this issue (requiring admin rights) when upgrading from 2.0.0 to 2.0.2.

I have not tested with admin rights (don't have access to service desk right now)

[dciarniello]

I was also not able to update but I've now broken my install.
I tried with admin rights but the install seemed to hand so I Ctrl-C'd out. Now I'm stuck with the message

An install, uninstall, or conversion is in progress for this distribution

I've also tried wsl --update --web-download but that gives me

The package installation failed because a version of the service exists outside of APPX packaging.

Any suggestions as to how to get out of this fix?

[dciarniello]

Thankfully, I was able to fix it by removing WSL via the Apps & features app and reinstalling with

wsl --update --web-download followed by
wsl --update --pre-release

I did both as administrator.

[rfay]

This update also broke me. It looked like it was working, but then after the upgrade to 2.0.2, wsl --version was no longer a valid flag, and systemd didn't work any more.

I seem to have recovered (thanks @dciarniello ) with:

• Remove all WSL-related things from "Apps and features"
• As admin: wsl --update
• As admin: wsl --update --pre-release

I did not lose my distro.

[felipecrs]

Your procedure does not work for me. After wsl --update --pre-release, I'm back to old WSL.

[alexbogias]

Was stacked in 2.0.1. Followed @rfay procedure and now I have successfully upgraded to 2.0.9. Cheers

[kh-abd-kh]

Hey guys;

I had the same problem. every thing failed
wsl --update
wsl --update --web-download

it turned out that i had an old version of wsl to solve the problem
here what worked for me
1- download
https://github.com/microsoft/WSL/releases/download/2.0.1/wsl.2.0.1.0.x64.msi
2- run as an admin from cmd
3- download the last one
https://github.com/microsoft/WSL/releases/download/2.0.14/wsl.2.0.14.0.x64.msi
4- run it as admin from cmd

i.e double "update"

now it works, hoping it helps