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

[GH-ISSUE #15447] Error: 400 (empty body) when pulling hf.co GGUF models after successful download #71932

New Issue
Open
opened 2026-05-05 03:00:33 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-05-05 03:00:33 -05:00
Owner
Copy Link

Originally created by @comdevx on GitHub (Apr 9, 2026).
Original GitHub issue: https://github.com/ollama/ollama/issues/15447

What is the issue?

When pulling a GGUF model from HuggingFace (hf.co/...), the download completes successfully but Ollama returns Error: 400: (empty body) and fails to register the model. No manifest is created and the model does not appear in ollama list.

Reproduction steps:

ollama run hf.co/arsovskidev/Gemma-4-E4B-Claude-4.6-Opus-Reasoning-Distilled:Q8_0

Output:

pulling manifest
pulling fe4c25ea2f4e: 100% ▕████████████████████████████████████▏ 8.0 GB
Error: 400:

Also reproduced with :Q4_K_M variant (5.3 GB).

GGUF file details

Inspecting the downloaded blob confirms it is a valid GGUF v3 file:

  • general.architecture = gemma4
  • general.quantized_by = Unsloth
  • 720 tensors, 42 KV pairs

Workaround

Manually creating the model from the already-downloaded blob works:

cat > Modelfile << 'MODELFILE'
FROM /path/to/.ollama/models/blobs/sha256-<hash>

TEMPLATE """<bos>{{ if .System }}<start_of_turn>user
{{ .System }}<end_of_turn>
{{ end }}{{ range .Messages }}{{ if eq .Role "user" }}<start_of_turn>user
{{ .Content }}<end_of_turn>
<start_of_turn>model
{{ else if eq .Role "assistant" }}{{ .Content }}<end_of_turn>
{{ end }}{{ end }}<start_of_turn>model
"""

PARAMETER stop "<end_of_turn>"
PARAMETER stop "<eos>"
MODELFILE

ollama create my-model -f Modelfile

Expected behavior

Model should be registered and runnable after a successful download, same as ollama create from a local blob.

Relevant log output

Server log only shows 200 POST /api/pull — no error details logged server-side for the 400 response.

OS

macOS Darwin 25.3.0 (Apple Silicon)

GPU

Apple Silicon (Metal)

CPU

Apple Silicon

Ollama version

ollama version is 0.20.4
Originally created by @comdevx on GitHub (Apr 9, 2026). Original GitHub issue: https://github.com/ollama/ollama/issues/15447 ### What is the issue? When pulling a GGUF model from HuggingFace (`hf.co/...`), the download completes successfully but Ollama returns `Error: 400:` (empty body) and fails to register the model. No manifest is created and the model does not appear in `ollama list`. **Reproduction steps:** ``` ollama run hf.co/arsovskidev/Gemma-4-E4B-Claude-4.6-Opus-Reasoning-Distilled:Q8_0 ``` Output: ``` pulling manifest pulling fe4c25ea2f4e: 100% ▕████████████████████████████████████▏ 8.0 GB Error: 400: ``` Also reproduced with `:Q4_K_M` variant (5.3 GB). ### GGUF file details Inspecting the downloaded blob confirms it is a valid GGUF v3 file: - `general.architecture = gemma4` - `general.quantized_by = Unsloth` - 720 tensors, 42 KV pairs ### Workaround Manually creating the model from the already-downloaded blob works: ```bash cat > Modelfile << 'MODELFILE' FROM /path/to/.ollama/models/blobs/sha256-<hash> TEMPLATE """<bos>{{ if .System }}<start_of_turn>user {{ .System }}<end_of_turn> {{ end }}{{ range .Messages }}{{ if eq .Role "user" }}<start_of_turn>user {{ .Content }}<end_of_turn> <start_of_turn>model {{ else if eq .Role "assistant" }}{{ .Content }}<end_of_turn> {{ end }}{{ end }}<start_of_turn>model """ PARAMETER stop "<end_of_turn>" PARAMETER stop "<eos>" MODELFILE ollama create my-model -f Modelfile ``` ### Expected behavior Model should be registered and runnable after a successful download, same as `ollama create` from a local blob. ### Relevant log output Server log only shows `200 POST /api/pull` — no error details logged server-side for the 400 response. ### OS macOS Darwin 25.3.0 (Apple Silicon) ### GPU Apple Silicon (Metal) ### CPU Apple Silicon ### Ollama version ``` ollama version is 0.20.4 ```
GiteaMirror added the networking label 2026-05-05 03:00:33 -05:00
GiteaMirror commented 2026-05-05 03:00:36 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Apr 9, 2026):

