Tracking WSL1 support - Githubissues

trungnt2910 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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

trungnt2910 commented 1 year ago

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)

mominshaikhdevs commented 7 months ago

@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?

trungnt2910 commented 7 months ago

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 commented 7 months ago

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.

mominshaikhdevs commented 7 months ago

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)?

trungnt2910 commented 7 months ago

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.

mominshaikhdevs commented 7 months ago

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.

darlinghq / darling

Tracking WSL1 support #1206