Update FLM to 0.9.44 and enable portable FLM for Linux by superm1 · Pull Request #2544 · lemonade-sdk/lemonade

superm1 · 2026-07-04T15:29:53Z

FLM 0.9.44 has a portable Linux release available, adjust Lemonade to optionally use it.

tawei-amd · 2026-07-04T16:44:49Z

Awesome! When are you planning to merge it? We are trying to find a 26.04 system so we can thoroughly test the portable FLM asap.

superm1 · 2026-07-04T16:48:30Z

Awesome! When are you planning to merge it? We are trying to find a 26.04 system so we can thoroughly test the portable FLM asap.

Once you merge the FLM side and tag it will merge this side and we can test E2E.

PR #2544 enables portable FLM for Linux, but the extraction always uses --strip-components=1. The FLM tarball has files at the root (level: flm, lib/, xclbins/) with no wrapper directory, so stripping component 1 removes filenames entirely. Fix: list archive contents, detect if all entries share a single top-level directory with nested content. Only then use --strip-components=1; otherwise use 0 to preserve the original layout.

fl0rianr

Thanks! Looking forward bringing this in.

One thing I think we should fix before merging: FastFlowLMServer::load() now calls install_backend("flm", "npu") unconditionally before get_flm_path(). On Linux, the managed backend install path does not appear to treat an already-installed flm from PATH as an existing backend before the offline/no_fetch/download handling. That means a user with a valid system FLM in PATH could still hit an unnecessary GitHub download, and offline/no_fetch mode could fail before the later PATH lookup gets a chance to use the system FLM.

Could we skip install_backend on Linux when fastflowlm::find_flm_executable() already finds FLM, or otherwise make the install path recognize FLM's PATH install before attempting download/offline handling?

Side note, not blocking: I noticed archive_windows.cpp was updated too. From what I know, Lemonade currently uses zip or 7z assets on Windows, not tarballs. So this may simply be symmetry with the Unix extractor, but I wanted to mention it in case there is a Windows tarball path I missed. If this path is currently unused and was not tested, I think it is fine to address any potential Windows-specific tarball issue when the path is first needed.

superm1 · 2026-07-06T14:01:42Z

Thanks! Looking forward bringing this in.

One thing I think we should fix before merging: FastFlowLMServer::load() now calls install_backend("flm", "npu") unconditionally before get_flm_path(). On Linux, the managed backend install path does not appear to treat an already-installed flm from PATH as an existing backend before the offline/no_fetch/download handling. That means a user with a valid system FLM in PATH could still hit an unnecessary GitHub download, and offline/no_fetch mode could fail before the later PATH lookup gets a chance to use the system FLM.

Could we skip install_backend on Linux when fastflowlm::find_flm_executable() already finds FLM, or otherwise make the install path recognize FLM's PATH install before attempting download/offline handling?

It's a good call out. While fixing I looked over all the logic and noticed a bunch of complexity with the handling (code duplication and redundancy). I've adjusted the logic accordingly

Side note, not blocking: I noticed archive_windows.cpp was updated too. From what I know, Lemonade currently uses zip or 7z assets on Windows, not tarballs. So this may simply be symmetry with the Unix extractor, but I wanted to mention it in case there is a Windows tarball path I missed. If this path is currently unused and was not tested, I think it is fine to address any potential Windows-specific tarball issue when the path is first needed.

It was to make sure that if we started using tarballs on Windows things keep working. I've moved it into a common path to avoid the code duplication.

fl0rianr

Thanks, this looks much better now. The Linux PATH/offline case looks addressed to me.

Two small things I noticed:

