-
-
Notifications
You must be signed in to change notification settings - Fork 104
Systemd units known to be problematic under WSL
Even with an AppArmor-supporting kernel, the service runs but exits with the message "Not starting AppArmor in container."
This is working as intended since WSL technically is a container, but leaves the system insecure. To make AppArmor operate normally under WSL 2, an AppArmor patch is required.
Please see this article for further details and the patch:
https://randombytes.substack.com/p/apparmor-on-wsl-2
Fails with the following error(s):
Error - audit support not in kernel
Cannot open netlink audit socket
The default WSL kernel does not include auditing support. (If you have a use case for auditing under WSL, compile and use a custom kernel which includes it.) Even if this is done, auditd does not support running within a PID namespace, which both the genie bottle and WSL itself are. auditd cannot be made to work under WSL at this time. Disable/mask this unit.
Some images (including the Ubuntu distro) include cloud-init, a tool used to initialize various settings for containers or virtual machines running on cloud providers. This serves no purpose under WSL, and indeed will fail after a lengthy DHCP timeout.
Disable it with the following command:
touch /etc/cloud/cloud-init.disabled
Fails with the following error:
Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
The default WSL kernel does not include the multipath support. If you have a use case for multipath under WSL, compile and use a custom kernel which includes it. Otherwise, disable/mask this unit.
ssh.service fails to start with the following error:
ssh.service: Failed with result 'exit-code'.
when running /usr/sbin/sshd you get the error:
sshd: no hostkeys available -- exiting.
The fix is to run:
sudo ssh-keygen -A
The default WSL kernel does not require any kernel modules, and any modules supplied by a distribution are unlikely to match the WSL-supplied kernel. Unless you are running a custom kernel with module support compiled in/in use, or have otherwise supplied suitable module support, disable/mask this unit.
If this service is listed among the failed units when systemd starts up, this indicates an issue with your network failing to configure itself properly. This is a consequence of a configuration error with another unit, most likely cloud-init.service or systemd-networkd.service. Check the logs and see the entries for those here.
Fails with the following error:
mount: /: can't find LABEL=cloudimg-rootfs.
This occurs because systemd-remount-fs is trying to remount the root partition to make sure that it has the options configured in /etc/fstab; and the Ubuntu default /etc/fstab assumes that the root partition is labeled "cloudimg-rootfs". This isn't the case under WSL (the root partition is one of its .vhdx files), so the remount fails. (This isn't strictly a problem with the service - you'd get the same error if you tried to remount / manually.)
There are two ways to solve this one: either find the device the root partition is mounted from (probably /dev/sdb, but check first), and label it appropriately:
sudo e2label /dev/sdb cloudimg-rootfs
or, if you're happy with the existing mount options for your root filesystem, simply delete the line for / from /etc/fstab entirely. WSL mounts it for you automatically and with reasonable options when starting up the distro, so unless you know that you need something different, there's not actually any point in having it there.
Both systemd-sysctl.service and systemd-sysusers.service utilize systemd credential, which may not work correctly in WSL.
This post describes the issue in detail.
To fix credential issues in WSL, add the following service:
[Unit]
Description=Fix the /dev/shm symlink to be a mount
DefaultDependencies=no
Before=sysinit.target
Before=systemd-sysctl.service # I need to add this line for systemd-sysctl.service to work
ConditionPathExists=/dev/shm
ConditionPathIsSymbolicLink=/dev/shm
ConditionPathIsMountPoint=/run/shm
[Service]
Type=oneshot
ExecStart=/usr/bin/rm /dev/shm
ExecStart=/usr/bin/mkdir /dev/shm
ExecStart=/bin/umount /run/shm
ExecStart=/usr/bin/rmdir /run/shm
ExecStart=/bin/mount -t tmpfs -o mode=1777,nosuid,nodev,strictatime tmpfs /dev/shm
ExecStart=/usr/bin/ln -s /dev/shm /run/shm
[Install]
WantedBy=sysinit.target
WantedBy=systemd-sysctl.service # I need to add this line for systemd-sysctl.service to work
Finally, make the eth0 interface unmanaged so networkd doesn't throw out the IP-address that HyperV / WSL2 assigned to it during boot:
cat << EOF > /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Link]
Unmanaged=yes
[Network]
DHCP=no
[DHCP]
UseDNS=false
EOF
Based on issue 203
From time to time fwupd-refresh.service & systemd-timedated.service fail resulting with "genie: WARNING: systemd is in degraded state, issues may occur!" when returning inside bottle.
Apr 10 11:46:04 flies-pc-wsl systemd[557225]:: Failed to set up mount namespacing: /run/systemd/unit-root/: No such device
Apr 10 11:46:04 flies-pc-wsl systemd[557225]: fwupd-refresh.service: Failed at step NAMESPACE spawning /usr/bin/fwupdmgr: No such device
Apr 06 20:21:13 flies-pc-wsl systemd[498898]: systemd-timedated.service: Failed to set up mount namespacing: /run/systemd/unit-root/: No such device
Apr 06 20:21:13 flies-pc-wsl systemd[498898]: systemd-timedated.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-timedated: No such device
Solution is to mask them: sudo systemctl mask fwupd-refresh.service