sdm: WSL support broken in V8.6

On my Windows 11 machine, sdm V8.6 does not work anymore in wsl.

sudo sdm --customize --locale de_DE.UTF-8 2023-05-03-raspios-bullseye-armhf-lite.img
* Mount IMG '2023-05-03-raspios-bullseye-armhf-lite.img'
mount: /dev/loop0p2 ist auf /mnt/sdm eingehängt.
mount: /dev/loop0p1 ist auf /mnt/sdm/boot eingehängt.
chmod: Zugriff auf '/mnt/sdm//usr/local/sdm/local-plugins/*' nicht möglich: Datei oder Verzeichnis nicht gefunden
* Start Configuration
> Command Line: /usr/local/bin/sdm --customize --locale de_DE.UTF-8
  2023-05-03-raspios-bullseye-armhf-lite.img
* Host Information
   Hostname: xxx
   uname: Linux xxx 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC
  2021 x86_64 x86_64 x86_64 GNU/Linux
   os-release Name: "Ubuntu"
   os-release Version: "22.04.1 LTS (Jammy Jellyfish)"
   sdm Version: V8.6
* IMG Information
   Date: 2023-05-03
   RasPiOS Version: 11
   os-release Version: "11 (bullseye)"
% No username specified with the --user switch; Using 'pi'
% sdm will try to use systemd-nspawn on this 'x86-64' system
  If this does not work please post a GitHub issue
> IMG '2023-05-03-raspios-bullseye-armhf-lite.img' has 294328 1K-blocks free
> Copy sdm to /usr/local/sdm in the IMG
* Start Phase 0 image customization
*+Phase 0 sdm configuration
*+Phase 0 Network configuration
*+Phase 0 User configuration
*+Phase 0 System configuration
*+Phase 0 Raspberry Pi-specific configuration
* Phase 0 Completed
* Enter image '2023-05-03-raspios-bullseye-armhf-lite.img' for Phase 1
Failed to open system bus: No such file or directory
umount: /mnt/sdm/boot ausgehängt
umount: /mnt/sdm ausgehängt

V7.17 does work in wsl. I installed V7.17 by downloading EZsdmInstaller, changing master in src to 48ca10bbbfad0dfa0774962ad13da5e96d8f5c20 and executing it.

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 19 (12 by maintainers)

Most upvoted comments

Great, thanks for confirming! Will be fixed in next release.

OK, thx. Wanted to make sure that it wasn’t customize-related. Apparently I cast chroot aside prematurely. It appears that systemd-nspawn on Ubuntu 22.04 doesn’t have the proper support.

I’ll revert the change in the next release, which is a few days out.

If you’d like to unblock (and help me out by testing it) you can manually revert the broken change:

  • sudoedit /usr/local/sdm/sdm-cparse
  • Find function initvirt
  • Change these lines
        # Not running sdm on ARM. Won't work if host is 32-bit without chroot, but just let it fail. Who runs 32-bit any more?
        IFS="," read wamielf wamiarch rest <<< "$wami"
        $msgrtn "% sdm will try to use systemd-nspawn on this '${wamiarch##\ }' system"
        $msgrtn "  If this does not work please post a GitHub issue"
        #$msgrtn "% Configure chroot for sdm on your '${wamiarch##\ }' computer"
        #$msgrtn "  * sdm will run more slowly due to qemu emulation"
        #virtmode="chroot"
        #[[ "$wtf" =~ "32-bit" ]] && vqemu="arm" || vqemu="aarch64"

to this:

        # Not running sdm on ARM. Won't work if host is 32-bit without chroot, but just let it fail. Who runs 32-bit any more?
        IFS="," read wamielf wamiarch rest <<< "$wami"
        #$msgrtn "% sdm will try to use systemd-nspawn on this '${wamiarch##\ }' system"
        #$msgrtn "  If this does not work please post a GitHub issue"
        $msgrtn "% Configure chroot for sdm on your '${wamiarch##\ }' computer"
        $msgrtn "  * sdm will run more slowly due to qemu emulation"
        virtmode="chroot"
        [[ "$wtf" =~ "32-bit" ]] && vqemu="arm" || vqemu="aarch64"

(comment out 2 lines, and uncomment 4 lines).

  • Save the file, exit, and test
  • Let me know if this resolves the issue (I don’t have a low-cost way to test, so counting on you 🙄)

thanks