You ran the depth camera SDK's Ubuntu kernel patch script. Every patch applied successfully — the offset and fuzz notices in the log are normal — the modules compiled, and then the install stage stopped at cp: cannot stat videobuf2-common.ko: No such file or directory. Nothing you built is missing: the file the script asks for is one this run never produces. It is written for engineers bringing a USB 3D depth camera up on Ubuntu, where the vendor's kernel patches are still the documented install path. You will confirm the root cause from your own build log, pick the script branch that matches your running kernel, and verify the patched driver actually loaded on 5.3.0-53-generic.
What the error line actually tells you
The message comes from the install stage, which runs only after every patch has applied and every module has linked. In the failing run the seven patched files went in cleanly, the uvc compile ended with MODPOST 1 modules and linked a single uvcvideo.ko, and the two HID sensor modules built the same way. Then the copy step asked for a staged file and found nothing. The build did not break; the staged file was never on this run's production list.
The <release>-videobuf2-common.ko name is a staging convention. The script builds a module in its patch workspace, drops it under that name, and copies it during install:
cp: cannot stat '<home>/<release>-videobuf2-common.ko': No such file or directory
When the workspace never builds that file, the copy fails the same way every time. That is why rerunning the identical script changes nothing.
Why videobuf2-common.ko is missing from the build
Look at what the workspace actually compiles. The uvc step builds the out-of-tree uvcvideo.ko from drivers/media/usb/uvc; the IIO steps build hid-sensor-accel-3d.ko and hid-sensor-gyro-3d.ko. Three modules, all camera-specific. videobuf2-common.ko is different: it belongs to the kernel's own V4L2 media stack, your running kernel already ships it, and a 5.3 workspace has no reason to rebuild it.
The copy step expects it anyway for historical reasons. The metadata patch edits include/uapi/linux/videodev2.h, the same header the in-tree videobuf2 code is compiled against. On the 4.x GA kernels that script branch was written for, it restages a matching videobuf2 module so the patched uvcvideo.ko and the stock media stack agree. The install list copies that staged file unconditionally. Drive the same branch against an HWE 5.3 tree, where nothing is staged, and the last line fails after a completely clean compile.
Confirm the cause in five minutes
Run the patch script with its output captured, then check four things in about ten minutes on a typical 4-core build machine, where the full module build itself takes roughly 5 to 15 minutes. The snippets use build-log.txt as the captured file name:
uname -r # -> 5.3.0-53-generic
grep -nE "MODPOST|LD \[M\]" build-log.txt # uvc block: "MODPOST 1 modules"
dpkg -l 'linux-headers-*' | grep ^ii # exact headers present, or only 4.15?
ls ~ | grep videobuf2 # empty: nothing was staged
Three results decide it. uname -r gives the series: a 5.3 release on Ubuntu 18.04 is a hardware-enablement (HWE) kernel, not the stock GA 4.15 the generic branch targets. The compile block proves the staging gap: MODPOST 1 modules followed by one uvcvideo.ko line means no videobuf2 object was produced. And the headers line shows the trap: the log carries linux-headers-generic 4.15.0.129.116, a metapackage that tracks the GA series, on a machine running 5.3.0-53-generic.
The fix: match the script branch to uname -r
- Read the series from
uname -r; the first two numbers (5.3 here) pick the branch. Ignore the Ubuntu release alone: 18.04 runs the 4.15 GA and 5.3 HWE stacks side by side, which is exactly how this mismatch happens. - Install the exact headers with
sudo apt install linux-headers-$(uname -r), which resolves tolinux-headers-5.3.0-53-genericon this kernel. The GA metapackage does not target it. - Run the script variant the SDK ships for that series. The scripts folder carries one branch for stock GA kernels and one for HWE stacks; choose by kernel series, not by habit. If your series has no variant, stop and ask the vendor for the documented path instead of forcing the generic script.
- Watch the tag the script fetches. An HWE 5.3 run prints a tag in the
Ubuntu-hwe-5.3series form — this log fetchedUbuntu-hwe-5.3.0-53.47_18.04.1— while a GA run fetches anUbuntu-4.15.0-series tag. If the family is wrong, abort and recheck step 1. - Verify the result:
modinfo uvcvideo | grep vermagicmust start with youruname -rstring, then replug the camera and readdmesgfor the uvc probe and its metadata nodes.
Worked example: 5.3.0-53-generic on Ubuntu 18.04
| Check | Value in the failing log | What it decides |
|---|---|---|
Running kernel, uname -r
|
5.3.0-53-generic | Series 5.3 → HWE branch |
| Headers metapackage | linux-headers-generic 4.15.0.129.116 | Tracks GA 4.15, wrong target |
| Series test | 5.3.0-53 vs 4.15.0-129 | Different series → script/kernel mismatch |
| Source tag fetched | Ubuntu-hwe-5.3.0-53.47_18.04.1 | Right tree and ABI, wrong installer branch |
| uvc compile output | MODPOST 1 modules, one uvcvideo.ko | No videobuf2-common staged, so the cp line fails |
The decision falls straight out of the table: 5.3.0-53-generic belongs to the HWE 5.3 branch, so run that variant with linux-headers-5.3.0-53-generic installed. Expect the same seven files patched — drivers/media/usb/uvc/uvc_driver.c, drivers/media/usb/uvc/uvcvideo.h, drivers/media/usb/uvc/uvc_ctrl.c, drivers/media/v4l2-core/v4l2-ioctl.c, include/uapi/linux/videodev2.h, drivers/iio/accel/hid-sensor-accel-3d.c and drivers/iio/gyro/hid-sensor-gyro-3d.c — then an install that copies uvcvideo.ko and the two HID modules into /lib/modules/$(uname -r) and refreshes the module dependencies. A GA kernel such as 4.15.0-129-generic, by contrast, belongs to the stock GA script, staged videobuf2 copy and all.
When the usual answer is wrong
Two tempting moves fail. Rerunning the identical script hits the identical line, because the mismatch is deterministic: the same branch drives the same tree and stages the same nothing. Hand-copying a videobuf2-common.ko from another machine is worse than doing nothing, for the reason below.
There is a legitimate move in the other direction: boot the GA kernel instead. If nothing in your application needs 5.3, select 4.15.0-129-generic at the GRUB menu, confirm with uname -r, and run the stock GA script on it — the combination that branch was written for, staged videobuf2 copy included. Before patching any kernel at all, also check whether you still need to: mainline kernels since 4.16 carry UVC metadata support in the stock driver, and newer SDK releases keep absorbing more of this into their installers. The kernel patch failure overview walks that decision.
Prevention checklist
Before you run any variant:
- Record
uname -rin the ticket; every later check compares against it. - Install
linux-headers-$(uname -r), the exact release, not the metapackage. - Expect the script to reset its workspace: uncommitted edits to patched files, such as a hand-tuned
uvcvideo.h, are wiped at the "reset all local kernel changes" prompt.
During the run:
- Check the fetched tag's family against your kernel series before letting the build continue.
- Read the MODPOST and
LD [M]lines: three camera-specific modules, nothing else.
After it finishes:
-
modinfo uvcvideo: vermagic starts with youruname -r. - Replug the camera and read
dmesg; if the stock driver still owns the device, see the built-in-driver article below. - Keep the log with the machine's records; it is the install evidence.
Related patch failures, and how this one differs
The kernel-patch family fails at different stages, and the stage names the fix. A run that stops earlier, at "can't find file to patch", is a source-tree mismatch — see check the kernel source tree. A build-stage failure on the wrong kernel, common with DKMS-managed rebuilds, is covered in the DKMS clean-and-rebuild fix. When a patch applies but nothing changes at runtime, that is the duplicate-headers silent stop. If the driver loads and the camera still never appears, the stock built-in module usually won the device — check for a built-in driver explains that tiebreak — and a bad install can be undone with the driver rollback procedure. This article's error differs from all of those: patches applied, modules built, and only the install-stage copy of a kernel-owned module failed. More Linux bring-up notes sit on the 3D topic page.
If you are standardizing new 3D stations, favor sensors whose installers match current kernels out of the box: the 3D sensors category covers laser profilers, stereo and structured-light cameras, and the camera finder filters by interface and resolution. The same UVC stack drives many USB area scan cameras, so the matching rule above applies to their Linux setups too. For a second opinion on a stuck install, message us through the contact page — free expert support comes with every order.
Questions
Can I build videobuf2-common.ko myself and copy it?
Only from the same patched workspace tree, and only if every module that consumes it is rebuilt against the same videodev2.h — otherwise the structures no longer agree. The script branches exist precisely because the staging set differs per kernel family. On an HWE 5.3 kernel the supported path is the matching script variant, not a hand-built copy.
Why does a uvcvideo patch touch videobuf2 at all?
The metadata patch edits include/uapi/linux/videodev2.h, and the in-tree videobuf2 code is compiled from that header. On the 4.x GA kernels the script targets, it therefore restages a matching videobuf2-common.ko alongside uvcvideo.ko so the media stack stays consistent. The 5.x HWE trees ship a videobuf2 that already matches, so nothing is staged and the copy step finds nothing.
How do I tell an HWE kernel from the stock GA kernel?
Run uname -r. On Ubuntu 18.04, a stock GA kernel reads 4.15.0-129-generic, while a hardware-enablement kernel reads 5.3.0-53-generic or another higher series. The metapackages differ too: linux-headers-generic tracks the GA series, which is why the failing log shows 4.15.0.129.116 on a machine running 5.3.0-53-generic. Install linux-headers-$(uname -r) for the exact match.
Did the failed copy damage my system?
No. cp failed before writing anything, so the stock modules under /lib/modules are untouched and the machine behaves as before. Remove or keep the patch workspace as you like — a rerun of any variant rebuilds it from its fetched tag and resets local changes. Only an install that partially succeeds, or a hand-copied module, can leave mixed state behind.
Do newer kernels still need this patch?
Often not for the uvc part: mainline kernels since 4.16 carry UVC metadata support in the stock driver, so many depth cameras work unpatched on them. The HID sensor part is separate and depends on whether your camera model has an IMU you need. Check your SDK's release notes for the minimum patched kernel before spending an afternoon on the build.