Closed cakrit closed 1 year ago
What it is doing is converting the WSL image from version 2 to 1, the reason is that way the distro can be installed in Windows Server systems that have not yet received the update to WSL2 or the ones that have it but can't use it because Virtualization isn't available. Another reason is that if the version is not specified it would install sometimes in version 1 or 2 for unclear conditions and some commands do differ between version so setting 1 can avoid those issues.
It shouldn't have used WSL1 in my case, WSL2 was running perfectly well on my Windows 11 AFAIK.
C:\Users\cakri\Downloads>wsl -l -v
NAME STATE VERSION
* Ubuntu Stopped 2
Netdata Running 1
I could force WSL2 to be used but then it will not work for virtual servers unless the VPS provider enables nested virtualization which might not be possible or desired for performance reasons.
Is there any way we could detect if WSL2 is actually usable? I know that the Hyper-V properties returned by Get-ComputerInfo
are not useful here (other than ‘HypervisorPresent’, they all seem to be blank when running inside a VM regardless of whether nested virtualization is enabled or not), but is there anything else we could look at to check this?
If so, then we should ideally be checking that and choosing whether to force WSL2 or not based on that.
No detection possible afaik so I'll set it for version 2 and if that fails it will switch to 1.
@Ferroin I'm thinking that perhaps it's better to not support WSL1 at all. It's ancient, untested and few things seem to work on it. Perhaps we could say that if the VPS provider doesn't supported nested virtualization, they should install netdata outside their VMs.
@Ferroin I'm thinking that perhaps it's better to not support WSL1 at all. It's ancient, untested and few things seem to work on it. Perhaps we could say that if the VPS provider doesn't supported nested virtualization, they should install netdata outside their VMs.
Fine by me, though I would hardly call WSL1 ‘ancient’ given that we’re still officially supporting RHEL 7 and Ubuntu 18.04...
Unfortunately we have an issue irrelevant to the installer, that makes supporting WSL1 almost inevitable. So let's do our best to support it, but we'll be strongly recommending WSL2 where possible.
@dfpr if the "try first wsl2 and then switch to wsl1 if it fails" results in a bad UX, we can try other approaches, e.g. adding a parameter to the installation. Try it and advise.
I'll test on both versions to detect the better option.
Installer now tries wsl2 and if importing the distro fails because virtualization is not available then will install using wsl1.
I saw the trial and reverting to WSL1 on the Windows Server. When #19 is resolved, I can verify I get WSL2 on Windows 11.
WSL2 was indeed installed on Windows 11.
Just so it’s clearly confirmed here, as of right now we are also correctly selecting WSL2 when run on a Windows VM that has nested virtualization enabled (the VM I’m running locally for testing this stuff is set up with nested virtualization).
This is new and can take some time. It wasn't there before AFAIK, what is it doing?