It fails because fetching the config blob specified in the manifest pulled from HF returns an error:

  "error": "The specified tag is not available in the repository. Please use another tag or \"latest\""
<!-- gh-comment-id:4213134585 --> @rick-github commented on GitHub (Apr 9, 2026): It fails because fetching the config blob specified in the manifest pulled from HF returns an error: ``` "error": "The specified tag is not available in the repository. Please use another tag or \"latest\"" ```
GiteaMirror commented 2026-05-05 03:00:37 -05:00
Author
Owner
Copy Link

@mcd1992 commented on GitHub (Apr 15, 2026):

Getting the same issue and your workaround does work. Thank you.

It fails because fetching the config blob specified in the manifest pulled from HF returns an error:

  "error": "The specified tag is not available in the repository. Please use another tag or \"latest\""

The error happens after it spends time actually downloading the model parts. And it happens even if you explicitly give a tag that exists like latest or BF16.

<!-- gh-comment-id:4256264212 --> @mcd1992 commented on GitHub (Apr 15, 2026): Getting the same issue and your workaround does work. Thank you. > It fails because fetching the config blob specified in the manifest pulled from HF returns an error: > > ``` > "error": "The specified tag is not available in the repository. Please use another tag or \"latest\"" > ``` The error happens after it spends time actually downloading the model parts. And it happens even if you explicitly give a tag that exists like `latest` or `BF16`.
GiteaMirror commented 2026-05-05 03:00:38 -05:00
Author
Owner
Copy Link

@PureBlissAK commented on GitHub (Apr 18, 2026):

🤖 Automated Triage & Analysis Report

Issue: #15447
Analyzed: 2026-04-18T18:21:30.083083

Analysis

  • Type: unknown
  • Severity: medium
  • Components: unknown

Implementation Plan

  • Effort: medium
  • Steps:

This issue has been triaged and marked for implementation.

<!-- gh-comment-id:4274308404 --> @PureBlissAK commented on GitHub (Apr 18, 2026): <!-- ollama-issue-orchestrator:v1 issue:15447 --> ## 🤖 Automated Triage & Analysis Report **Issue**: #15447 **Analyzed**: 2026-04-18T18:21:30.083083 ### Analysis - **Type**: unknown - **Severity**: medium - **Components**: unknown ### Implementation Plan - **Effort**: medium - **Steps**: *This issue has been triaged and marked for implementation.*
GiteaMirror commented 2026-05-05 03:00:39 -05:00
Author
Owner
Copy Link

@Taschentiger commented on GitHub (Apr 30, 2026):

I can reproduce this on macOS Apple Silicon with Ollama 0.22.0.

For me, normal registry pulls work fine, for example:

ollama pull llama3.2:3b

This completes successfully, writes the manifest, and the model appears in ollama list.

However, pulling GGUF models from hf.co/... fails after the blob download completes.

Example:

ollama pull hf.co/llmfan46/gemma-4-26B-A4B-it-ultra-uncensored-heretic-GGUF:Q8_0

Output:

pulling manifest
pulling c3d2d0ae6814: 100% ▕████████████████████████████████████████████████████████████████████████▏ 26 GB
Error: 400:

I also previously saw a separate unexpected EOF error while pulling another hf.co/... model, so there may be multiple Hugging Face pull-path issues.

Relevant observations:

  • ollama pull llama3.2:3b works normally
  • hf.co/... GGUF pull downloads the blob fully, then fails with Error: 400:
  • no manifest is written
  • model does not appear in ollama list
  • server debug log shows only the pull request without a meaningful internal error

Environment:

  • macOS Apple Silicon
  • GPU: Metal
  • Ollama version: 0.22.0

Debug server log around the failure:

time=2026-04-30T11:43:01.845+02:00 level=INFO source=routes.go:1820 msg="Listening on 127.0.0.1:11434 (version 0.22.0)"
[GIN] 2026/04/30 - 11:43:48 | 200 | 696.851667ms | 127.0.0.1 | POST "/api/pull"

So this still appears reproducible on 0.22.0 and is not limited to 0.20.4.

<!-- gh-comment-id:4351468529 --> @Taschentiger commented on GitHub (Apr 30, 2026): I can reproduce this on macOS Apple Silicon with Ollama 0.22.0. For me, normal registry pulls work fine, for example: ```bash ollama pull llama3.2:3b ``` This completes successfully, writes the manifest, and the model appears in `ollama list`. However, pulling GGUF models from `hf.co/...` fails after the blob download completes. Example: ```bash ollama pull hf.co/llmfan46/gemma-4-26B-A4B-it-ultra-uncensored-heretic-GGUF:Q8_0 ``` Output: ```bash pulling manifest pulling c3d2d0ae6814: 100% ▕████████████████████████████████████████████████████████████████████████▏ 26 GB Error: 400: ``` I also previously saw a separate `unexpected EOF` error while pulling another `hf.co/...` model, so there may be multiple Hugging Face pull-path issues. Relevant observations: * `ollama pull llama3.2:3b` works normally * `hf.co/...` GGUF pull downloads the blob fully, then fails with `Error: 400:` * no manifest is written * model does not appear in `ollama list` * server debug log shows only the pull request without a meaningful internal error Environment: * macOS Apple Silicon * GPU: Metal * Ollama version: 0.22.0 Debug server log around the failure: ```text time=2026-04-30T11:43:01.845+02:00 level=INFO source=routes.go:1820 msg="Listening on 127.0.0.1:11434 (version 0.22.0)" [GIN] 2026/04/30 - 11:43:48 | 200 | 696.851667ms | 127.0.0.1 | POST "/api/pull" ``` So this still appears reproducible on 0.22.0 and is not limited to 0.20.4.
GiteaMirror commented 2026-05-05 03:00:40 -05:00
Author
Owner
Copy Link

@Michal-Zablocki commented on GitHub (Apr 30, 2026):

Hi, I've experienced the same issue today as well - but on Windows 11.

I pulled gemma4:e4b successfully, however, when I tried

ollama run hf.co/llmfan46/gemma-4-E4B-it-ultra-uncensored-heretic-GGUF:Q4_K_M

I got

pulling manifest
pulling f9dbbe3bdf39: 100% ▕██████████████████████████████████████████████████████████▏ 5.3 GB
Error: 400:

OS: Windows 11
GPU: NVIDIA GeForce RTX 4060 Laptop
CPU: AMD Ryzen 7 8845HS
Ollama version: 0.22.0

<!-- gh-comment-id:4356121496 --> @Michal-Zablocki commented on GitHub (Apr 30, 2026): Hi, I've experienced the same issue today as well - but on Windows 11. I pulled gemma4:e4b successfully, however, when I tried `ollama run hf.co/llmfan46/gemma-4-E4B-it-ultra-uncensored-heretic-GGUF:Q4_K_M` I got ``` pulling manifest pulling f9dbbe3bdf39: 100% ▕██████████████████████████████████████████████████████████▏ 5.3 GB Error: 400: ``` OS: Windows 11 GPU: NVIDIA GeForce RTX 4060 Laptop CPU: AMD Ryzen 7 8845HS Ollama version: 0.22.0
GiteaMirror commented 2026-05-05 03:00:41 -05:00
Author
Owner
Copy Link

@kaylavelle commented on GitHub (May 1, 2026):

Same issue

ollama run hf.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-GGUF:Q4_K_S
pulling manifest
pulling cd3e8a001cbb: 100% ▕██████████████████████████████████████████████████████████▏ 15 GB
Error: 400:

Any updates?

<!-- gh-comment-id:4358508793 --> @kaylavelle commented on GitHub (May 1, 2026): Same issue ollama run hf.co/llmfan46/Qwen3.6-27B-uncensored-heretic-v2-GGUF:Q4_K_S pulling manifest pulling cd3e8a001cbb: 100% ▕██████████████████████████████████████████████████████████▏ 15 GB Error: 400: Any updates?
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 networking
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#71932
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?