Kernel patch can't find file to patch: check the source tree

A vendor set-up script for a USB depth camera stops mid-run: patch reports "can't find file to patch", hints at a wrong strip option, and waits at a "File to patch:" prompt. The patch file is almost never the problem — the kernel source tree the script cloned a minute earlier has come back empty or half-downloaded, so patch has no files to modify. You can confirm that with two commands in the cloned folder, fix it with a delete and a re-clone on a network that does not block git's transport, and be back to building modules within the hour. This guide reads the error in the order it arrives: what patch is telling you, how to check the tree in two minutes, why the clone comes up short, the fix, and the fallback of cloning on another PC and copying the folder across.

What does "can't find file to patch" actually mean?

patch worked down the patch file, took each target path from the diff headers, applied the strip level the script passed it, looked for that file under the kernel source folder, found nothing there, stopped at the named input line and fell back to its interactive "File to patch:" prompt.

The prompt is patch asking you to name a file by hand; it is not a step you are meant to complete. When the message comes from a vendor script rather than a patch you invoked yourself, the script's own sequence explains the failure. These wrappers install prerequisites, clone the matching kernel source into a folder beside their scripts directory, apply the vendor patches, then build and install the modules. If the clone step produced an empty folder, the patch step cannot resolve its very first header, and you see exactly this error whatever the hint claims.

The "at input line N" number points into the patch file at its first unresolvable header — read it to learn which file patch wanted first. If you also saw a plain RGB image in your viewer with no depth stream behind it, that is the same missing patch one level up: the stock USB video driver has no depth formats to offer until the patch lands.

Why does patch blame the -p or --strip option?

patch prints that hint automatically every time a named target is missing, so when a wrapper script raised the error the advice is a red herring: the script already calls patch with the correct strip level, and the file is simply absent from disk.

Kernel patches are unified diffs with a/ and b/ prefixes on every path:

--- a/drivers/media/usb/uvc/Makefile
+++ b/drivers/media/usb/uvc/Makefile

The -p level tells patch how many leading path components to strip. Count them: a, drivers, media, usb, uvc, Makefile — six components. Kernel patches are built for -p1, which strips the first:

Vendor wrapper scripts apply these patches at -p1, as kernel patches require, so the option deserves suspicion only when you ran patch by hand. When the script printed the hint, believe the missing file, not the hint.

How do I check the kernel source tree in two minutes?

Change into the cloned tree — the distribution-named folder the script created beside its scripts directory, ubuntu-xenial-master in the stack behind this error — run ls, then git log -1, and anything short of a full source listing plus a commit line is your answer.

Inside that folder, the three checks are:

git log -1
git status
ls drivers/media/usb/uvc

A healthy tree answers git log -1 with a commit hash, a date and a subject naming the kernel release; git status reports a clean checkout; the listing shows Makefile beside the driver sources. A broken tree answers git log -1 with fatal: bad default revision 'HEAD' — the .git folder exists but no commits ever arrived — and the listing prints nothing. Folder present, contents absent: that is the signature of this failure.

Next, confirm the files named in the patch header exist. The "text leading up to this" block in the error lists them: for this UVC patch family, drivers/media/usb/uvc/Makefile, uvc_driver.c and uvcvideo.h, plus drivers/media/v4l2-core/v4l2-ioctl.c and include/uapi/linux/videodev2.h. One absence stops the run. Those paths follow standard kernel layout — USB media drivers live under drivers/media/usb — and if that hierarchy is new to you, an embedded Linux kernel, device tree and driver reference maps how the source, drivers and device trees fit together.

If ls instead shows a full tree, compare releases: the subject line from git log -1 against the output of uname -r. A healthy tree at the wrong kernel release gives the same error for a different reason, and that fix starts in matching the patch to the kernel source tree. Folder names and script steps differ slightly between vendor SDKs; the two-command check is the same everywhere.

Why did the clone come back empty?

The causes in order of likelihood: a download that died or was throttled mid-transfer, a firewall or proxy silently refusing git's transport, a disk that filled during the clone, and — rarest — running the script from a directory where the tree lands somewhere you did not look.

The mechanism is simple: the folder is created before the transfer fills it, so any failure after that leaves a directory that looks like a destination and holds no commits. Rule the disk out first because the check costs nothing: df -h . in the SDK folder — a tree with its git history wants roughly 1-2 GB, and a full disk stops the transfer right after the folder exists.

The network case is the common one. Git's native protocol runs on TCP port 9418, which corporate firewalls and proxies routinely refuse while leaving browser traffic untouched — the web works and the clone does not. Test the transport directly with git ls-remote against the URL the script fetches. A hang or a proxy error, on a machine where browsing is healthy, convicts the network path rather than your hardware.

What is the fix — delete, re-clone, verify, patch?