The Linux unavailable/status action still points users to installing the FLM system package, while the docs and load path now say Lemonade can auto-install the portable FLM binary if FLM is not in PATH. I think the /system-info action should match that new behavior, probably by using the generic lemonade backends install flm:npu action or the Lemonade FLM troubleshooting page instead of only the upstream system package path.
The new compute_tarball_strip_components() helper seems to return 0 for common tar listings that include an explicit top-level directory entry, e.g. pkg/ followed by pkg/bin/flm. Since pkg/ gets normalized to pkg and then treated as a root-level entry, all_same_dir becomes false. This may not break the current FLM install because executable discovery is recursive, but it does not quite match the helper’s stated behavior. What do you think? A small test for top-level directory entries would make this safer?

Windows tarball question totally fine.

fl0rianr

Thanks, the previous two points look addressed to me now.

One remaining concern to think about: the new PATH-first logic now also changes Windows behavior. Previously Windows always went through install_backend() and find_flm_executable() explicitly avoided PATH, using the Lemonade-managed FLM install dir only. With the new shared resolver, any flm.exe on PATH now skips install_backend() and is preferred over the Lemonade-managed install.

That seems useful for Linux, but for Windows it could let a stale or unrelated PATH flm.exe shadow the managed FLM zip and prevent the pinned Lemonade-managed version from being installed/updated. Since this PR is about the new Linux portable FLM path, could we keep the PATH-bypass Linux-only, or keep Windows as managed-install-first?

superm1 · 2026-07-06T15:59:21Z

One remaining concern to think about: the new PATH-first logic now also changes Windows behavior. Previously Windows always went through install_backend() and find_flm_executable() explicitly avoided PATH, using the Lemonade-managed FLM install dir only. With the new shared resolver, any flm.exe on PATH now skips install_backend() and is preferred over the Lemonade-managed install.

Yes - this is intentional to have the same approach on both operating systems.

That seems useful for Linux, but for Windows it could let a stale or unrelated PATH flm.exe shadow the managed FLM zip and prevent the pinned Lemonade-managed version from being installed/updated. Since this PR is about the new Linux portable FLM path, could we keep the PATH-bypass Linux-only, or keep Windows as managed-install-first?

Then that means a lot of different code paths. Why should they be different?

fl0rianr

I just wanted to call it out because the old Windows path was managed-install-first.

Looks good to me otherwise, so go for it with a small caveat - I'm not at my 1151-sytem atm and was not able to test it properly.

FastFlowLM portable has a static build of ffmpeg and packages it's own libxrt.

PR #2544 enables portable FLM for Linux, but the extraction always uses --strip-components=1. The FLM tarball has files at the root (level: flm, lib/, xclbins/) with no wrapper directory, so stripping component 1 removes filenames entirely. Fix: list archive contents, detect if all entries share a single top-level directory with nested content. Only then use --strip-components=1; otherwise use 0 to preserve the original layout.

A system-managed FLM (Linux distro package on PATH) must not trigger a GitHub download and must keep working in offline/no_fetch mode. Guard the load-time install_backend so it only fetches when no PATH FLM is present; the managed install dir still goes through install_backend for updates. Unify FLM executable resolution into find_flm_executable() (config bin override, then PATH on Linux, then managed install dir) and reduce get_flm_path() to a single call. Factor the duplicated tarball strip-components detection into a shared header helper.

Replace the Linux-only #ifdef guard around load-time install_backend with a cross-platform find_flm_in_path() check, so a user-managed FLM on PATH is honored on Windows too (no download, works offline/no_fetch). The managed install dir still flows through install_backend for version-pinned updates. Extract find_flm_in_path() and reuse it inside find_flm_executable().

compute_tarball_strip_components() treated an explicit top-level directory entry (e.g. "pkg/" listed before "pkg/bin/flm") as a root-level file, which flipped all_same_dir false and returned strip 0. Distinguish directory entries (trailing slash) from genuine root-level files so listings with an explicit directory entry strip correctly. The FLM Linux /system-info action pointed only at the upstream system package, but Lemonade now auto-installs the portable FLM when none is on PATH. Use the generic backends install action for installable/update states and the Lemonade Linux troubleshooting page for driver/xrt issues, mirroring the Windows branch.

