JoergHH

Never mind, the AI and I figured it out. TL;DR kornia_rs ships precompiled Rust binaries built with an x86-64-v3 baseline (AVX2 + FMA3 + BMI2). On older Xeons (Ivy Bridge-EP and earlier) the import crashes with "Fatal Python error: Illegal instruction", so the container never reaches ComfyUI. Fix by placing a user_script.bash in the run folder that (1) disables AVX2/FMA3 for NumPy at runtime, (2) installs cmake, nasm, build-essential, pkg-config via sudo apt-get, (3) deletes the broken /comfy/mnt/venv/bin/cmake wrapper with rm -f, and (4) rebuilds kornia-rs from source — guarded by a pip show check so it only happens once. Full script below. ComfyUI-Nvidia-Docker fails to start on older Xeon CPUs (no AVX2) — kornia_rs "Illegal instruction" and cmake build failures — with fix Hardware/Software in question: - CPU: 2x Intel Xeon E5-2690 v2 (Ivy Bridge-EP, no AVX2 / FMA3) - GPU: NVIDIA RTX 3060 12 GB - Unraid 7.3.2 - Image: mmartial/comfyui-nvidia-docker:ubuntu24_cuda12.6.3-latest (also affects ubuntu24_cuda12.8-latest) - NVIDIA driver 610.43.03 (CUDA 13.3 host-side) SYMPTOM The container never reaches the ComfyUI server. Log ends with: Fatal Python error: Illegal instruction ... File "/comfy/mnt/venv/lib/python3.12/site-packages/kornia_rs/__init__.py", line 1 in <module> ... /comfyui-nvidia_init.bash: line 1057: 1359 Illegal instruction ${COMFY_CMDLINE_BASE} ${COMFY_CMDLINE_EXTRA} !! ERROR: ComfyUI failed or exited with an error ROOT CAUSE kornia_rs ships precompiled Rust binaries built with an x86-64-v3 baseline (AVX2 + FMA3 + BMI2). CPUs older than Haswell (like the Xeon E5-2690 v2) don't support these instructions, so the import crashes immediately. This is not an Unraid or Docker problem — it's a CPU-feature mismatch. A secondary issue appears once you try to rebuild kornia-rs from source inside the container: Traceback (most recent call last): File "/comfy/mnt/venv/bin/cmake", line 4, in <module> from cmake import cmake ModuleNotFoundError: No module named 'cmake' The venv contains a broken Python cmake wrapper at /comfy/mnt/venv/bin/cmake. The Rust build script for turbojpeg-sys (a kornia-rs dependency) picks that wrapper from PATH and fails. "pip install cmake" makes it worse; "pip uninstall cmake" leaves the wrapper file behind. FIX The project supports a user_script.bash placed in the run folder (/comfy/mnt), which is executed on every container start. Use it to: 1. Disable AVX2/FMA3 for NumPy at runtime (prevents the Illegal instruction crash). 2. Install the required system packages (cmake, nasm, build-essential, pkg-config) via sudo apt-get. 3. Delete the broken cmake wrapper (rm -f), so the Rust build picks up /usr/bin/cmake instead. 4. Rebuild kornia-rs from source — but only once, guarded by a pip show check, so subsequent container starts are fast. user_script.bash content (place in your run folder, e.g. /mnt/user/appdata/comfyui-nvidia/mnt/user_script.bash): #!/bin/bash set -e # Disable AVX2/FMA3 (Xeon E5-2690 v2 does not support these) export NPY_DISABLE_CPU_FEATURES="AVX2,FMA3" # Install build dependencies (sudo required - container runs as user 'comfy') sudo apt-get update && sudo apt-get install -y cmake nasm build-essential pkg-config # Remove the broken Python cmake wrapper from the venv rm -f /comfy/mnt/venv/bin/cmake # Make sure the system cmake is found export PATH="/usr/bin:/usr/local/bin:$PATH" # Build kornia-rs from source only once if ! /comfy/mnt/venv/bin/pip show kornia-rs > /dev/null 2>&1; then echo "== kornia-rs not installed, building from source..." /comfy/mnt/venv/bin/pip install kornia-rs --force-reinstall --no-cache-dir --no-binary :all: else echo "== kornia-rs already installed, skipping build." fi # Optional: enable Matrix sharing in ComfyUI-Manager /comfy/mnt/venv/bin/pip install matrix-nio Ownership matters. The container runs as UID 99 / GID 100 (nobody:users on Unraid). Set ownership before starting: chown 99:100 /path/to/run/user_script.bash chmod +x /path/to/run/user_script.bash NOTES / GOTCHAS ENCOUNTERED ALONG THE WAY - FORCE_CHOWN does not help for bind-mounted folders. If you see "Directory /comfy/mnt owned by unexpected user/group, expected 99:100, actual 0:0", run "chown -R 99:100 <host-path>" on the host. - apt-get inside the user script must use sudo. Without it you'll get "E: List directory /var/lib/apt/lists/partial is missing. - Acquire (13: Permission denied)". - Do NOT run "pip install cmake" in the venv — it creates the wrapper that breaks the build. If it's already there, "rm -f /comfy/mnt/venv/bin/cmake" is the fix (a plain "pip uninstall cmake" leaves the wrapper in place). - The "cu130 or higher" warning from comfy_kitchen in the startup log can be ignored on Ampere (RTX 30xx). It is only relevant for RTX 50xx / Blackwell. - First start is slow (Rust compile of kornia-rs can take several minutes on Ivy Bridge). Subsequent starts are fast because of the pip show guard. - Do not rename/delete the run folder between attempts unless the venv is genuinely broken. Editing user_script.bash in place is enough; the script runs on every container start. RESULT Device: cuda:0 NVIDIA GeForce RTX 3060 : cudaMallocAsync pytorch version: 2.14.0+cu126 ComfyUI version: 0.36.0 Starting server To see the GUI go to: http://0.0.0.0:8188 Everything works: GPU is detected, PyTorch uses CUDA, ComfyUI + Manager start normally. Hope this saves someone else a weekend. 😇