Delete the empty tree, re-clone on a network that reaches git cleanly, verify the files are present, then let the script continue into patch and build — a sequence that clears this error far more often than any change to the patch itself.

1. Remove the broken folder completely (rm -rf on the cloned tree); a reused partial clone fails again at the same header.
2. Check free space with df -h . and keep about 2 GB available.
3. Re-run the script from the SDK root, as its instructions state, so the clone starts fresh.
4. Watch the download finish before patch output begins, and do not let the machine sleep mid-run.
5. Verify before celebrating: git log -1 prints a commit, and ls drivers/media/usb/uvc shows Makefile with the .c and .h files.
6. Let the script run on into the patch and module build.

Calibrate what a healthy run feels like. A kernel tree with its git history weighs roughly 1-2 GB; take 1,500 MB for the arithmetic and divide by the transfer rate:

Ten times less bandwidth turns a two-and-a-half-minute clone into a two-hour one — long enough for a laptop to suspend, a Wi-Fi client to roam, or a proxy to cut the connection, and any of those leaves the empty folder you started with. A clone still grinding after half an hour is not nearly done: stop it and move the download to a clean network or another PC. Confirm the real size afterwards with du -sh on the folder.

Can I clone on another PC and copy the tree over?

Yes — when the target machine's network refuses git's transport, clone the source on any unrestricted PC, verify it there, copy the whole folder including its .git directory to the same path on the target, and re-run the script.

1. On the connected PC, clone the same source and branch the script fetches.
2. Verify it there: git log -1 and ls drivers/media/usb/uvc.
3. Copy the entire folder, .git included, to the identical path on the target machine.
4. Re-run the patch script; it finds the tree in place and proceeds to patch and build.

The copy is quick — a 1-2 GB folder crosses a USB stick in a couple of minutes, against hours through a hostile proxy — and the script cannot tell a transferred tree from one it fetched itself, provided the path matches.

How do I see exactly where the script gave up?

Switch on command tracing by changing set -e to set -ex on the options line near the top of the script, run it again, and the console echoes each command before it executes — the last cd and patch lines show the folder patch expected the files in.

Read the trace backwards from the failure. The cd immediately above the patch line is the directory patch ran in, and the diff headers are relative to it: if that directory is the empty folder from the check above, the script's own view confirms the diagnosis. If the trace instead shows a cd into a folder you never checked, the script was launched from the wrong working directory — start it from the SDK root as its instructions state.

Save the whole run to a file — pipe the script through tee log.txt or copy the terminal output — because vendor support will ask for it, and the trace removes the guesswork from any follow-up question.

What should I check after the patch applies?

A clean run answers every patch application with "Hunk #N succeeded" lines instead of a prompt, builds and installs the modules, and after the camera is connected ls /dev/video* prints one or more /dev/videoN nodes where the pre-patch run printed "No such file or directory".

That missing-/dev/video line the script printed during preparation was expected: the stock USB video driver exposes no depth formats for these cameras, so there was nothing to find until the patched module loaded.

Two follow-ups cover the cases left over. If the nodes exist and the viewer shows RGB but no depth, the usual next cause is the camera sitting in its passive IR fallback, which why a depth camera publishes no depth stream walks through. If the viewer cannot open the device at all after a successful patch, suspect version skew between camera firmware and driver, and start from fixing detection failures caused by a camera firmware version mismatch.

How do I keep this off the next install?

Verify the tree in the gap between the clone and the patch — one ls and one git log -1 — and this failure cannot reach the patch step again, because a bad clone is caught in seconds while it is still obvious what went wrong.

• Wire the set-up machine to an unrestricted network for the download; walk off the corporate proxy or use a phone hotspot when git ls-remote hangs.
• Run df -h . first and keep about 2 GB free for the tree.
• Work on mains power with sleep disabled until the patch and build finish.
• After every clone and before every patch: git log -1, then ls drivers/media/usb/uvc.
• Keep the cloned tree on disk after a successful install. Distribution kernel updates replace the patched modules and the vendor stack gets re-run for each new kernel, so the kept tree saves the whole download next time.

If you end up maintaining these trees often enough to want to read them properly, a guide to choosing kernel source learning resources lists study material worth the time. The wider set of patch-time failures in depth camera stacks — version skew, header mismatches, build errors — is covered in fixing or avoiding depth camera kernel patch failures.

Next step: if a verified, healthy tree still fails to patch, you have moved on from an empty download to a version mismatch — start from the source-tree matching guide linked above. If this patch ritual taxes every machine you set up, cameras that follow the GigE Vision and USB3 Vision standards install through their standard drivers and vendor SDKs without touching kernel source. Today's depth cameras live in the 3D sensors category, the camera finder filters them by interface and resolution, and the contact page takes your kernel release plus the last ten log lines — usually enough to name the failure on the first reply.