github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 16:11:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #2226] Irritating log output "libnvidia-ml.so.545.29.06 ... wrong ELF class: ELFCLASS32" #1274

New Issue
Closed
opened 2026-04-12 11:04:40 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-12 11:04:40 -05:00
Owner
Copy Link

Originally created by @shoffmeister on GitHub (Jan 27, 2024).
Original GitHub issue: https://github.com/ollama/ollama/issues/2226

Originally assigned to: @dhiltgen on GitHub.

When starting ollama, irritating log output is emitted complaining about wrong ELF class: ELFCLASS32- full content below.

I suspect that eventually the working copy of libnvidia-ml is found, but that does not appear it the logs.

As such, this is a very irritating.

I'd suggest emitting a Successfully loaded CUDA management library /usr/lib64/libnvidia-ml.so.545.29.06 to the logs to balance out the earlier problem entry.

2024/01/27 07:32:28 gpu.go:282: INFO Discovered GPU libraries: [/usr/lib/libnvidia-ml.so.545.29.06 /usr/lib64/libnvidia-ml.so.545.29.06]
2024/01/27 07:32:28 gpu.go:294: INFO Unable to load CUDA management library /usr/lib/libnvidia-ml.so.545.29.06: Unable to load /usr/lib/libnvidia-ml.so.545.29.06 library to query for Nvidia GPUs: /usr/lib/libnvidia-ml.so.545.29.06: wrong ELF class: ELFCLASS32
2024/01/27 07:32:28 gpu.go:99: INFO Nvidia GPU detected
Originally created by @shoffmeister on GitHub (Jan 27, 2024). Original GitHub issue: https://github.com/ollama/ollama/issues/2226 Originally assigned to: @dhiltgen on GitHub. When starting ollama, irritating log output is emitted complaining about `wrong ELF class: ELFCLASS32`- full content below. I suspect that eventually the working copy of `libnvidia-ml` is found, but that does not appear it the logs. As such, this is a very irritating. I'd suggest emitting a `Successfully loaded CUDA management library /usr/lib64/libnvidia-ml.so.545.29.06` to the logs to balance out the earlier problem entry. ``` 2024/01/27 07:32:28 gpu.go:282: INFO Discovered GPU libraries: [/usr/lib/libnvidia-ml.so.545.29.06 /usr/lib64/libnvidia-ml.so.545.29.06] 2024/01/27 07:32:28 gpu.go:294: INFO Unable to load CUDA management library /usr/lib/libnvidia-ml.so.545.29.06: Unable to load /usr/lib/libnvidia-ml.so.545.29.06 library to query for Nvidia GPUs: /usr/lib/libnvidia-ml.so.545.29.06: wrong ELF class: ELFCLASS32 2024/01/27 07:32:28 gpu.go:99: INFO Nvidia GPU detected ```
GiteaMirror commented 2026-04-12 11:04:42 -05:00
Author
Owner
Copy Link

@NanisTe commented on GitHub (Feb 5, 2024):

@shoffmeister and @dhiltgen I guess you have this issue on a Linux machine eventually in AWS. I was confronted the same and figured out by running some online research that it most probably is an issue by Ollama using the 32bit version of nvidia libraries on a 64bit system. I am not sure if this affects actually the usage of GPUs but I had the experience of slow response when having these logs.

My current workaround is that I replace the 32bit library with the 64bit library and I do not get any of these logs messages anymore. I also did not experience any slow responses since then allthough I can not be sure it is because of that, since these were not isolated experiences or tests.

I would suggest to implement in Ollama Linux variant that the 64bit libraries are being used as a priority as soon as they are available.

<!-- gh-comment-id:1926557254 --> @NanisTe commented on GitHub (Feb 5, 2024): @shoffmeister and @dhiltgen I guess you have this issue on a Linux machine eventually in AWS. I was confronted the same and figured out by running some online research that it most probably is an issue by Ollama using the 32bit version of nvidia libraries on a 64bit system. I am not sure if this affects actually the usage of GPUs but I had the experience of slow response when having these logs. My current workaround is that I replace the 32bit library with the 64bit library and I do not get any of these logs messages anymore. I also did not experience any slow responses since then allthough I can not be sure it is because of that, since these were not isolated experiences or tests. I would suggest to implement in Ollama Linux variant that the 64bit libraries are being used as a priority as soon as they are available.
GiteaMirror commented 2026-04-12 11:04:42 -05:00
Author
Owner
Copy Link

@shoffmeister commented on GitHub (Feb 5, 2024):

As mentioned, I don't think it is a functional issue.

This smells as if something is scanning the library path (in absolutely the right order) for matching libraries and probes things. For me, the 32bit libraries are hit first, hit the with diagnostic, then the 64 bit library is hit, and things work.

I haven't taken a look at any of the code to support my gut feeling, though.

Do de-irritate, all it takes would be a "Successfully ... " - and as I don't know whether ollama itself does the scanning, I don't know whether this is actually actionable on the ollama side.

This is happening on my local Fedora Linux, FWIW,

<!-- gh-comment-id:1927050573 --> @shoffmeister commented on GitHub (Feb 5, 2024): As mentioned, I don't think it is a _functional_ issue. This smells as if something is scanning the library path (in absolutely the right order) for matching libraries and probes things. For me, the 32bit libraries are hit first, hit the with diagnostic, then the 64 bit library is hit, and things work. I haven't taken a look at any of the code to support my gut feeling, though. Do de-irritate, all it takes would be a "Successfully ... <this library>" - and as I don't know whether ollama itself does the scanning, I don't know whether this is actually actionable on the ollama side. This is happening on my local Fedora Linux, FWIW,
GiteaMirror commented 2026-04-12 11:04:42 -05:00
Author
Owner
Copy Link

@dhiltgen commented on GitHub (Feb 5, 2024):

We have some other PRs in flight that may transition us off of nvidia-ml and over to the cudart libraries instead. If those work out, the code in question that's generating this warning will be removed.

<!-- gh-comment-id:1928467768 --> @dhiltgen commented on GitHub (Feb 5, 2024): We have some other PRs in flight that may transition us off of nvidia-ml and over to the cudart libraries instead. If those work out, the code in question that's generating this warning will be removed.
GiteaMirror commented 2026-04-12 11:04:43 -05:00
Author
Owner
Copy Link

@dhiltgen commented on GitHub (Mar 27, 2024):

We've merged the change that switches to leveraging the cudart library first, and only if that doesn't work out, falls back to the nvidia management library. The longer-term goal is remove the management library dependency entirely, but we'll wait a few releases to make sure the cudart approach doesn't have any corner cases we missed. I think we can consider this issue resolved in 0.1.30.

<!-- gh-comment-id:2023848750 --> @dhiltgen commented on GitHub (Mar 27, 2024): We've merged the change that switches to leveraging the cudart library first, and only if that doesn't work out, falls back to the nvidia management library. The longer-term goal is remove the management library dependency entirely, but we'll wait a few releases to make sure the cudart approach doesn't have any corner cases we missed. I think we can consider this issue resolved in 0.1.30.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#1274
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?