Isn't fixing errors YOUR job as the maintainer of the app/Docker container? When I install an app from the Community Applications, I should be able to expect it to work right out of the box, and not have to tinker with it as a user just to get it to work eventually, right? So, buddy, do your job! 😉

The container won't start for me either. Repository: mmartial/comfyui-nvidia-docker:ubuntu24_cuda13.2-latest TORCH_LOCK: torch==2.13.0+cu130 torchaudio==2.11.0+cu130 torchvision==0.28.0+cu130 /comfyui-nvidia_init.bash: line 1057: 814 Illegal instruction ${COMFY_CMDLINE_BASE} ${COMFY_CMDLINE_EXTRA} !! ERROR: ComfyUI failed or exited with an error !! Exiting script (ID: 115) !! ERROR: subscript failed !! Exiting script (ID: 1)

Great project, runs excellently - many thanks! But I wonder why there is no Docker icon. The .svg graphic is linked in the settings, but unfortunately Unraid can't do anything with it :,-( Anyway... I have made a suitable .png in the format 512 x 512, see attachment. Or you can use the online version: https://i.imgur.com/2WuVtUt.png

Since I also have problems with the renofischa docker, I switched to snorre0815. It seems to work better as it is the latest IDrive version 3.2.0: https://hub.docker.com/r/snorre0815/idrive-docker/

No. It simply didn't work, I didn't pursue the matter any further and I won't either. So it is done for me. Unfortunately.

Done and works as expected.

I am still on 6.9.2 and have the described problem. Unfortunately the patch is not offered to me via the App Store - what now?? I can't update to the current Unraid version at the moment for various reasons.

I just solved it myself. The line in Post Parameters (Advanced View) should read: lame-cleaner --device=cpu --port=8080 --host=0.0.0.0 I read it wrong, dumbass. 🙄

Nope, unfortunately it doesn't work: Command:root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='lama-cleaner' --net='bridge' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -p '8081:8080/tcp' -v '/mnt/user/appdata/lama-cleaner/torch_cache':'/root/.cache/torch':'rw' -v '/mnt/user/appdata/lama-cleaner/huggingface_cache':'/root/.cache/huggingface':'rw' 'cwq1913/lama-cleaner:cpu-0.26.1' --device=cpu --port=8080 --host=0.0.0.0 1b3a2a10a0ccbdc36f299a09e534bc0f66a90db7d0bd0b7ad96b0169893332f3 docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "--device=cpu": executable file not found in $PATH: unknown. The command failed.

I am trying to install Lama Cleaner (https://github.com/Sanster/lama-cleaner#docker) in the Docker CPU version, but I am not succeeding. Docker just doesn't want to start. Unfortunately I'm not the Docker expert either, but I suspect it's because of the options --device=cpu --port=8080 --host=0.0.0.0 is the reason. Can someone please help me and tell me what to put where in the template? Before the installation I had created the cache directories under .../appdata/lama-cleaner/.

Is there any way or chance to make step #1 persistent as well?

This means, however, that the Sundtek drivers must be (re)installed every time the container (image AKA app) is updated, right? Because changes in the container are not persistent.

Hmmm, so should I wait with the manual installation of the Sundtek drivers until they have landed in your plugin?

Is the documentation up to date now and may I assume that the whole installation has to be repeated for a Unraid system update?