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 #10267] Downloader incorrectly assumes only range is downloaded (even when HTTP 200 is returned) #32501

New Issue
Open
opened 2026-04-22 13:49:38 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-22 13:49:38 -05:00
Owner
Copy Link

Originally created by @gdiepen on GitHub (Apr 14, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/10267

What is the issue?

When executing the following:

C:\Users\guido>ollama run tinyllama --verbose
pulling manifest
pulling 2af3b81862c6... 100% ▕████████████████████████████████████████████████████████▏ 637 MB
pulling af0ddbdaaa26... 100% ▕████████████████████████████████████████████████████████▏   70 B
pulling c8472cd9daed... 100% ▕████████████████████████████████████████████████████████▏   31 B
pulling fa956ab37b8c... 100% ▕████████████████████████████████████████████████████████▏   98 B
pulling 6331358be52a... 100% ▕████████████████████████████████████████████████████████▏  483 B
verifying sha256 digest
Error: digest mismatch, file must be downloaded again: want sha256:2af3b81862c6be03c769683af18efdadb2c33f60ff32ab6f83e42c043d6c7816, got sha256:198c7dc595d2b1235c2ac7d54ed0f10422dbe294b5750739e133cc7b55ef6947

I am seeing the mismatch of the calculated sha and the epxected sha.

If I tunnel my traffic through a proxy, I see that the download.go is using the Range header to split the total download into separate download blocks:

Image

However, the server does NOT respond with a HTTP 206 Partial content, but with a HTTP 200 OK status. When this happens, it means the server did NOT respect the requested range, but sent the complete file again.

Now it looks like when the cloudfare server sends the HTTP 200 OK status, the ollama downloader is actually creating the result by copying the first 100.000.000 bytes of the original model file.

I have tested this and it seems my hypothesis is correct:

Image

(The script just copies the first 100.000.000 bytes 6 times and then appends the first 37699456 bytes into a new file and then calculates the sha256sum of that new file)

This sha256 is exactly the same as the sha256 reported by the ollama run statement

In case the server responds with a HTTP 200 instead of the expected 206 it should not assume the bytes returned are the requested range, but instead should fall back on logic to only download it once.

Relevant log output

OS

Windows

GPU

N/A

CPU

N/A

Ollama version

0.6.5

Originally created by @gdiepen on GitHub (Apr 14, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/10267 ### What is the issue? When executing the following: ``` C:\Users\guido>ollama run tinyllama --verbose pulling manifest pulling 2af3b81862c6... 100% ▕████████████████████████████████████████████████████████▏ 637 MB pulling af0ddbdaaa26... 100% ▕████████████████████████████████████████████████████████▏ 70 B pulling c8472cd9daed... 100% ▕████████████████████████████████████████████████████████▏ 31 B pulling fa956ab37b8c... 100% ▕████████████████████████████████████████████████████████▏ 98 B pulling 6331358be52a... 100% ▕████████████████████████████████████████████████████████▏ 483 B verifying sha256 digest Error: digest mismatch, file must be downloaded again: want sha256:2af3b81862c6be03c769683af18efdadb2c33f60ff32ab6f83e42c043d6c7816, got sha256:198c7dc595d2b1235c2ac7d54ed0f10422dbe294b5750739e133cc7b55ef6947 ``` I am seeing the mismatch of the calculated sha and the epxected sha. If I tunnel my traffic through a proxy, I see that the `download.go` is using the `Range` header to split the total download into separate download blocks: ![Image](https://github.com/user-attachments/assets/9c1be76e-18fe-494a-bc9c-01f862f6bcff) However, the server does NOT respond with a HTTP 206 Partial content, but with a HTTP 200 OK status. When this happens, it means the server did NOT respect the requested range, but sent the complete file again. Now it looks like when the cloudfare server sends the HTTP 200 OK status, the ollama downloader is actually creating the result by copying the first 100.000.000 bytes of the original model file. I have tested this and it seems my hypothesis is correct: ![Image](https://github.com/user-attachments/assets/f0cf5f96-78c4-4846-a75a-f0d0f9bc0797) (The script just copies the first 100.000.000 bytes 6 times and then appends the first 37699456 bytes into a new file and then calculates the sha256sum of that new file) This sha256 is exactly the same as the sha256 reported by the ollama run statement In case the server responds with a HTTP 200 instead of the expected 206 it should not assume the bytes returned are the requested range, but instead should fall back on logic to only download it once. ### Relevant log output ```shell ``` ### OS Windows ### GPU N/A ### CPU N/A ### Ollama version 0.6.5
GiteaMirror added the bug label 2026-04-22 13:49:39 -05:00
GiteaMirror commented 2026-04-22 13:49:41 -05:00
Author
Owner
Copy Link

@bmizerany commented on GitHub (Apr 14, 2025):

I'm sorry you experienced this. This is a known issue. We've been actively working on a fix for it. Please feel free to follow along in #10069

<!-- gh-comment-id:2803062839 --> @bmizerany commented on GitHub (Apr 14, 2025): I'm sorry you experienced this. This is a known issue. We've been actively working on a fix for it. Please feel free to follow along in #10069
GiteaMirror commented 2026-04-22 13:49:42 -05:00
Author
Owner
Copy Link

@gdiepen commented on GitHub (Apr 25, 2025):

I saw that #10069 was merged and assume it was in the 0.6.6 release. I just checked with the 0.6.6 release on my computer, but the problem still persists

<!-- gh-comment-id:2829838903 --> @gdiepen commented on GitHub (Apr 25, 2025): I saw that #10069 was merged and assume it was in the 0.6.6 release. I just checked with the 0.6.6 release on my computer, but the problem still persists
GiteaMirror commented 2026-04-22 13:49:44 -05:00
Author
Owner
Copy Link

@RobMorga commented on GitHub (May 13, 2025):

Even in 0.6.8 it is broken. 🤷‍♂️

https://github.com/ollama/ollama/issues/8105#issuecomment-2875601421

It is currently impossible to download a model!

<!-- gh-comment-id:2876229363 --> @RobMorga commented on GitHub (May 13, 2025): Even in 0.6.8 it is broken. 🤷‍♂️ https://github.com/ollama/ollama/issues/8105#issuecomment-2875601421 It is currently impossible to download a model!
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 bug
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#32501
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?