Conversation
… PATH bash.exe crashes with 0xC0000139 (STATUS_ENTRYPOINT_NOT_FOUND) on Nano Server -- a loaded DLL is present but missing an export, not a missing DLL. Replace the now-answered A/B/C/D probe (bare `bash -c echo` already proven to crash) with data gathering: dump the full conda m2-bash tree and its DLLs to see whether the msys-* runtime is complete and where it sits, and retry a bare bash builtin with Library\usr\bin + Library\bin on PATH in case mise's absolute-path launch left the runtime off the loader search path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The tree dump proved msys-2.0.dll (v3.6) sits next to bash.exe and a PATH-augmented retry still crashed with 0xC0000139, so msys-2.0.dll imports a Win32 entry point Nano Server doesn't export. Install llvm-mingw (static native toolchain that runs on Nano) just to dump msys-2.0.dll's and bash.exe's imported DLLs/symbols, naming the exact system DLL to backfill from the servercore donor. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
mise's github: backend installs under installs\github-mstorsjo-llvm-mingw\ <ver>\bin, not \llvm-mingw\, so the prior dir match was empty and the empty for-loop left errorlevel 1 (skipping ver>/dev/null). Point RODIR at the real versioned bin dir and call llvm-readobj directly, with ver>/dev/null outside any loop so the diagnostic always exits 0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root cause of the 0xC0000139 (STATUS_ENTRYPOINT_NOT_FOUND) bash crash on Nano Server, found by extracting msys-2.0.dll + bash.exe from the conda packages, pulling Nano's full System32 DLL set + api-set schema from mcr, and transitively resolving every import: msys-2.0.dll imports exactly two symbols Nano's stripped kernel32 forwarder doesn't re-export -- KERNEL32.dll!IdnToAscii and !IdnToUnicode -- everything else (incl. bash.exe's own kernel32/user32 imports) resolves. The functions exist on Nano (real exports in KernelBase.dll; normaliz.dll + the api-ms-win-core-localization contract expose them); only the kernel32-named door is missing. Server Core's full kernel32.dll exports both (forwarding to normaliz/kernelbase, present here), same ltsc2022 / 10.0.20348 baseline, so drop it in over Nano's kernel32 forwarder (+ a System32 root copy). Replace the readobj diagnostics with a bash smoke-test that confirms the load in the CI log. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
docker COPY can't overwrite Nano's ACL-locked System32\forwarders\ kernel32.dll (Access denied on unlinkat), and kernel32 is a KnownDLL (*kernel32 in the registry) so a root/app-dir copy is ignored by the loader. Stage the Server Core donor kernel32.dll to a fresh path, then overwrite the forwarders copy (the KnownDLLs section source) from inside a RUN as ContainerAdministrator after an icacls grant. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The bash-tasks died with `mise: not found` (127) under busybox: mise, when it spawns a shell it recognizes (bash/sh/zsh/fish/ksh/dash), rewrites the task PATH to msys/Cygwin form (/c/mise/bin:...). busybox-w32 is native Win32 and can't resolve those, so command lookup failed -- while the same busybox launched from cmd (Windows-form PATH) found mise fine. `ash` is not in mise's POSIX-shell list, so naming the busybox binary `ash.exe` skips that PATH conversion; busybox still selects its `ash` applet from argv[0], and gets the Windows-form PATH it understands. Update the http:busybox bin, the winsh var, and MISE_BASH_PATH/WINSH accordingly; collapse the diagnostics into one smoke that checks busybox can find mise. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With bash now working (busybox ash), the build reached the final `mise install`, where the cargo: tools (taplo-cli, wasm-pack, ...) failed: `rustup could not choose a version of cargo ... no default is configured`. mise's rust tool uses RUSTUP_HOME=C:\.rustup (where setup-windows set the 1.96.0-gnu default), but mise's cargo backend spawns `cargo install` without rust's exec_env, so rustup fell back to the empty %USERPROFILE%\.rustup. Pin CARGO_HOME/RUSTUP_HOME globally so every cargo/rustup invocation sees the .rustup that has the gnu default. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
With RUSTUP_HOME pinned, the cargo: tools compile but fail: `error calling dlltool 'x86_64-w64-mingw32-dlltool': program not found` -- mise's cargo backend doesn't activate llvm-mingw onto the build subprocess's PATH, so rustc can't find dlltool or the gnu linker. Pin llvm-mingw to a fixed version and prepend its <install>\bin to PATH in Dockerfile.windows. Also skip taplo on Windows: cargo:taplo-cli pulls `ring` (needs a C/asm toolchain the gnu Nano build lacks), and TOML linting runs in the Linux check job -- so exclude the tool on windows and short-circuit taplo-check there (POSIX guard, runs on busybox ash). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
setup-all is the shared internal base the per-OS setup tasks depend on; it shouldn't be invoked outside the mise config. Switch the workflows' Windows arm from `mise run setup-all` to `mise run setup-windows` (which also installs the gnu toolchain + flips rustup to gnu). README already uses setup-windows. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
taiki-e/install-action installs mise 2026.6.1, below the new min_version = "2026.6.5" floor, so every mise invocation aborts and check/test/dependencies fail at the first step. Pin the install to 2026.6.5 (the release with auto_env) so CI satisfies the floor. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two regressions surfaced once the gnullvm link fix let the Windows build run far enough to reach tooling, and once setup-linux moved out of config.toml: - Dockerfile.windows: pipx:semgrep shells out to `pipx`, but the full `mise install` ran before pipx was pip-installed. Install python + pipx (Scripts dir on PATH) first, then the full install. - Dockerfile (linux): build-minimal copied only config.toml, so the relocated setup-linux task (now in config.linux.toml) and auto_env (.miserc.toml) were missing. Copy both into the minimal stage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Both docker jobs got further after the prior fixes and surfaced new failures: - Dockerfile (linux): the `rust` tool is a two-version list (latest + nightly); installed in parallel they run two rustup-inits at once and race on the shared rustup binary's self-update, so the second exits 1. MISE_JOBS=1 serializes the install. Validated with a local `docker build --target build-minimal`. - Dockerfile.windows: pip dropped pipx.exe outside the prefix Scripts dir that was on PATH, so the full `mise install` couldn't find pipx for pipx:semgrep. Add the per-user AppData Scripts dir to PATH too and log the resolved location. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pip installs pipx.exe into python's versioned Scripts dir (...\python\3.13.14\Scripts), whose patch component isn't stable, so the hardcoded ...\python\3.13\Scripts on PATH never matched and pipx:semgrep still failed with "program not found". Locate pipx.exe with `dir /s` and copy it into C:\mise\bin (already on PATH); the pip launcher .exe embeds the python path so it runs from there. Confirmed the real location via the prior build's diagnostic output. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pipx crashes at import on Nano Server: platformdirs.user_data_path() calls SHGetFolderPathW, a shell known-folder API Nano lacks, and it runs at module import so no pipx env var avoids it. semgrep is only ever run by `mise run check` on Linux, so disable just pipx:semgrep via MISE_DISABLE_TOOLS rather than excluding it on all Windows (real Windows dev boxes run pipx fine). Drops the now-pointless python+pipx install/copy dance; python installs with the rest via the main `mise install`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The guest-language stage failed because Nano Server can't run dotnet's PowerShell installer or pipx (python's tools). Restrict MISE_ENV to the guests that install cleanly on Nano -- dart, java, rust, zig -- and use `mise install` instead of install-all (which forces $ALL_LANGS and would re-add dotnet + python). semgrep stays skipped via MISE_DISABLE_TOOLS. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Switch ast-grep/cargo-deny/taplo/wasm-pack/watchexec from `cargo:` source builds to prebuilt aqua binaries. cargo-expand has no prebuilt (crates.io only), so it stays source-built and is disabled in both Docker images via MISE_DISABLE_TOOLS. - Prefix the Linux config vars (a_/b_/c_ tiers) so taplo's reorder_keys keeps every definition before its use; alphabetising had moved a value after the var that reads it and broke `mise install` tera rendering. - Provision the Windows gnullvm stable+nightly toolchains with their components and wasm targets in preinstall (rustup had installed them against the pre-flip host). Fixes the wasm-agent `-Z build-std` "rust-src missing" failure and stops wasm-pack downloading rust-std mid-build. - Build the wasm-agent with `wasm-pack --mode no-install` so it uses the mise-pinned wasm-bindgen rather than fetching its own. - Move clippy config to config/clippy.toml, add config/lychee.toml + link-check, refresh the .miserc.toml auto_env note, and reclaim Docker CI disk via easimon/maximize-build-space. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Revert `wasm-pack --mode no-install` on build-ws-wasm-agent: it stopped wasm-pack downloading wasm-bindgen but also couldn't use the mise-provided one, failing every rust/build job with "Not able to find or install a local wasm-bindgen". - Bump github:wasm-bindgen 0.2.114 -> 0.2.122 to match Cargo.lock, so wasm-pack finds the matching binary on PATH and downloads nothing (what --mode no-install was meant to do). - Add the mise-no-source-backends taplo schema: ban `cargo:`/`ubi:` tool backends in .mise/config*.toml, allowlisting cargo-expand + dart-typegen. - Trim the exec_auto_install / task.run_auto_install comment. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
build-modules failed on the Nano image at build-ws-audio1-module: wasm-opt
(binaryen) can't execute there (os error 3). The earlier --no-opt fix only
covered build-ws-wasm-agent; the standard module builds still ran wasm-opt.
Gate it via a shared {{ vars.no_opt }} (empty default, --no-opt on Windows) used
by all 12 wasm-pack module builds and the wasm-agent. wasm-opt still runs on
Linux/macOS, where the shipped browser artifacts are built.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pierre-tenedero
approved these changes
Jun 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.