darling icon indicating copy to clipboard operation
darling copied to clipboard
verified publisher icon darlinghq

Tracking WSL1 support

Open trungnt2910 opened this issue 3 years ago • 10 comments

Opening this issue to track WSL1 support.

According to the Darling docs:

WSL1 is more complicated and is not currently working.

There is no explicit statement from Darling denying support of WSL1, so this issue should be valid.

Currently, there are a few main issues:

  • The pidfd_open syscall (since Linux 5.3) and the mmap MAP_FIXED_NOREPLACE flag (since Linux 4.17) is not available on Linux 4.4.0 (WSL1 kernel). (addressed in https://github.com/darlinghq/darlingserver/pull/4 and https://github.com/darlinghq/darling/pull/1207)
  • https://github.com/microsoft/WSL/issues/8095 (workaround added in https://github.com/darlinghq/darling/pull/1207)
  • https://github.com/microsoft/WSL/issues/8742 (workaround added in https://github.com/darlinghq/darlingserver/pull/4 and https://github.com/darlinghq/darling/pull/1207)
  • https://github.com/microsoft/WSL/issues/8748 (workaround added in https://github.com/darlinghq/darlingserver/pull/5)
  • https://github.com/microsoft/WSL/issues/8757 (workaround added in https://github.com/darlinghq/darling-libkqueue/pull/3 and https://github.com/darlinghq/darling/pull/1209)
  • https://github.com/microsoft/WSL/issues/2555 (workaround added in https://github.com/darlinghq/darling/pull/1209)
  • https://github.com/microsoft/WSL/issues/8777 (workaround added in https://github.com/darlinghq/darlingserver/pull/5)

System Information

Software Version
Linux Kernel 4.4.0-22000-Microsoft
Darling e385bb9d9898987119c6514d01d403204e00704d

trungnt2910 avatar Aug 21 '22 14:08 trungnt2910

At the time of writing, when #1209 is merged, darling shell can now run launchd and spawn essential system daemons, including shellspawn.

Very simple binaries, such as uname, can be loaded and run: image

Other binaries, including essential ones such as bash and g++, cannot run due to a hanging mach_msg_overwrite call. Any help here is appreciated.

trungnt2910 avatar Aug 25 '22 02:08 trungnt2910

xtrace works well, and with its help, more details about the bash hang can be obtained:

trung@DESKTOP-5OCA2N2:~$ sudo -E strace -u trung -v -s 4096 -ff -o /home/trung/darlingtrace/trace.txt darling /home/trung/.darling/usr/bin/xtrace bash
[sudo] password for trung:
xtrace: failed to dlsym(/usr/lib/darling/xtrace-mig/libnotify_xtrace_mig.dylib, "xtrace_mig_subsystem"): dlsym(0x7f0d3b9b7f70, xtrace_mig_subsystem): symbol not found
[45] sigprocmask(1, NULL, 0x7FFFFFDFFD30) -> 0
[45] sigaltstack(NULL, 0x7FFFFFDFFD20) -> 0
[45] open("/dev/tty", O_RDWR|O_NONBLOCK, 996530944) -> 3
[45] close(3) -> 0
[45] open_nocancel("/usr/share/locale/C.UTF-8/LC_COLLATE", O_RDONLY, -2100347) -> ENOENT
[45] open_nocancel("/usr/share/locale/C.UTF-8/LC_COLLATE", O_RDONLY, -2100347) -> ENOENT
[45] open_nocancel("/usr/local/share/locale/C.UTF-8/LC_COLLATE", O_RDONLY, -2100341) -> ENOENT
[45] getuid() -> 1000
[45] getgid() -> 1000
[45] geteuid() -> 1000
[45] getegid() -> 1000
[45] sigprocmask(1, NULL, 0x7FFFFFDFFD30) -> 0
[45] sigaltstack(NULL, 0x7FFFFFDFFD20) -> 0
[45] gettimeofday(0x7FFFFFDFFD10, NULL, NULL) -> 0
[45] ioctl(0, 1074030202, 0x7FFFFFDFFCE4) -> 0
[45] ioctl(2, 1074030202, 0x7FFFFFDFFCE4) -> 0
[45] fstat64(2, 0x7FFFFFDFFAE0) -> 0
[45] fstat64(1, 0x7FFFFFDFFAE0) -> 0
[45] sigaction(20, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(20, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(2, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(2, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(3, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(3, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(15, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(15, 0x7FFFFFDFFB40, 0x7FFFFFDFFBB0) -> 0
[45] sigaction(1, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(2, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(4, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(5, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(6, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(7, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(8, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(10, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(11, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(12, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(13, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(14, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(15, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(24, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(25, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(26, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(30, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigaction(31, 0x7FFFFFDFFB20, 0x7FFFFFDFFB98) -> 0
[45] sigprocmask(1, NULL, 0x1000DB7B4) -> 0
[45] sigaction(3, 0x7FFFFFDFFB20, 0x7FFFFFDFFB90) -> 0
[45] sigaction(2, 0x7FFFFFDFFB20, 0x7FFFFFDFFB90) -> 0
[45] sigaction(15, 0x7FFFFFDFFB20, 0x7FFFFFDFFB90) -> 0
[45] sigaction(28, 0x7FFFFFDFFB10, 0x7FFFFFDFFB80) -> 0
[45] sigaction(2, 0x7FFFFFDFFB30, 0x7FFFFFDFFBA0) -> 0
[45] sigaction(18, 0x7FFFFFDFFB30, 0x7FFFFFDFFBA0) -> 0
[45] sigaction(22, 0x7FFFFFDFFB30, 0x7FFFFFDFFBA0) -> 0
[45] sigaction(21, 0x7FFFFFDFFB30, 0x7FFFFFDFFBA0) -> 0
[45] sysctl(0x7FFFFFDFFBF0, 2, 0x7FFFFFDFFAE0, 0x7FFFFFDFFAC0, NULL, 0) -> 0
[45] mach_msg_trap(0x7FFFFFDFF238, MACH_SEND_MSG|MACH_RCV_MSG, 188, 108, port 1543, 0, port 0)
[45]         {remote = copy send 1799, local = make send-once 1543, id = 404}, 164 bytes of inline data
[45]         job::look_up2(copy send 1799, "com.apple.system.notification_center", 0, [240, 7, 8, 0, 36, 255, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0], 8)

The interesting line is:

[45]         job::look_up2(copy send 1799, "com.apple.system.notification_center", 0, [240, 7, 8, 0, 36, 255, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0], 8)

trungnt2910 avatar Aug 28 '22 16:08 trungnt2910

image

A bash shell now works and can run neofetch, but the system as a whole is still quite unstable.

trungnt2910 avatar Aug 29 '22 15:08 trungnt2910

On the update_source_11.5 branch, there seems to be a regression with the same job::look_up2: When running sysctl (the thing that neofetch gets its "Uptime" from:

Darling [~]$ xtrace sysctl -n kern.boottime
xtrace: failed to dlsym(/usr/lib/darling/xtrace-mig/libnotify_xtrace_mig.dylib, "xtrace_mig_subsystem"): dlsym(0x7f7a08026050, xtrace_mig_subsystem): symbol not found
[177] open_nocancel("/usr/share/locale/C.UTF-8/LC_NUMERIC", O_RDONLY, 0) -> ENOENT
[177] open_nocancel("/usr/share/locale/C.UTF-8/LC_NUMERIC", O_RDONLY, 0) -> ENOENT
[177] open_nocancel("/usr/local/share/locale/C.UTF-8/LC_NUMERIC", O_RDONLY, 0) -> ENOENT
[177] sysctl(0x7FFFFFDFF580, 2, 0x7FFFFFDFFE20, 0x7FFFFFDFF558, 0x7FFFFFDFFA20, 13) -> 0
[177] sysctl(0x7FFFFFDFF550, 4, 0x7FFFFFDFF150, 0x7FFFFFDFF118, NULL, 0) -> 0
[177] sysctl(0x7FFFFFDFEC20, 4, 0x7FFFFFDFE820, 0x7FFFFFDFE7E8, NULL, 0) -> 0
[177] sysctl(0x7FFFFFDFED40, 4, 0x7FFFFFDFED80, 0x7FFFFFDFECC8, NULL, 0) -> 0
[177] sysctl(0x7FFFFFDFFE20, 2, NULL, 0x7FFFFFDFECC8, NULL, 0) -> 0
[177] sysctl(0x7FFFFFDFFE20, 2, 0x7F7A0727AE90, 0x7FFFFFDFECC0, NULL, 0) -> 0
[177] write_nocancel(1, 0x7FFFFFDFE580, 31){ sec = 1678950087, usec = 0 }  -> 31
[177] access("/etc/localtime", 4) -> 0
[177] open_nocancel("/etc/localtime", O_RDONLY, 0) -> 3
[177] fstat64(3, 0x7FFFFFDFE238) -> 0
[177] _kernelrpc_mach_vm_map_trap(...)
[177]     mmap(0x1000, 45056, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0) -> 0x7F7A06770000
[177] _kernelrpc_mach_vm_map_trap() -> KERN_SUCCESS
[177] _kernelrpc_mach_vm_map_trap(...)
[177]     mmap(0x1000, 4096, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, -1, 0) -> 0x7F7A06760000
[177] _kernelrpc_mach_vm_map_trap() -> KERN_SUCCESS
[177] read_nocancel(3, 0x7F7A06770000, 41448) -> 2190
[177] close_nocancel(3) -> 0
[177] issetugid() -> 0
[177] open_nocancel("/var/db/timezone/zoneinfo/posixrules", O_RDONLY, 0) -> ENOENT
[177] madvise(0x7F7A06770000, 45056, 9) -> 0
[177] mach_msg_trap(0x7FFFFFDFDDA8, MACH_SEND_MSG|MACH_RCV_MSG, 188, 108, port 1543, 0, port 0)
[177]         {remote = copy send 1799, local = make send-once 1543, id = 404}, 164 bytes of inline data
[177]         job::look_up2(copy send 1799, "com.apple.system.notification_center", 0, [253, 7, 8, 0, 108, 255, 122, 0, 0, 0, 0, 0, 0, 0, 0, 0], 8)

Similar for curl:

Darling [~]$ xtrace curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh
xtrace: failed to dlsym(/usr/lib/darling/xtrace-mig/libnotify_xtrace_mig.dylib, "xtrace_mig_subsystem"): dlsym(0x7ff84ec37ca0, xtrace_mig_subsystem): symbol not found
[180] getuid() -> 1000
[180] mach_msg_trap(0x7FFFFFDFAF08, MACH_SEND_MSG|MACH_RCV_MSG, 188, 108, port 1543, 0, port 0)
[180]         {remote = copy send 1799, local = make send-once 1543, id = 404}, 164 bytes of inline data
[180]         job::look_up2(copy send 1799, "com.apple.system.notification_center", 0, [253, 7, 8, 0, 226, 255, 248, 0, 0, 0, 0, 0, 0, 0, 0, 0], 8)

trungnt2910 avatar Mar 16 '23 20:03 trungnt2910

@trungnt2910 aside from https://github.com/microsoft/WSL/issues/8742, every linked issues here seems to have been resolved. have you found a workaround of https://github.com/microsoft/WSL/issues/8742? What's the latest update on this WSL1 support as a whole?

mominshaikhdevs avatar Apr 01 '24 07:04 mominshaikhdevs

every linked issues here seems to have been resolved.

No, they haven't, unless you actually tested it yourself. See this comment for more details.

What's the latest update on this WSL1 support as a whole?

Still unstable as usual. I have given up on this in favor of porting the XNU kernel directly on top of lxmonika, or at least, a full Linux kernel to host normal Darling on.

trungnt2910 avatar Apr 01 '24 11:04 trungnt2910

image

For those interested, this is a screenshot of neofetch on WSL1 on a pretty ancient build (one year old?) of update_source_11.5.

Make sure to terminate the WSL distro (or at least, run a killall -9 mldr) after finishing your Darling session, unless you are OK with a bunch of zombie mldrs taking 90% of your CPU.

trungnt2910 avatar Apr 01 '24 11:04 trungnt2910

in favor of porting the XNU kernel directly on top of lxmonika

Screenshot_20240401-175405

@trungnt2910 do you have a separate project that focuses on porting the XNU Kernel directly (on top of lxmonika)?

mominshaikhdevs avatar Apr 01 '24 11:04 mominshaikhdevs

do you have a separate project that focuses on porting the XNU Kernel directly

Currently not. Very slow progress is being made to finalize the core infrastructure of lxmonika (for more details see my Discord).

Then, the focus will shift to porting the latest LTS Linux release, effectively creating a direct competitor to WSL1 and WSL2.

trungnt2910 avatar Apr 01 '24 12:04 trungnt2910

Currently not. Very slow progress is being made to finalize the core infrastructure of lxmonika (for more details see my Discord).

you are doing what Microsoft should have done in the first place.

You are a Genius.

mominshaikhdevs avatar Apr 01 '24 13:04 mominshaikhdevs