OpenSuSE leap 15.4 on WSL2 will not start after enabling systemd

[lfservin]

Version

Windows version: 10.0.22621.1105

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.15.79.1

Distro Version

openSUSE-Leap-15.4

Other Software

No response

Repro Steps

I followed the instructions to have systemd start on boot from: this link . In particular I set this variable in the /etc/wsl.conf file in my distro:

[boot]
systemd=true

Expected Behavior

The distro "boots" when I start WSL

Actual Behavior

This error is thrown and no console starts:
Error code: Wsl/Service/CreateInstance/E_UNEXPECTED

Diagnostic Logs

Using this script I created this diagnostic log file.
WslLogs-2023-02-06_13-47-49.zip

[lfservin]

This ticket was created since #9477 has been marked closed by inactivity from the reporter.

[sbradnick]

Unfortunately there's a piece of the systemd puzzle missing by default in Leap. You need a symlink for /sbin/init pointing to /usr/lib/systemd/systemd ([as root, run] ln -s /usr/lib/systemd/systemd /sbin/init) ; once that's in place it will work.

I've added this logic to a wsl_systemd pattern (package: patterns-wsl-systemd) but it hasn't proliferated everywhere in the ecosystem, especially backwards (15.4, 15.3, etc.); hopefully >=15.5 will have it available out of the gate.

[lfservin]

I tried a new opensuse install, this time tumbleweed, and I did install the wsl_systemd pattern. It works fine.
Now, how do I recover the "lost" Leap instance? I would like to save a few files that are "stuck" in it. Ideally I could mount the disk to disable systemd on start from wsl.conf or at least copy files out of it. Anything that you could recommend, besides from wiping that disk and starting anew?

[lfservin]

Leaving this here for anyone having the same problem as I did. This is how you fix a botched Leap distribution using a different wsl distribution, in my case tumbleweed.

1. Find out where the vhdx (virtual hdd) is located in the filesystem. Run this one liner in powershell:

(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | Where-Object { $_.GetValue("DistributionName") -eq 'openSUSE-Leap-15.4' }).GetValue("BasePath") + "\ext4.vhdx"

This will give you a long string as an answer. In my case it was this, but yours will surely look different

C:\Users\<your windows username>\AppData\Local\Packages\46932SUSE.openSUSELeap15.4_022rs5jcyhyac\LocalState\ext4.vhdx

2. Now exit all wsl windows and in a powershell terminal type wsl --shutdown.
3. Verify that all wsl instances have been shutdown with wsl -l -v
4. Start your alternative wsl distribution (tumbleweed in my case)
5. In a powershell terminal mount the vhdx to your alternative distribution, using the long string you got in 1.:

 wsl -d openSUSE-Tumbleweed --mount --vhd C:\Users\<your windows username>\AppData\Local\Packages\46932SUSE.openSUSELeap15.4_022rs5jcyhyac\LocalState\ext4.vhdx

6. The previous command will tell you on success that the disk has been mounted on /mnt/wsl/XX, in my case it was:

7. Time to fix your wsl.conf file! In your alternative (tumbleweed) wsl terminal open this file using sudo:

 sudo vim /mnt/wsl/CYourWindowsUserNameAppDataLocalPackages46932SUSEopenSUSELeap154022rs5jcyhyacLocalStateext4vhdx/etc/wsl.conf

8. Remove the offending lines from wsl.conf and save it:

[boot]
systemd=true

9. Close your alternative wsl (tumbleweed) instance. Call wsl --shutdown in the powershell terminal
10. Start your Leap wsl distribution.
11. Now try to install the wsl_systemd pattern in Leap, before you enable systemd again!

[sbradnick]

I tried a new opensuse install, this time tumbleweed, and I did install the wsl_systemd pattern. It works fine.
Now, how do I recover the "lost" Leap instance? I would like to save a few files that are "stuck" in it. Ideally I could mount the disk to disable systemd on start from wsl.conf or at least copy files out of it. Anything that you could recommend, besides from wiping that disk and starting anew?

Using %HOMEPATH%/.wslconfig with:

[wsl2]
safeMode=true

disables systemd, at least for TW/SLE - not sure why that isn't the case for Leap when /etc/wsl.conf contains:

[boot]
systemd=true

but the /sbin/init link isn't present (link wasn't present before, w/ systemd inactive [no /etc/wsl.conf]). Not sure if that's a WSL problem or not 😑️

[RedSnt]

Unfortunately there's a piece of the systemd puzzle missing by default in Leap. You need a symlink for /sbin/init pointing to /usr/lib/systemd/systemd ([as root, run] ln -s /usr/lib/systemd/systemd /sbin/init) ; once that's in place it will work.

I've added this logic to a wsl_systemd pattern (package: patterns-wsl-systemd) but it hasn't proliferated everywhere in the ecosystem, especially backwards (15.4, 15.3, etc.); hopefully >=15.5 will have it available out of the gate.

Thanks for this fix. For some reason still had to do this with openSUSE-Leap-15.5 to get systemd working.

PS C:\Windows\system32> wsl --version
WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3803

for reference.

[sbradnick]

Unfortunately there's a piece of the systemd puzzle missing by default in Leap. You need a symlink for /sbin/init pointing to /usr/lib/systemd/systemd ([as root, run] ln -s /usr/lib/systemd/systemd /sbin/init) ; once that's in place it will work.
I've added this logic to a wsl_systemd pattern (package: patterns-wsl-systemd) but it hasn't proliferated everywhere in the ecosystem, especially backwards (15.4, 15.3, etc.); hopefully >=15.5 will have it available out of the gate.

Thanks for this fix. For some reason still had to do this with openSUSE-Leap-15.5 to get systemd working.

PS C:\Windows\system32> wsl --version
WSL version: 2.0.14.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3803

for reference.

When I said "hopefully >=15.5 will have it available out of the gate." I was referring to the wsl_systemd pattern being available for use, not backend systemd changes to Leap on the whole. I'm not planning on enabling systemd "out of the gate" for any of the SUSE/openSUSE images.

The idea would be zypper in -t pattern wsl_systemd is run very early after a distro is installed if an individual wants systemd "out of the gate".

[vanvuvuong]

I have the same issue, after follow instruction from this doc: https://en.opensuse.org/openSUSE:WSL, install wsl_gui, wsl_systemd, wsl_base & shutdown WSL, start again. Finally my SUSE can use systemd

[Sieboldianus]

(Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss | Where-Object { $_.GetValue("DistributionName") -eq 'openSUSE-Leap-15.4' }).GetValue("BasePath") + "\ext4.vhdx"

dir not work for me. I get:

> Es ist nicht möglich, eine Methode für einen Ausdruck aufzurufen, der den NULL hat.
> In Zeile:1 Zeichen:1
> + (Get-ChildItem -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\ ...
> + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
>     + FullyQualifiedErrorId : InvokeMethodOnNull

What worked was:

1. Go to:

C:\Users\user\AppData\Local\Packages\

2. Search for

ext4

3. Find:

C:\Users\user\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\rootfs\usr\share\man\man5\ext4.5.gz