Ubuntu-20.04 has stopped working

[oleg-jukovec]

Everything worked until today (but it could have broken earlier):

    runs-on: windows-2022
    ...
    steps  
      - name: Setup WSL for tarantool
        uses: Vampire/setup-wsl@v1
        with:
          distribution: Ubuntu-20.04

And it doesn't work now:

2022-06-16T09:18:40.9862410Z ##[group]Run Vampire/setup-wsl@v1
2022-06-16T09:18:40.9862742Z with:
2022-06-16T09:18:40.9863103Z   distribution: Ubuntu-20.04
2022-06-16T09:18:40.9863382Z   use-cache: true
2022-06-16T09:18:40.9863627Z   set-as-default: true | false
2022-06-16T09:18:40.9863907Z   update: false
2022-06-16T09:18:40.9864200Z env:
2022-06-16T09:18:40.9864530Z   pythonLocation: C:\hostedtoolcache\windows\Python\3.10.5\x64
2022-06-16T09:18:40.9864811Z ##[endgroup]
2022-06-16T09:18:41.3981083Z ##[group]Verify Windows Environment
2022-06-16T09:18:41.4326056Z ##[endgroup]
2022-06-16T09:18:41.6556345Z ##[group]Install Distribution
2022-06-16T09:18:45.8896904Z Received 176160768 of 485110807 (36.3%), 165.8 MBs/sec
2022-06-16T09:18:46.8919317Z Received 381681664 of 485110807 (78.7%), 180.6 MBs/sec
2022-06-16T09:18:49.4873775Z Received 485110807 of 485110807 (100.0%), 100.4 MBs/sec
2022-06-16T09:18:49.4875684Z Cache Size: ~463 MB (485110807 B)
2022-06-16T09:18:49.4895289Z [command]C:\Windows\System32\tar.exe -z -xf D:/a/_temp/081d6935-5a91-4c2c-8173-f5e0fca2e0b5/cache.tgz -P -C D:/a/tarantool-python/tarantool-python
2022-06-16T09:18:51.5767884Z [command]C:\hostedtoolcache\windows\Ubuntu\20.4.0\x64\ubuntu.exe install --root
2022-06-16T09:18:52.5272290Z Installing, this may take a few minutes...
2022-06-16T09:18:52.5272556Z 
2022-06-16T09:18:52.5272991Z WslRegisterDistribution failed with error: 0x800701bc
2022-06-16T09:18:52.5273389Z 
2022-06-16T09:18:52.5273956Z Error: 0x800701bc WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel

Workflow.

[antaljanosbenjamin]

I just run into the same problem. I found microsoft/WSL#5393 issue as a possible fix for this, however I am not familiar with the internals of setup-wsl to know how this can be solved.

Do you have any estimation about when this can be fixed? I don't want to hurry you at all, just asking to have more information to decide how to proceed with this in our workflow, whether we should find a workaround this or wait a few days for the fix.

[Vampire]

Hi guys, thanks for the reports. It is broken since somewhen yesterday. I have a daily CI run on all sorts of combinations and it started to fail today, but only on windows-2022 and thus windows-latest.

That issue ist not really a fix, it is two years old and contains several ways that worked for some and not for others. They all just show the usual problems some people have when trying to get WSL2 or WSL in general up and running, but thanks for finding it.

There was a new release of the windows-2022 environment that seems break it by somehow halfway enabling WSL2 while the documentation says still only WSL1 is supported. So before doing anything here, I have to post a question as to whether these changes were unintended and will be fixed or on how to proceed.

As a work-around, if you don't depend on the specific Windows version, use windows-2019 environment, that still works fine.

[Vampire]

Upstream report: actions/runner-images#5760

[Vampire]

Unfortunately the Azure cloud the build agents are running on do not support nested Hyper-V virtualization,
so unfortunately WSLv2 can still not be supported properly.
In a future update of the windows-2022 environment GitHub sets the default version of WSL to WSLv1,
but I'll also later today will release an updated version of this action that also forces the WSL version to be WSLv1.

[ssbarnea]

It might not be very important but I observed that the call to --set-default-vers 1 fails because that flag does not exist on wsl1 version that we have on GHA default windows runners.

While only a visual annoyance, maybe we can find a way to avoid displaying that failure or even running the command only when needed instead of always.

[Vampire]

How do you define "default windows runners"?
There is windows-2022 and windows-2019, and there is windows-latest which currently points at windows-2022.
windows-2022 supports the command, windows-2019 does not.

I'm aware that the command fails on windows-2019, but it also failed on windows-2022 two weeks ago.
So I decided to always execute the command without letting the action fail in case it gets supported in the future,
so that it simply works without another release of the action.

To execute if only when needed would mean that I would need to make another command first like wsl --help and check the output whether it contains --set-default-version. And that just to ensure that it does not show a warning on the old Windows version. I'm not sure whether that's worth it.

Are your feelings about that so strong while at the same time not being able to switch to a newer Windows?

[ssbarnea]

Last attempt to switch to Windows 2022 was a total waste of time as the jobs using WSL on it where crashing, as in runner becoming totally unresponsive. That is why we continued to use 2019. We wasted few days and Microsoft Support was not able to do much about it but I seen them doing some kind of ack regarding knowing about some stability issues. As they change runners often, we will try again. In fact I am already testing with 2022 and will use it if it works.

BTW, I really appreciate you taking time to help others dealing with WSL-joys in their actions. It is a very stressful experience so 2x kudos!

A warning like this probably does not worth your time but if someone else would make a PR, you can review it.

[Vampire]

I quickly built a new version where it checks whether the option is available.
Should not show the warning anymore now.