github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-08-30 17:25:30 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #15897] issue: The docker image v0.6.18 does not run correctly on rpi #88451

New Issue
Closed
opened 2026-05-15 13:00:40 -05:00 by GiteaMirror · 18 comments
GiteaMirror commented 2026-05-15 13:00:40 -05:00
Owner
Copy Link
Copy Source

Originally created by @sinfallas on GitHub (Jul 21, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/15897

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.6.18

Ollama Version (if applicable)

No response

Operating System

Debian GNU/Linux 12 (bookworm) aarch64

Browser (if applicable)

mozilla firefox 140

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

download and run the docker image

Actual Behavior

The docker image v0.6.18 does not run correctly and keeps restarting on aarch64 raspberry pi 4 model B with 8 Gb of RAM

The operating system is Debian 12 and Docker version 28.3.2, build 578ccf6

Steps to Reproduce

install docker using docker-compose located in the following github repository: https://github.com/tecno-consultores/llm-lab

The command to run it is the following: docker compose -f docker-compose.yml --env-file env.example --profile openwebui up -d

Logs & Screenshots

INFO [open_webui.env] 'SOUGOU_API_SID' loaded from the latest database entry
INFO [open_webui.env] 'SOUGOU_API_SK' loaded from the latest database entry
INFO [open_webui.env] 'TAVILY_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'TAVILY_EXTRACT_DEPTH' loaded from the latest database entry
INFO [open_webui.env] 'PLAYWRIGHT_WS_URL' loaded from the latest database entry
INFO [open_webui.env] 'PLAYWRIGHT_TIMEOUT' loaded from the latest database entry
INFO [open_webui.env] 'FIRECRAWL_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'FIRECRAWL_API_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'IMAGE_GENERATION_ENGINE' loaded from the latest database entry
INFO [open_webui.env] 'ENABLE_IMAGE_GENERATION' loaded from the latest database entry
INFO [open_webui.env] 'ENABLE_IMAGE_PROMPT_GENERATION' loaded from the latest database entry
INFO [open_webui.env] 'AUTOMATIC1111_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'AUTOMATIC1111_API_AUTH' loaded from the latest database entry
INFO [open_webui.env] 'COMFYUI_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'COMFYUI_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'COMFYUI_WORKFLOW' loaded from the latest database entry
INFO [open_webui.env] 'COMFYUI_WORKFLOW' loaded from the latest database entry
INFO [open_webui.env] 'IMAGES_OPENAI_API_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'IMAGES_OPENAI_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'IMAGES_GEMINI_API_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'IMAGES_GEMINI_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'WHISPER_MODEL' loaded from the latest database entry
INFO [open_webui.env] 'DEEPGRAM_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_OPENAI_API_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_OPENAI_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_ENGINE' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_MODEL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_AZURE_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_AZURE_REGION' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_AZURE_LOCALES' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_AZURE_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_STT_AZURE_MAX_SPEAKERS' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_OPENAI_API_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_OPENAI_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_API_KEY' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_ENGINE' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_MODEL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_VOICE' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_SPLIT_ON' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_REGION' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_BASE_URL' loaded from the latest database entry
INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_OUTPUT_FORMAT' loaded from the latest database entry
INFO [open_webui.env] 'ENABLE_LDAP' loaded from the latest database entry
WARNI [langchain_community.utils.user_agent] USER_AGENT environment variable not set, consider setting it to identify your requests.

Additional Information

No response

Originally created by @sinfallas on GitHub (Jul 21, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/15897 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.18 ### Ollama Version (if applicable) _No response_ ### Operating System Debian GNU/Linux 12 (bookworm) aarch64 ### Browser (if applicable) mozilla firefox 140 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior download and run the docker image ### Actual Behavior The docker image v0.6.18 does not run correctly and keeps restarting on aarch64 raspberry pi 4 model B with 8 Gb of RAM The operating system is Debian 12 and Docker version 28.3.2, build 578ccf6 ### Steps to Reproduce install docker using docker-compose located in the following github repository: https://github.com/tecno-consultores/llm-lab The command to run it is the following: docker compose -f docker-compose.yml --env-file env.example --profile openwebui up -d ### Logs & Screenshots INFO [open_webui.env] 'SOUGOU_API_SID' loaded from the latest database entry INFO [open_webui.env] 'SOUGOU_API_SK' loaded from the latest database entry INFO [open_webui.env] 'TAVILY_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'TAVILY_EXTRACT_DEPTH' loaded from the latest database entry INFO [open_webui.env] 'PLAYWRIGHT_WS_URL' loaded from the latest database entry INFO [open_webui.env] 'PLAYWRIGHT_TIMEOUT' loaded from the latest database entry INFO [open_webui.env] 'FIRECRAWL_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'FIRECRAWL_API_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'IMAGE_GENERATION_ENGINE' loaded from the latest database entry INFO [open_webui.env] 'ENABLE_IMAGE_GENERATION' loaded from the latest database entry INFO [open_webui.env] 'ENABLE_IMAGE_PROMPT_GENERATION' loaded from the latest database entry INFO [open_webui.env] 'AUTOMATIC1111_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'AUTOMATIC1111_API_AUTH' loaded from the latest database entry INFO [open_webui.env] 'COMFYUI_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'COMFYUI_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'COMFYUI_WORKFLOW' loaded from the latest database entry INFO [open_webui.env] 'COMFYUI_WORKFLOW' loaded from the latest database entry INFO [open_webui.env] 'IMAGES_OPENAI_API_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'IMAGES_OPENAI_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'IMAGES_GEMINI_API_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'IMAGES_GEMINI_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'WHISPER_MODEL' loaded from the latest database entry INFO [open_webui.env] 'DEEPGRAM_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_OPENAI_API_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_OPENAI_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_ENGINE' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_MODEL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_AZURE_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_AZURE_REGION' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_AZURE_LOCALES' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_AZURE_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_STT_AZURE_MAX_SPEAKERS' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_OPENAI_API_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_OPENAI_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_API_KEY' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_ENGINE' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_MODEL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_VOICE' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_SPLIT_ON' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_REGION' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_BASE_URL' loaded from the latest database entry INFO [open_webui.env] 'AUDIO_TTS_AZURE_SPEECH_OUTPUT_FORMAT' loaded from the latest database entry INFO [open_webui.env] 'ENABLE_LDAP' loaded from the latest database entry WARNI [langchain_community.utils.user_agent] USER_AGENT environment variable not set, consider setting it to identify your requests. ### Additional Information _No response_
GiteaMirror added the bug label 2026-05-15 13:00:40 -05:00
GiteaMirror commented 2026-05-15 13:00:42 -05:00
Author
Owner
Copy Link
Copy Source

@theghostglitch commented on GitHub (Jul 21, 2025):

Confirmed, same issue. Had it working fine, but failed to load after pulling an update with docker compose pull. No errors in docker logs. It just continues to cycle between docker heath status "Starting" and "Restarting" when doing a docker ps.

<!-- gh-comment-id:3095104314 --> @theghostglitch commented on GitHub (Jul 21, 2025): Confirmed, same issue. Had it working fine, but failed to load after pulling an update with docker compose pull. No errors in docker logs. It just continues to cycle between docker heath status "Starting" and "Restarting" when doing a docker ps.
GiteaMirror commented 2026-05-15 13:00:42 -05:00
Author
Owner
Copy Link
Copy Source

@tjbck commented on GitHub (Jul 21, 2025):

Unable to reproduce, are you running it on rpi?

<!-- gh-comment-id:3095467966 --> @tjbck commented on GitHub (Jul 21, 2025): Unable to reproduce, are you running it on rpi?
GiteaMirror commented 2026-05-15 13:00:42 -05:00
Author
Owner
Copy Link
Copy Source

@geoffmunn commented on GitHub (Jul 21, 2025):

Can confirm, running this command will result in an unresponsive docker container:
docker run -d --name open-webui -p 3000:8080 ghcr.io/open-webui/open-webui:v0.6.18

Can anyone suggest a tag that does work on a Raspberry Pi?

<!-- gh-comment-id:3095552324 --> @geoffmunn commented on GitHub (Jul 21, 2025): Can confirm, running this command will result in an unresponsive docker container: `docker run -d --name open-webui -p 3000:8080 ghcr.io/open-webui/open-webui:v0.6.18` Can anyone suggest a tag that does work on a Raspberry Pi?
GiteaMirror commented 2026-05-15 13:00:42 -05:00
Author
Owner
Copy Link
Copy Source

@beecho01 commented on GitHub (Jul 21, 2025):

I have updated from 0.6.16 this yesterday via watchtower, and I can conform the issue is present.

  • When running as a fresh install, it appears to restart the docker image consistently after the embedding model is setup.
  • After an update, however, it appears to give the same as the original post, a restart of the docker image after the enable LDAP.

I am running this on a Raspberry Pi 5 and can assist with more tests if required.

<!-- gh-comment-id:3096055862 --> @beecho01 commented on GitHub (Jul 21, 2025): I have updated from 0.6.16 this yesterday via watchtower, and I can conform the issue is present. - When running as a fresh install, it appears to restart the docker image consistently after the embedding model is setup. - After an update, however, it appears to give the same as the original post, a restart of the docker image after the enable LDAP. I am running this on a Raspberry Pi 5 and can assist with more tests if required.
GiteaMirror commented 2026-05-15 13:00:43 -05:00
Author
Owner
Copy Link
Copy Source

@amoshydra commented on GitHub (Jul 21, 2025):

Running RPi 3B.

i can confirm having this issue on both 0.6.17 and 0.6.18.
downgrading to 0.6.16 works.

attempted previous suggestions for RPI users (https://github.com/open-webui/open-webui/discussions/4331#discussioncomment-10409754), such as:

  • use dev branch (doesn't help)
  • create a separare Dockerfile and install different torch version. Tried torch,torchaudio(2.7.0), torchvision(0.22.0) these were the latest version when 0.6.16 were released. (doesn't help)
<!-- gh-comment-id:3096259090 --> @amoshydra commented on GitHub (Jul 21, 2025): Running RPi 3B. i can confirm having this issue on both 0.6.17 and 0.6.18. downgrading to 0.6.16 works. attempted previous suggestions for RPI users (https://github.com/open-webui/open-webui/discussions/4331#discussioncomment-10409754), such as: - use dev branch (doesn't help) - create a separare Dockerfile and install different torch version. Tried torch,torchaudio(2.7.0), torchvision(0.22.0) these were the latest version when 0.6.16 were released. (doesn't help)
GiteaMirror commented 2026-05-15 13:00:43 -05:00
Author
Owner
Copy Link
Copy Source

@sinfallas commented on GitHub (Jul 21, 2025):

Unable to reproduce, are you running it on rpi?

Yes, the failure appeared while I ran it on a raspbery pi 4 version B 8 GB of ram

<!-- gh-comment-id:3096741377 --> @sinfallas commented on GitHub (Jul 21, 2025): > Unable to reproduce, are you running it on rpi? Yes, the failure appeared while I ran it on a raspbery pi 4 version B 8 GB of ram
GiteaMirror commented 2026-05-15 13:00:43 -05:00
Author
Owner
Copy Link
Copy Source

@amoshydra commented on GitHub (Jul 21, 2025):

I tried running the server inside the docker exec, manage to get more error message in 0.6.17 inside my rpi

docker compose -it open-webui bash
./start.sh

I manage to see new error message:

WARNI [langchain_community.utils.user_agent] USER_AGENT environment variable not set, consider setting it to identify your requests.

 ██████╗ ██████╗ ███████╗███╗   ██╗    ██╗    ██╗███████╗██████╗ ██╗   ██╗██╗
██╔═══██╗██╔══██╗██╔════╝████╗  ██║    ██║    ██║██╔════╝██╔══██╗██║   ██║██║
██║   ██║██████╔╝█████╗  ██╔██╗ ██║    ██║ █╗ ██║█████╗  ██████╔╝██║   ██║██║
██║   ██║██╔═══╝ ██╔══╝  ██║╚██╗██║    ██║███╗██║██╔══╝  ██╔══██╗██║   ██║██║
╚██████╔╝██║     ███████╗██║ ╚████║    ╚███╔███╔╝███████╗██████╔╝╚██████╔╝██║
 ╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═══╝     ╚══╝╚══╝ ╚══════╝╚═════╝  ╚═════╝ ╚═╝


v0.6.17 - building the best AI user interface.

https://github.com/open-webui/open-webui
Illegal instruction (core dumped)

I started placing print statements to see where the code get stuck:

terminal screenshot showing runtime crash at get_ef

^ terminal screenshot showing server crash at get_ef

looking deeper inside get_ef, the server will crash in:

from sentence_transformers import SentenceTransformer
terminal screenshot showing server crash at when importing sentence-transformers

^ terminal screenshot showing server crash at when importing sentence-transformers

Probably a torch issue again?
https://github.com/UKPLab/sentence-transformers/issues/1120#issuecomment-901206516

<!-- gh-comment-id:3096990188 --> @amoshydra commented on GitHub (Jul 21, 2025): I tried running the server inside the docker exec, manage to get more error message in 0.6.17 inside my rpi ``` docker compose -it open-webui bash ./start.sh ``` I manage to see new error message: ``` WARNI [langchain_community.utils.user_agent] USER_AGENT environment variable not set, consider setting it to identify your requests. ██████╗ ██████╗ ███████╗███╗ ██╗ ██╗ ██╗███████╗██████╗ ██╗ ██╗██╗ ██╔═══██╗██╔══██╗██╔════╝████╗ ██║ ██║ ██║██╔════╝██╔══██╗██║ ██║██║ ██║ ██║██████╔╝█████╗ ██╔██╗ ██║ ██║ █╗ ██║█████╗ ██████╔╝██║ ██║██║ ██║ ██║██╔═══╝ ██╔══╝ ██║╚██╗██║ ██║███╗██║██╔══╝ ██╔══██╗██║ ██║██║ ╚██████╔╝██║ ███████╗██║ ╚████║ ╚███╔███╔╝███████╗██████╔╝╚██████╔╝██║ ╚═════╝ ╚═╝ ╚══════╝╚═╝ ╚═══╝ ╚══╝╚══╝ ╚══════╝╚═════╝ ╚═════╝ ╚═╝ v0.6.17 - building the best AI user interface. https://github.com/open-webui/open-webui Illegal instruction (core dumped) ``` I started placing print statements to see where the code get stuck: <img width="2167" height="851" alt="terminal screenshot showing runtime crash at get_ef" src="https://github.com/user-attachments/assets/28406078-1e77-426d-a8ec-da544e3725e5" /> \^ terminal screenshot showing server crash at `get_ef` looking deeper inside `get_ef`, the server will crash in: ```py from sentence_transformers import SentenceTransformer ``` <img width="2167" height="851" alt="terminal screenshot showing server crash at when importing sentence-transformers" src="https://github.com/user-attachments/assets/d80a7f84-c932-468d-8180-b8268cf4abe8" /> \^ terminal screenshot showing server crash at when importing `sentence-transformers` Probably a `torch` issue again? https://github.com/UKPLab/sentence-transformers/issues/1120#issuecomment-901206516
GiteaMirror commented 2026-05-15 13:00:44 -05:00
Author
Owner
Copy Link
Copy Source

@rgaricano commented on GitHub (Jul 21, 2025):

very good debugging work,
but sentence transformer lib version has not change in a few versions the most recent lib (that can be related), changes was langchain and pydantic,
you can see blame: https://github.com/open-webui/open-webui/blame/5fbfe2bdcadf5f157926f6551891e4dc0802b9f3/backend/requirements.txt

<!-- gh-comment-id:3097187573 --> @rgaricano commented on GitHub (Jul 21, 2025): very good debugging work, but sentence transformer lib version has not change in a few versions the most recent lib (that can be related), changes was langchain and pydantic, you can see blame: https://github.com/open-webui/open-webui/blame/5fbfe2bdcadf5f157926f6551891e4dc0802b9f3/backend/requirements.txt
GiteaMirror commented 2026-05-15 13:00:44 -05:00
Author
Owner
Copy Link
Copy Source

@amoshydra commented on GitHub (Jul 22, 2025):

a new day with a new discovery.

between 0.6.16 and 0.6.18 the docker images bundled with a different version of pyarrow.

- pyarrow==20.0.0
+ pyarrow==21.0.0

pinning pyarrow version to 20.0.0 resolves the Illegal instruction (core dumped) issue and I am able to start the server in my Raspberry PI 3B again.

Notes

  • I am not sure where pyarrow come from, it could be one of the transitive dependency.
  • I am not able to tell from pyarrow's changelog what is the breaking change between 20 to 21. https://arrow.apache.org/release/21.0.0.html

Troubleshoot steps

Inside my Raspberry PI's open-webui's container, dump out the installed python versions using pip3 list and compare the 2.

(1)

docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash
pip3 list

(2)

docker run -it ghcr.io/open-webui/open-webui:0.6.16 bash
pip3 list

one prominent difference is the pyarrow version installed.

Expand to see the full differences Image

after several trial and error, I discovered that pinning pyarrow version to 20.0.0 resolve the issue:

docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash

echo "pyarrow==20.0.0" >> requirements.txt
uv pip install --system -r requirements.txt --no-cache-dir

# In erroneous case, simply importing sentence_transformers will cause Illegal instruction (core dumped) error
python -c "from sentence_transformers import SentenceTransformer;"

# finally no error, so let's start the server 
./start.sh
Image

I am able to start the server afterwards.

Question

Is it reasonable to pin pyarrow version to 20 inside requirements.txt?
I am not sure how this can be tested for future release.

<!-- gh-comment-id:3103251662 --> @amoshydra commented on GitHub (Jul 22, 2025): a new day with a new discovery. between 0.6.16 and 0.6.18 the docker images bundled with a different version of `pyarrow`. ```diff - pyarrow==20.0.0 + pyarrow==21.0.0 ``` pinning `pyarrow` version to 20.0.0 resolves the `Illegal instruction (core dumped)` issue and I am able to start the server in my Raspberry PI 3B again. ### Notes - I am not sure where `pyarrow` come from, it could be one of the transitive dependency. - I am not able to tell from `pyarrow`'s changelog what is the breaking change between 20 to 21. https://arrow.apache.org/release/21.0.0.html ### Troubleshoot steps Inside my Raspberry PI's `open-webui`'s container, dump out the installed python versions using `pip3 list` and compare the 2. (1) ```bash docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash pip3 list ``` (2) ```bash docker run -it ghcr.io/open-webui/open-webui:0.6.16 bash pip3 list ``` one prominent difference is the `pyarrow` version installed. <details> <summary>Expand to see the full differences</summary> <img width="904" height="2239" alt="Image" src="https://github.com/user-attachments/assets/7239b71f-46fc-49b0-b810-3403ede04f2c" /> </details> after several trial and error, I discovered that pinning `pyarrow` version to 20.0.0 resolve the issue: ```bash docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash echo "pyarrow==20.0.0" >> requirements.txt uv pip install --system -r requirements.txt --no-cache-dir # In erroneous case, simply importing sentence_transformers will cause Illegal instruction (core dumped) error python -c "from sentence_transformers import SentenceTransformer;" # finally no error, so let's start the server ./start.sh ``` <img width="2782" height="1641" alt="Image" src="https://github.com/user-attachments/assets/ae72b26f-7662-4fc0-8049-65fcbf5b311a" /> I am able to start the server afterwards. ### Question Is it reasonable to pin `pyarrow` version to 20 inside `requirements.txt`? I am not sure how this can be tested for future release.
GiteaMirror commented 2026-05-15 13:00:45 -05:00
Author
Owner
Copy Link
Copy Source

@beecho01 commented on GitHub (Jul 22, 2025):

a new day with a new discovery.

between 0.6.16 and 0.6.18 the docker images bundled with a different version of pyarrow.

  • pyarrow==21.0.0
  • pyarrow==20.0.0
    pinning pyarrow version to 20.0.0 resolve the Illegal instruction (core dumped) issue and I am able to start the server in my Raspberry PI 3B again.

Notes

  • I am not sure where pyarrow come from, it could be one of the transitive dependency.
  • I am not able to tell from pyarrow's changelog what is the breaking change between 20 to 21. https://arrow.apache.org/release/21.0.0.html

Troubleshoot steps

Inside my Raspberry PI's open-webui's container, dump out the installed python versions using pip3 list and compare the 2.

(1)

docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash
pip3 list
(2)

docker run -it ghcr.io/open-webui/open-webui:0.6.16 bash
pip3 list
one prominent difference is the pyarrow version installed.

Expand to see the full differences
after several trial and error, I discovered that pinning pyarrow version to 20.0.0 resolve the issue:

docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash

echo "pyarrow==20.0.0" >> requirements.txt
uv pip install --system -r requirements.txt --no-cache-dir

In erroneous case, simply importing sentence_transformers will cause Illegal instruction (core dumped) error

python -c "from sentence_transformers import SentenceTransformer;"

finally no error, so let's start the server

./start.sh
Image
I am able to start the server afterwards.

Question

Is it reasonable to pin pyarrow version to 20 inside requirements.txt? I am not sure how this can be tested for future release.

Great debugging

<!-- gh-comment-id:3103310746 --> @beecho01 commented on GitHub (Jul 22, 2025): > a new day with a new discovery. > > between 0.6.16 and 0.6.18 the docker images bundled with a different version of `pyarrow`. > > - pyarrow==21.0.0 > + pyarrow==20.0.0 > pinning `pyarrow` version to 20.0.0 resolve the `Illegal instruction (core dumped)` issue and I am able to start the server in my Raspberry PI 3B again. > > ### Notes > * I am not sure where `pyarrow` come from, it could be one of the transitive dependency. > * I am not able to tell from `pyarrow`'s changelog what is the breaking change between 20 to 21. https://arrow.apache.org/release/21.0.0.html > > ### Troubleshoot steps > Inside my Raspberry PI's `open-webui`'s container, dump out the installed python versions using `pip3 list` and compare the 2. > > (1) > > docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash > pip3 list > (2) > > docker run -it ghcr.io/open-webui/open-webui:0.6.16 bash > pip3 list > one prominent difference is the `pyarrow` version installed. > > Expand to see the full differences > after several trial and error, I discovered that pinning `pyarrow` version to 20.0.0 resolve the issue: > > docker run -it ghcr.io/open-webui/open-webui:0.6.18 bash > > echo "pyarrow==20.0.0" >> requirements.txt > uv pip install --system -r requirements.txt --no-cache-dir > > # In erroneous case, simply importing sentence_transformers will cause Illegal instruction (core dumped) error > python -c "from sentence_transformers import SentenceTransformer;" > > # finally no error, so let's start the server > ./start.sh > <img alt="Image" width="2000" height="1641" src="https://private-user-images.githubusercontent.com/8733840/469266940-ae72b26f-7662-4fc0-8049-65fcbf5b311a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTMxOTc2NTYsIm5iZiI6MTc1MzE5NzM1NiwicGF0aCI6Ii84NzMzODQwLzQ2OTI2Njk0MC1hZTcyYjI2Zi03NjYyLTRmYzAtODA0OS02NWZjYmY1YjMxMWEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDcyMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTA3MjJUMTUxNTU2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9OTlmMDUzZmQ1ZTc5Y2NkZWE5ZDVmODFiMGZjYTcyMDY3OGFkMzI1YTYzODhlZGM0MjI5YTMyYTRlNjJmZjg0ZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.DUKb3JOvRpeLYWROi2CmgI7cpwx2ZF40apuxq5aB73M"> > I am able to start the server afterwards. > > ### Question > Is it reasonable to pin `pyarrow` version to 20 inside `requirements.txt`? I am not sure how this can be tested for future release. Great debugging
GiteaMirror commented 2026-05-15 13:00:46 -05:00
Author
Owner
Copy Link
Copy Source

@rgaricano commented on GitHub (Jul 22, 2025):

pyarrow issue: https://github.com/apache/arrow/issues/20848#issuecomment-1377737869

Question
Is it reasonable to pin pyarrow version to 20 inside requirements.txt?
I am not sure how this can be tested for future release.

pyarrow reverse dependency tree (in my python 3.12):
(pipdeptree -p pyarrow -r)

pyarrow==20.0.0
├── datasets==2.21.0 [requires: pyarrow>=15.0.0]
│   ├── browsergym-assistantbench==0.13.3 [requires: datasets]
│   │   └── browsergym==0.13.3 [requires: browsergym-assistantbench==0.13.3]
│   ├── colbert-ai==0.2.21 [requires: datasets]
│   ├── evaluate==0.4.3 [requires: datasets>=2.0.0]
│   │   ├── libvisualwebarena==0.0.15 [requires: evaluate]
│   │   │   └── browsergym-visualwebarena==0.13.3 [requires: libvisualwebarena==0.0.15]
│   │   │       └── browsergym==0.13.3 [requires: browsergym-visualwebarena==0.13.3]
│   │   └── libwebarena==0.0.4 [requires: evaluate]
│   │       └── browsergym-webarena==0.13.3 [requires: libwebarena==0.0.4]
│   │           ├── browsergym==0.13.3 [requires: browsergym-webarena==0.13.3]
│   │           └── browsergym-visualwebarena==0.13.3 [requires: browsergym-webarena]
│   │               └── browsergym==0.13.3 [requires: browsergym-visualwebarena==0.13.3]
│   └── weblinx-browsergym==0.0.1.dev14 [requires: datasets]
│       └── browsergym==0.13.3 [requires: weblinx-browsergym>=0.0.1dev14]
├── graphrag==1.2.0 [requires: pyarrow>=15.0.0]
└── pylance==0.20.0 [requires: pyarrow>=14]
    └── lancedb==0.17.0 [requires: pylance==0.20.0]
        └── graphrag==1.2.0 [requires: lancedb>=0.17.0,<0.18.0]

I think that you can force it to 20.0.0 without problem, datasets requiere only >15

Note: I have installed pyarrow 20.0.0, with pythom 3.12 and all requirements libs updated (I'm replace == & ~= by >= ), I don't know why this lib is in version 21.0.0.
Logically, if I have all the libraries updated to their latest version, I should also have that updated if there were any dependencies. Maybe some other that I have installed force it to that version 20.0.0??

By the way, all run fine, any problem!

<!-- gh-comment-id:3103372840 --> @rgaricano commented on GitHub (Jul 22, 2025): pyarrow issue: https://github.com/apache/arrow/issues/20848#issuecomment-1377737869 > Question Is it reasonable to pin pyarrow version to 20 inside requirements.txt? I am not sure how this can be tested for future release. pyarrow reverse dependency tree (in my python 3.12): (`pipdeptree -p pyarrow -r`) ``` pyarrow==20.0.0 ├── datasets==2.21.0 [requires: pyarrow>=15.0.0] │ ├── browsergym-assistantbench==0.13.3 [requires: datasets] │ │ └── browsergym==0.13.3 [requires: browsergym-assistantbench==0.13.3] │ ├── colbert-ai==0.2.21 [requires: datasets] │ ├── evaluate==0.4.3 [requires: datasets>=2.0.0] │ │ ├── libvisualwebarena==0.0.15 [requires: evaluate] │ │ │ └── browsergym-visualwebarena==0.13.3 [requires: libvisualwebarena==0.0.15] │ │ │ └── browsergym==0.13.3 [requires: browsergym-visualwebarena==0.13.3] │ │ └── libwebarena==0.0.4 [requires: evaluate] │ │ └── browsergym-webarena==0.13.3 [requires: libwebarena==0.0.4] │ │ ├── browsergym==0.13.3 [requires: browsergym-webarena==0.13.3] │ │ └── browsergym-visualwebarena==0.13.3 [requires: browsergym-webarena] │ │ └── browsergym==0.13.3 [requires: browsergym-visualwebarena==0.13.3] │ └── weblinx-browsergym==0.0.1.dev14 [requires: datasets] │ └── browsergym==0.13.3 [requires: weblinx-browsergym>=0.0.1dev14] ├── graphrag==1.2.0 [requires: pyarrow>=15.0.0] └── pylance==0.20.0 [requires: pyarrow>=14] └── lancedb==0.17.0 [requires: pylance==0.20.0] └── graphrag==1.2.0 [requires: lancedb>=0.17.0,<0.18.0] ``` I think that you can force it to 20.0.0 without problem, datasets requiere only >15 Note: I have installed pyarrow 20.0.0, with pythom 3.12 and all requirements libs updated (I'm replace == & ~= by >= ), I don't know why this lib is in version 21.0.0. Logically, if I have all the libraries updated to their latest version, I should also have that updated if there were any dependencies. Maybe some other that I have installed force it to that version 20.0.0?? By the way, all run fine, any problem!
GiteaMirror commented 2026-05-15 13:00:46 -05:00
Author
Owner
Copy Link
Copy Source

@Fluqzy commented on GitHub (Jul 22, 2025):

would it be possible, that we can get a new docker image with this pyarrow fix?
Although I'm quite advanced with docker, I'm not really sure if i get it to run correctly and reliable. Getting a new hotfix would definitely be helpful.

Thanks in advance!

<!-- gh-comment-id:3103576749 --> @Fluqzy commented on GitHub (Jul 22, 2025): would it be possible, that we can get a new docker image with this pyarrow fix? Although I'm quite advanced with docker, I'm not really sure if i get it to run correctly and reliable. Getting a new hotfix would definitely be helpful. Thanks in advance!
GiteaMirror commented 2026-05-15 13:00:47 -05:00
Author
Owner
Copy Link
Copy Source

@okynnor commented on GitHub (Jul 22, 2025):

I confirm that this problem is happening on the raspberry PI 4. When I deploy the same yaml file to an intel-based system, openWebUI loads and runs perfectly fine.
Seems like pyarrow is the issue and a new image for raspberry PI will be released soon.

<!-- gh-comment-id:3104849923 --> @okynnor commented on GitHub (Jul 22, 2025): I confirm that this problem is happening on the raspberry PI 4. When I deploy the same yaml file to an intel-based system, openWebUI loads and runs perfectly fine. Seems like pyarrow is the issue and a new image for raspberry PI will be released soon.
GiteaMirror commented 2026-05-15 13:00:48 -05:00
Author
Owner
Copy Link
Copy Source

@rgaricano commented on GitHub (Jul 22, 2025):

would it be possible, that we can get a new docker image with this pyarrow fix? Although I'm quite advanced with docker, I'm not really sure if i get it to run correctly and reliable. Getting a new hotfix would definitely be helpful.

Thanks in advance!

Until it is released, you can force the change in your current Docker:

run docker, then

docker exec -it open-webui /bin/bash
pip install -U pyarrow==20.0.0
exit

& try it (restart docker)

<!-- gh-comment-id:3105033373 --> @rgaricano commented on GitHub (Jul 22, 2025): > would it be possible, that we can get a new docker image with this pyarrow fix? Although I'm quite advanced with docker, I'm not really sure if i get it to run correctly and reliable. Getting a new hotfix would definitely be helpful. > > Thanks in advance! Until it is released, you can force the change in your current Docker: run docker, then ``` docker exec -it open-webui /bin/bash pip install -U pyarrow==20.0.0 exit ``` & try it (restart docker)
GiteaMirror commented 2026-05-15 13:00:48 -05:00
Author
Owner
Copy Link
Copy Source

@laszloturanyi commented on GitHub (Jul 25, 2025):

Same behavior confirmed on jetson nano (not orin, but the old version)

<!-- gh-comment-id:3116963580 --> @laszloturanyi commented on GitHub (Jul 25, 2025): Same behavior confirmed on jetson nano (not orin, but the old version)
GiteaMirror commented 2026-05-15 13:00:48 -05:00
Author
Owner
Copy Link
Copy Source

@beecho01 commented on GitHub (Aug 8, 2025):

I updated my docker compose on my Raspberry Pi OS to:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.6.18@sha256:52128ce9dab9dfdcbcaa25133e35eeab4fa7337e689843b3a2a4ceaade0e78bf
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - "./data:/app/backend/data"
    environment:
      WEBUI_SECRET_KEY: "xxxxxxxxxxxxxxxxxxxxx"
      TZ: "Europe/London"
      OLLAMA_BASE_URL: "http://192.168.0.xxx:11434"
      USER_AGENT: "xxxxxxxxxxxx"
      RAG_EMBEDDING_MODEL: "snowflake-arctic-embed:335m"
    restart: always
    labels:
      com.centurylinklabs.watchtower.enable: "true"
    extra_hosts:
      - "host.docker.internal:host-gateway"

Then running:

docker compose pull

Followed by:

docker compose up -d

I then immediately tried

docker compose exec open-webui bash -lc "pip install -U pyarrow==20.0.0" && docker compose restart open-webui

Which appeared to resolve my issue.

<!-- gh-comment-id:3167012216 --> @beecho01 commented on GitHub (Aug 8, 2025): I updated my docker compose on my Raspberry Pi OS to: ``` services: open-webui: image: ghcr.io/open-webui/open-webui:v0.6.18@sha256:52128ce9dab9dfdcbcaa25133e35eeab4fa7337e689843b3a2a4ceaade0e78bf container_name: open-webui ports: - "3000:8080" volumes: - "./data:/app/backend/data" environment: WEBUI_SECRET_KEY: "xxxxxxxxxxxxxxxxxxxxx" TZ: "Europe/London" OLLAMA_BASE_URL: "http://192.168.0.xxx:11434" USER_AGENT: "xxxxxxxxxxxx" RAG_EMBEDDING_MODEL: "snowflake-arctic-embed:335m" restart: always labels: com.centurylinklabs.watchtower.enable: "true" extra_hosts: - "host.docker.internal:host-gateway" ``` Then running: ``` docker compose pull ``` Followed by: ``` docker compose up -d ``` I then immediately tried ``` docker compose exec open-webui bash -lc "pip install -U pyarrow==20.0.0" && docker compose restart open-webui ``` Which appeared to resolve my issue.
GiteaMirror commented 2026-05-15 13:00:49 -05:00
Author
Owner
Copy Link
Copy Source

@kaka272 commented on GitHub (Aug 8, 2025):

Unable to reproduce, are you running it on rpi?

same question，anyone slove it ?

<!-- gh-comment-id:3168013157 --> @kaka272 commented on GitHub (Aug 8, 2025): > Unable to reproduce, are you running it on rpi? same question，anyone slove it ?
GiteaMirror commented 2026-05-15 13:00:49 -05:00
Author
Owner
Copy Link
Copy Source

@KodeMunkie commented on GitHub (Aug 8, 2025):

Not solved but workaround without the hassle of a custom build.
I always run from a docker compose file so I have a variant of the following - add your personal settings as required:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/open-webui:/app/backend/data
    restart: always
    command: >
      bash -c "pip install -U pyarrow==20.0.0 && ./start.sh"
volumes:
  open-webui:
<!-- gh-comment-id:3168984673 --> @KodeMunkie commented on GitHub (Aug 8, 2025): Not solved but workaround without the hassle of a custom build. I always run from a docker compose file so I have a variant of the following - add your personal settings as required: ``` services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - "3000:8080" volumes: - CHANGE_TO_COMPOSE_DATA_PATH/open-webui:/app/backend/data restart: always command: > bash -c "pip install -U pyarrow==20.0.0 && ./start.sh" volumes: open-webui: ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#88451