Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →The error E: Unable to locate package curl during docker build usually means the Debian or Ubuntu image has no usable APT package index yet. Add apt-get update and apt-get install to the same Dockerfile RUN instruction, then remove the downloaded lists after installation:
Antihost offers VPS plans with one-click Docker, NVMe storage and a 14-day free trial.
FROM debian:bookworm-slim
RUN apt-get update
&& apt-get install -y --no-install-recommends
ca-certificates
curl
&& rm -rf /var/lib/apt/lists/*
If that still fails, inspect the output from the update command. A DNS, mirror, or other network error can leave APT with missing or unusable metadata, so the later install reports the symptom rather than the original cause.
As an Amazon Associate I earn from qualifying purchases.
What the error actually means
APT does not search the internet every time you ask it to install a package. It searches package lists stored inside the image. Those lists describe which packages are available for the image’s Debian or Ubuntu release and where they can be downloaded.
A minimal base image commonly starts with an empty or stale set of lists. Running an installation command immediately asks APT to find curl in that local metadata. When the metadata does not contain a usable entry, APT prints:
#1 Best Overall
E: Unable to locate package curl
This message does not establish that curl has been removed from Debian or Ubuntu. It says that the APT instance in the current image cannot locate a package entry. Refreshing the lists before installing is therefore the first repair, rather than changing the package name or downloading a separate curl binary.
The reliable Dockerfile fix
Use one shell layer for update and install
Keep the refresh and installation in one RUN instruction and connect each command with &&:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
FROM debian:bookworm-slim
RUN apt-get update
&& apt-get install -y --no-install-recommends
ca-certificates
curl
&& rm -rf /var/lib/apt/lists/*
apt-get update downloads the package indexes for the release in the base image. Once those indexes are present, apt-get install can resolve curl and its required dependencies. The -y option answers the install confirmation automatically, which is necessary for a non-interactive image build.
Why the cleanup command is included
The update step leaves downloaded index files under /var/lib/apt/lists/. Removing them in the same layer with rm -rf /var/lib/apt/lists/* prevents those temporary indexes from remaining in the final image. The package itself and the files required to run it stay installed; only the local index data is removed. If another image-building step later needs APT, that step must run apt-get update again.
What --no-install-recommends changes
APT can install packages that are marked as suggested or recommended in addition to the package’s required dependencies. The --no-install-recommends option skips suggested packages, keeping this installation focused on the requested tools and their required dependencies. Omit the option only when your application specifically needs those additional recommended packages.
Why separate update and install layers are fragile
Docker evaluates a Dockerfile as a sequence of layers and can reuse a previously built layer from its cache. Consider this pattern:
Recommended Free Tools
RUN apt-get update
RUN apt-get install -y curl
If the first instruction is reused from an earlier build, the second instruction may run with old package metadata. The Dockerfile appears to perform an update, but the cached update layer may no longer reflect the repositories available when the image is rebuilt. Combining the commands makes the install depend on the update performed in that same layer instead of on a separately cached result.
Use the same combined form even when a separate update seems to work on a developer machine. It avoids a class of intermittent builds in which an old cached index is paired with a newer base image or changed repository state.
Step-by-step repair
- Confirm the base image family. Check the
FROMline. The APT procedure applies to Debian- and Ubuntu-based images. Do not substitute it for another distribution’s package manager without confirming that distribution’s instructions. - Place the refresh immediately before installation. Add
RUN apt-get update && apt-get install ...rather than relying on an earlier layer or on package lists from the host machine. - Use the exact package name. For the Debian/Ubuntu example in this guide, the package is
curl. Package names can differ between releases, so verify the name against the release used by the base image if the refreshed install still cannot resolve it. - Make the build non-interactive. Include
-yso the build does not stop waiting for confirmation. - Limit optional packages when appropriate. Add
--no-install-recommendswhen you need curl and required dependencies but not APT’s suggested packages. - Delete the lists after a successful install. Keep
rm -rf /var/lib/apt/lists/*in the sameRUNinstruction, after the install has completed. - Rebuild and read the complete log. The important diagnostic output is produced by
apt-get update. Do not judge the update solely by the final install error.
If the combined command still fails
Read the update output first
A later “Unable to locate package” message can be a consequence of an earlier update failure. Look for errors while APT contacts its mirrors. For example, Temporary failure resolving indicates that the build could not resolve a mirror hostname. In that situation, the package lists may remain absent or old, so repeating only the install command cannot fix the problem.
Correct the network, DNS, proxy, or mirror reachability issue used by the build environment, then rerun the combined update-and-install layer. The exact remedy depends on the environment; the key check is that the update completes successfully before APT attempts to resolve curl.
Free tools Windows power users keep installed
One-click scans. No signup required.
Do not hide update failures behind a cached layer
When troubleshooting, make sure the update instruction is actually executed rather than silently reused from Docker’s cache. A build that continues to use an old layer can reproduce the same metadata problem even after the Dockerfile has been edited. The combined RUN form reduces this risk, but the build log should still show a successful refresh for the current build.
Check the release represented by the base image
Repository contents and package names are tied to the distribution release. If the image uses a release for which the expected package name is different or unavailable, refreshing the lists will not create that package. Confirm that curl exists for the release named by the image before changing other parts of the Dockerfile. The available evidence for this error does not establish one universal package name across every distribution or release.
Rank #4
Consider architecture only when the evidence points there
On Apple Silicon, one Docker for Mac discussion reported that adding a platform declaration to the first line resolved an APT failure:
FROM --platform=linux/amd64 debian:bookworm-slim
This is a single reported case, not a general requirement for Apple Silicon or for curl. Pinning linux/amd64 can also force an architecture different from the host, so use it only when your image’s target architecture and deployment plan call for it, or when architecture-specific behavior is the demonstrated cause. First inspect the update log; a normal mirror or DNS failure should be fixed as a network problem rather than masked with a platform change.
Patterns that cause the error or make it harder to diagnose
| Dockerfile pattern | What can happen | Better approach |
|---|---|---|
RUN apt-get install -y curl on a fresh minimal image |
APT has no current local package index and cannot locate the package. | Run apt-get update in the same instruction before installing. |
RUN apt-get update followed by a separate install layer |
Docker may reuse an old update layer, pairing stale metadata with the later install. | Join update and install with &&. |
| Update fails, but only the final install line is examined | The install error hides the mirror, DNS, or network failure that prevented index retrieval. | Inspect and resolve the update-stage error first. |
| Index cleanup runs before the install | The metadata needed by the install is removed too early. | Install first, then remove /var/lib/apt/lists/* in the same layer. |
| Adding a platform flag without an architecture diagnosis | The build may switch architectures without addressing the real APT problem. | Use a platform declaration only for a confirmed architecture-specific case. |
Understanding the image-size trade-off
The update downloads repository metadata that is useful during the build but usually unnecessary at runtime. Leaving it in the image increases the amount of data carried into later layers. Deleting the files after installation keeps the resulting image leaner while preserving curl and its required runtime files.
There is one practical consequence: a later Dockerfile instruction that needs to install another APT package cannot assume the lists still exist. It must refresh them again in the same instruction as that later installation. If several packages are needed for one build stage, install them together so one update serves that installation and one cleanup removes the temporary indexes afterward.
Best Value
How to verify the repair
Verify during the image build
A successful update should show APT retrieving or accepting package indexes without mirror, DNS, or repository errors. The subsequent install should resolve curl and finish without the “Unable to locate package” message. If the update reports a failure, treat the build as unresolved even if another cached step appears successful.
Verify the resulting image
After the build completes, run the image with the command your application expects and check that curl is available in that container. This confirms that the package was installed in the image being built, rather than merely being available on the host. If the image has multiple build stages, check the final stage: installing curl in an earlier stage does not automatically place it in a later, separate stage.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →When this advice does not apply directly
The commands in this article are for APT-based Debian and Ubuntu images. A base image that uses a different distribution and package manager needs that distribution’s own update and install workflow. The APT diagnosis should not be copied verbatim to such an image.
Likewise, an image that deliberately uses an internal mirror, a restricted network, or a proxy may require that environment to make the mirror reachable before APT can refresh its lists. The Dockerfile’s command can be correct while the build environment still prevents the update from completing.
A compact diagnostic checklist
- Is the
FROMimage Debian- or Ubuntu-based? - Does the same
RUNinstruction executeapt-get updatebeforeapt-get install? - Are the commands connected with
&&, so a failed update stops the install? - Does the update log contain a DNS, mirror, proxy, or other network error?
- Could Docker be reusing a stale update layer?
- Does the requested package exist under the base image’s release and architecture?
- Is
--no-install-recommendsappropriate for the image’s purpose? - Does cleanup occur only after installation, using
/var/lib/apt/lists/*? - If using Apple Silicon, is there concrete evidence that the selected architecture is involved?
For the usual Debian or Ubuntu case, the decisive change is simple: refresh APT’s local index and install curl in one Docker layer. When that still produces the same message, the update log—not the package-install line—is where the next cause will be visible.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems




