> Can you elaborate on what will happen to users of older versions of wsl if they apply this update? Do they need to take some manual action? What will stop working or break?
Definetely! What happens depend on which version. Prior to WSL 2.5.1 ------------------- With the removal of the systemd-binfmt.service override it's possible for that service to break interop (the ability of launching Windows apps from the Linux shell) anytime it restarts. At boot time WSL implements some logic to perform the binfmt_registration that handles Windows executables after that unit starts so it shouldn't break by default at startup. But any action that causes systemd to restart it would break interop, for example installing qemu-user-static or python or any package that comes with binfmt_misc handlers. WSL 2.5.1 to WSL 2.5.6 ---------------------- WSL places a hook that runs together with systemd-binfmt.service such that once it restarts the hook acts and restores the WSL binfmt_misc registration, so interop wouldn't break. But the hook is removed when `systemctl daemon-load`, thus installing a combination of packages that causes systemd to reload daemons followed by a package that comes with binfmt_misc registration still break interop. One example of such combination is `binfmt-support` and `qemu-user-static`, common for users willing to debug ARM64 native binaries on AMD64 for instance. WSL 2.5.7 and later --------------------- WSL injects a systemd generator, thus reloading daemons recreates the hook that registers WSL binfmt_misc handler, thus interop is effectively protected. Updates to the WSL platform are released in a flexible cadence, always as pre-release until they mature a feature or fix and then they release a stable version. Users can opt-in for the pre-release versions by doing `wsl --update --pre-release`, otherwise they only receive stable versions. Since the systemd generator was implemented there were already 4 releases, two being marked as stable (one in April and another in June). So when I say that "We no longer consider those to be our main users, as there were already two stable releases of WSL since the fix was implemented." I mean that our main users are on the latest stable versions of WSL, most likely at the latest one. For those who opt for staying in older versions for whatever reasons, they will find documentation about what to do if interop becomes broken due systemd-binfmt.service. The way to handle that varies, some options are: - do nothing if the user doesn't care about interop at all - mask or disable systemd-binfmt.service if the user doesn't rely on it to register binfmt_misc handlers - re-gistering the binfmt handler manually (by writing a file at /proc/sys/fs/binfmt_misc/ with the correct settings) if it breaks once in a lifetime - or creating a systemd generator script that does the registration when systemd-binfmt.service starts (like the newer versions of WSL do) But most importantly we encourage our users to stay in the latest stable versions of the WSL platform and take advantage from the latest fixes and features unlocking new or previously blocked use cases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2118617 Title: [SRU] Ubuntu on WSL install fails on non-ASCII usernames To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wsl-setup/+bug/2118617/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