FLM's classify_unavailable override was added when Linux required a system package install (no auto-install), so it needed custom guidance. Now that the portable FLM auto-installs on Linux, the generic fallback ("Backend is supported but not installed") is correct. Remove the override so FLM shows the same friendly message as every other backend.

jeremyfowers · 2026-07-06T18:51:29Z

the new PATH-first logic now also changes Windows behavior. Previously Windows always went through install_backend() and find_flm_executable() explicitly avoided PATH, using the Lemonade-managed FLM install dir only.

There is no 100% right answer here, but from what I can tell this PR will instantly break Lemonade+FLM on my Windows PC, which would be sad.

My Windows PC has a stale copy of system FLM on it, so instead of using my nice up-to-date Lemonade-managed FLM, Lemonade will refer to the stale system copy and refuse to work until I do a manual update

This is the reason for the prior FLM-on-Windows policy, it "just works" 100% of the time (at the expense of people maybe having 2 copies of FLM on their system).

My preference is always for "it just works".

Add prefer_system: false to FLM's descriptor config_extra (matching llama.cpp's pattern). Update find_flm_in_path() to check the config value — PATH binaries are only used when the user enables {"flm": {"prefer_system": true}} in config.json. By default, Lemonade's managed FLM install takes precedence.

superm1 · 2026-07-06T21:42:16Z

I have adjusted it to have a new prefer_system setting similar to llama.cpp.

It defaults to false, which means that we will by default download a portable FLM for all distros and OSes.
If the user sets it to true, we try PATH first, and fall back to portable.
If the user sets no_fetch_executables we will fall back to PATH (portable will "fail")

…stem turned off

ramkrishna2910 · 2026-07-07T18:04:13Z

Looks good! All PATH usage is gated behind a new config flag flm.prefer_system that defaults to false.

* Bump FLM version to 0.9.44 * Add support for getting a portable flm asset * Update Linux NPU documentation * debian/control: Drop libxrt and ffmpeg recommends FastFlowLM portable has a static build of ffmpeg and packages it's own libxrt. * Detect tarball layout to avoid stripping root-level entries PR #2544 enables portable FLM for Linux, but the extraction always uses --strip-components=1. The FLM tarball has files at the root (level: flm, lib/, xclbins/) with no wrapper directory, so stripping component 1 removes filenames entirely. Fix: list archive contents, detect if all entries share a single top-level directory with nested content. Only then use --strip-components=1; otherwise use 0 to preserve the original layout. * Skip FLM backend install when a system FLM is on PATH A system-managed FLM (Linux distro package on PATH) must not trigger a GitHub download and must keep working in offline/no_fetch mode. Guard the load-time install_backend so it only fetches when no PATH FLM is present; the managed install dir still goes through install_backend for updates. Unify FLM executable resolution into find_flm_executable() (config bin override, then PATH on Linux, then managed install dir) and reduce get_flm_path() to a single call. Factor the duplicated tarball strip-components detection into a shared header helper. * Guard FLM install on PATH lookup instead of platform ifdef Replace the Linux-only #ifdef guard around load-time install_backend with a cross-platform find_flm_in_path() check, so a user-managed FLM on PATH is honored on Windows too (no download, works offline/no_fetch). The managed install dir still flows through install_backend for version-pinned updates. Extract find_flm_in_path() and reuse it inside find_flm_executable(). * Fix tarball strip detection and align FLM Linux status action compute_tarball_strip_components() treated an explicit top-level directory entry (e.g. "pkg/" listed before "pkg/bin/flm") as a root-level file, which flipped all_same_dir false and returned strip 0. Distinguish directory entries (trailing slash) from genuine root-level files so listings with an explicit directory entry strip correctly. The FLM Linux /system-info action pointed only at the upstream system package, but Lemonade now auto-installs the portable FLM when none is on PATH. Use the generic backends install action for installable/update states and the Lemonade Linux troubleshooting page for driver/xrt issues, mirroring the Windows branch. * Remove FLM custom classify_unavailable override FLM's classify_unavailable override was added when Linux required a system package install (no auto-install), so it needed custom guidance. Now that the portable FLM auto-installs on Linux, the generic fallback ("Backend is supported but not installed") is correct. Remove the override so FLM shows the same friendly message as every other backend. * Gate FLM PATH lookup behind prefer_system config Add prefer_system: false to FLM's descriptor config_extra (matching llama.cpp's pattern). Update find_flm_in_path() to check the config value — PATH binaries are only used when the user enables {"flm": {"prefer_system": true}} in config.json. By default, Lemonade's managed FLM install takes precedence. * Fallback to system FLM if portable fails to install even if prefer_system turned off * Use portable FLM for CI on Linux

…2544) * Bump FLM version to 0.9.44 * Add support for getting a portable flm asset * Update Linux NPU documentation * debian/control: Drop libxrt and ffmpeg recommends FastFlowLM portable has a static build of ffmpeg and packages it's own libxrt. * Detect tarball layout to avoid stripping root-level entries PR lemonade-sdk#2544 enables portable FLM for Linux, but the extraction always uses --strip-components=1. The FLM tarball has files at the root (level: flm, lib/, xclbins/) with no wrapper directory, so stripping component 1 removes filenames entirely. Fix: list archive contents, detect if all entries share a single top-level directory with nested content. Only then use --strip-components=1; otherwise use 0 to preserve the original layout. * Skip FLM backend install when a system FLM is on PATH A system-managed FLM (Linux distro package on PATH) must not trigger a GitHub download and must keep working in offline/no_fetch mode. Guard the load-time install_backend so it only fetches when no PATH FLM is present; the managed install dir still goes through install_backend for updates. Unify FLM executable resolution into find_flm_executable() (config bin override, then PATH on Linux, then managed install dir) and reduce get_flm_path() to a single call. Factor the duplicated tarball strip-components detection into a shared header helper. * Guard FLM install on PATH lookup instead of platform ifdef Replace the Linux-only #ifdef guard around load-time install_backend with a cross-platform find_flm_in_path() check, so a user-managed FLM on PATH is honored on Windows too (no download, works offline/no_fetch). The managed install dir still flows through install_backend for version-pinned updates. Extract find_flm_in_path() and reuse it inside find_flm_executable(). * Fix tarball strip detection and align FLM Linux status action compute_tarball_strip_components() treated an explicit top-level directory entry (e.g. "pkg/" listed before "pkg/bin/flm") as a root-level file, which flipped all_same_dir false and returned strip 0. Distinguish directory entries (trailing slash) from genuine root-level files so listings with an explicit directory entry strip correctly. The FLM Linux /system-info action pointed only at the upstream system package, but Lemonade now auto-installs the portable FLM when none is on PATH. Use the generic backends install action for installable/update states and the Lemonade Linux troubleshooting page for driver/xrt issues, mirroring the Windows branch. * Remove FLM custom classify_unavailable override FLM's classify_unavailable override was added when Linux required a system package install (no auto-install), so it needed custom guidance. Now that the portable FLM auto-installs on Linux, the generic fallback ("Backend is supported but not installed") is correct. Remove the override so FLM shows the same friendly message as every other backend. * Gate FLM PATH lookup behind prefer_system config Add prefer_system: false to FLM's descriptor config_extra (matching llama.cpp's pattern). Update find_flm_in_path() to check the config value — PATH binaries are only used when the user enables {"flm": {"prefer_system": true}} in config.json. By default, Lemonade's managed FLM install takes precedence. * Fallback to system FLM if portable fails to install even if prefer_system turned off * Use portable FLM for CI on Linux

AreYouLoco · 2026-07-17T17:06:26Z

@superm1 Well it broke NPU detection for me:
TL;DR

lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager) Backend availability:
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NPU hardware: Yes
[...]
Installing backend: flm:npu
Error: Cannot install flm:npu on this system: Requires AMD XDNA 2 AMD NPU

Additionally on host system:

$ flm validate
[Linux]  Kernel: 7.1.3+deb14-amd64
[Linux]  NPU: /dev/accel/accel0 with 8 columns
[Linux]  NPU FW Version: 1.1.2.64
[Linux]  amdxdna version: 0.8
[Linux]  Memlock Limit: infinity

Lemonade GUI is not even showing FastFlowLM as an option to install. Freshly pulled lemonade-server docker container and updated app from Flatpak. Both to 11.0.0

Full relevant log

areyouloco@minisforum-x1-pro:~/code/lemonade-server$ docker compose logs -f lemonade 
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main) Starting Lemonade Server...
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Version: 11.0.0
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Cache dir: /opt/lemonade/.cache/lemonade
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Port: 13305
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Host: 0.0.0.0
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Log level: info
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Telemetry: disabled
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (ModelManager) Loading "user_models.json"
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (ModelManager) Loading "recipe_options.json"
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (WebSocket) Configured port: 9000
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (Server) Starting HTTP server on 0.0.0.0:13305
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) Warming model list cache...
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) resolution failed for 0.0.0.0 no IPv6 resolution found.
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (Server) Host resolution: IPv4=0.0.0.0, IPv6=(none)
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (ModelManager) Building models cache...
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) Serving on non-loopback host '0.0.0.0' without an API key. All endpoints, including the /internal/* control endpoints, are reachable from other machines unauthenticated. Set LEMONADE_API_KEY to secure all endpoints; LEMONADE_ADMIN_API_KEY on its own only secures the /internal/* control endpoints.
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (WebSocket) Server started on port 9000
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) WebSocket server started on port 9000
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) Binding IPv4 HTTP server to 0.0.0.0:13305...
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) Broadcasting disabled by --no-broadcast option
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) IPv4 HTTP server listening on 0.0.0.0:13305
lemonade-server  | 2026-07-17 16:56:25.980 [Info] (BackendManager) Resolved 'latest' for ggml-org/llama.cpp -> b10064
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager) Backend availability:
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NPU hardware: Yes
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - System RAM: 124.4 GB (max model size: 99.5 GB)
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - Largest memory pool: 1.0
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NVIDIA GPU: detection error: No NVIDIA discrete GPU found
lemonade-server  | 2026-07-17 16:56:26.865 [Info] (ModelManager) Cache built: 134 total, 12 downloaded
lemonade-server  | 2026-07-17 16:56:27.377 [Info] (ModelManager) Update available for mradermacher/zen-musician-GGUF on Hugging Face: cached=68f57789b3452c5e6d, latest=b6f1ebe1d279fce8f6 (1 variant(s))
lemonade-server  | 2026-07-17 16:56:28.916 [Info] (ModelManager) Updates available for 1 model(s)
lemonade-server  | 2026-07-17 16:56:46.433 [Warn] (BackendManager) GitHub returned HTTP 403 for lemonade-sdk/llama.cpp
lemonade-server  | 2026-07-17 16:56:46.654 [Info] (BackendManager) Resolved 'latest' for lemonade-sdk/llama.cpp -> b10064
^C
areyouloco@minisforum-x1-pro:~/code/lemonade-server$ docker compose exec -it lemonade /bin/bash
lemonade@ffa80a312af5:~$ lemonade backends install flm:npu
Installing backend: flm:npu
Error: Cannot install flm:npu on this system: Requires AMD XDNA 2 AMD NPU

Any ideas what could go wrong here?

superm1 · 2026-07-17T17:08:03Z

@superm1 Well it broke NPU detection for me: TL;DR

lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager) Backend availability:
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NPU hardware: Yes
[...]
Installing backend: flm:npu
Error: Cannot install flm:npu on this system: Requires AMD XDNA 2 AMD NPU

Additionally on host system:

$ flm validate
[Linux]  Kernel: 7.1.3+deb14-amd64
[Linux]  NPU: /dev/accel/accel0 with 8 columns
[Linux]  NPU FW Version: 1.1.2.64
[Linux]  amdxdna version: 0.8
[Linux]  Memlock Limit: infinity

Lemonade GUI is not even showing FastFlowLM as an option to install. Freshly pulled lemonade-server docker container and updated app from Flatpak.

Full relevant log

areyouloco@minisforum-x1-pro:~/code/lemonade-server$ docker compose logs -f lemonade 
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main) Starting Lemonade Server...
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Version: 11.0.0
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Cache dir: /opt/lemonade/.cache/lemonade
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Port: 13305
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Host: 0.0.0.0
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Log level: info
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (main)   Telemetry: disabled
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (ModelManager) Loading "user_models.json"
lemonade-server  | 2026-07-17 16:56:25.628 [Info] (ModelManager) Loading "recipe_options.json"
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (WebSocket) Configured port: 9000
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (Server) Starting HTTP server on 0.0.0.0:13305
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) Warming model list cache...
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) resolution failed for 0.0.0.0 no IPv6 resolution found.
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (Server) Host resolution: IPv4=0.0.0.0, IPv6=(none)
lemonade-server  | 2026-07-17 16:56:25.631 [Info] (ModelManager) Building models cache...
lemonade-server  | 2026-07-17 16:56:25.631 [Warn] (Server) Serving on non-loopback host '0.0.0.0' without an API key. All endpoints, including the /internal/* control endpoints, are reachable from other machines unauthenticated. Set LEMONADE_API_KEY to secure all endpoints; LEMONADE_ADMIN_API_KEY on its own only secures the /internal/* control endpoints.
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (WebSocket) Server started on port 9000
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) WebSocket server started on port 9000
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) Binding IPv4 HTTP server to 0.0.0.0:13305...
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) Broadcasting disabled by --no-broadcast option
lemonade-server  | 2026-07-17 16:56:25.632 [Info] (Server) IPv4 HTTP server listening on 0.0.0.0:13305
lemonade-server  | 2026-07-17 16:56:25.980 [Info] (BackendManager) Resolved 'latest' for ggml-org/llama.cpp -> b10064
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager) Backend availability:
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NPU hardware: Yes
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - System RAM: 124.4 GB (max model size: 99.5 GB)
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - Largest memory pool: 1.0
lemonade-server  | 2026-07-17 16:56:25.983 [Info] (ModelManager)   - NVIDIA GPU: detection error: No NVIDIA discrete GPU found
lemonade-server  | 2026-07-17 16:56:26.865 [Info] (ModelManager) Cache built: 134 total, 12 downloaded
lemonade-server  | 2026-07-17 16:56:27.377 [Info] (ModelManager) Update available for mradermacher/zen-musician-GGUF on Hugging Face: cached=68f57789b3452c5e6d, latest=b6f1ebe1d279fce8f6 (1 variant(s))
lemonade-server  | 2026-07-17 16:56:28.916 [Info] (ModelManager) Updates available for 1 model(s)
lemonade-server  | 2026-07-17 16:56:46.433 [Warn] (BackendManager) GitHub returned HTTP 403 for lemonade-sdk/llama.cpp
lemonade-server  | 2026-07-17 16:56:46.654 [Info] (BackendManager) Resolved 'latest' for lemonade-sdk/llama.cpp -> b10064
^C
areyouloco@minisforum-x1-pro:~/code/lemonade-server$ docker compose exec -it lemonade /bin/bash
lemonade@ffa80a312af5:~$ lemonade backends install flm:npu
Installing backend: flm:npu
Error: Cannot install flm:npu on this system: Requires AMD XDNA 2 AMD NPU

Any ideas what could go wrong here?

I would guess you're missing libreadline8 in the container (we just fixed that on main). If that's not it, open a new ticket please rather than comment on a PR.

github-actions Bot added engine::flm FastFlowLM backend (NPU); multi-modal LLM/ASR/embeddings/reranking enhancement New feature or request labels Jul 4, 2026

superm1 changed the title ~~enable portable flm for Linux~~ Enable portable FLM for Linux Jul 6, 2026

superm1 force-pushed the superm1/portable-flm-linux branch from a7298b4 to 84aecd2 Compare July 6, 2026 03:13

superm1 changed the title ~~Enable portable FLM for Linux~~ Update FLM to 0.9.44 and enable portable FLM for Linux Jul 6, 2026

superm1 force-pushed the superm1/portable-flm-linux branch from 7d5a8b9 to 72b2c96 Compare July 6, 2026 05:10

superm1 requested a review from fl0rianr July 6, 2026 05:12

fl0rianr requested changes Jul 6, 2026

View reviewed changes

fl0rianr reviewed Jul 6, 2026

View reviewed changes

superm1 requested a review from fl0rianr July 6, 2026 15:30

fl0rianr reviewed Jul 6, 2026

View reviewed changes

fl0rianr approved these changes Jul 6, 2026

View reviewed changes

superm1 and others added 8 commits July 6, 2026 11:32

Bump FLM version to 0.9.44

2525aa5

Add support for getting a portable flm asset

483ddc2

Update Linux NPU documentation

9565382

debian/control: Drop libxrt and ffmpeg recommends

cfbc507

FastFlowLM portable has a static build of ffmpeg and packages it's own libxrt.

superm1 force-pushed the superm1/portable-flm-linux branch from 8de1385 to a5cb8d1 Compare July 6, 2026 16:32

jeremyfowers requested a review from ramkrishna2910 July 6, 2026 18:51

superm1 added 2 commits July 6, 2026 19:47

Fallback to system FLM if portable fails to install even if prefer_sy…

2a6868c

…stem turned off

Use portable FLM for CI on Linux

2e5e81f

superm1 force-pushed the superm1/portable-flm-linux branch from 0a4a618 to 2e5e81f Compare July 7, 2026 00:47

ramkrishna2910 approved these changes Jul 7, 2026

View reviewed changes

ramkrishna2910 added this pull request to the merge queue Jul 7, 2026

Merged via the queue into main with commit 40b4193 Jul 7, 2026
93 checks passed

ramkrishna2910 deleted the superm1/portable-flm-linux branch July 7, 2026 18:54

AreYouLoco mentioned this pull request Jul 17, 2026

NPU detection regression for docker container with 11.0.0 and unprivileged user switch (/dev/accel/accel0 permission problem inside the container) #2742

Open

Conversation

superm1 commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tawei-amd commented Jul 4, 2026

Uh oh!

superm1 commented Jul 4, 2026

Uh oh!

fl0rianr left a comment

Choose a reason for hiding this comment

Uh oh!

superm1 commented Jul 6, 2026

Uh oh!

fl0rianr left a comment

Choose a reason for hiding this comment

Uh oh!

fl0rianr left a comment

Choose a reason for hiding this comment

Uh oh!

superm1 commented Jul 6, 2026

Uh oh!

fl0rianr left a comment

Choose a reason for hiding this comment

Uh oh!

jeremyfowers commented Jul 6, 2026

Uh oh!

superm1 commented Jul 6, 2026

Uh oh!

ramkrishna2910 commented Jul 7, 2026

Uh oh!

Uh oh!

AreYouLoco commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

superm1 commented Jul 17, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

superm1 commented Jul 4, 2026 •

edited

Loading

AreYouLoco commented Jul 17, 2026 •

edited

Loading