PREV_LEC NEXT_LEC

What You Will Learn

Prerequisites

Basic familiarity with git (clone, checkout, branches) and a Linux host machine with a few gigabytes of free disk space and a decent internet connection — a full kernel git history is large.

Two Ways to Get the Source

Once you’ve picked a target kernel — mainline, stable, LTS, or a vendor BSP, as covered in the earlier lectures of this free linux device drivers course — you have two practical options for pulling it onto your machine: cloning it with git, or downloading a compressed tarball snapshot.

For any serious embedded development — writing drivers, porting to new hardware, tracking security patches — git is the better choice. You get the full commit history, can bisect regressions, diff your local changes against upstream, and switch between versions instantly without re-downloading anything.

Cloning the Stable Tree

The canonical stable/LTS tree lives at kernel.org under linux-stable. A clone pulls the entire project history, so expect it to take a while and use several gigabytes:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ep-linux
$ cd ep-linux

Note: Always prefer the https:// URL over the older git:// protocol shown in some legacy references — plain git:// traffic is unauthenticated and unencrypted, and kernel.org’s modern mirrors are served over HTTPS.

Pinning an Exact Version

A fresh clone leaves you on whatever the default branch happens to be — not what you want for a reproducible product build. Every released kernel version is tagged, so check out the exact tag you need:

# list available tags matching a version family
$ git tag -l "v6.6.*"

# check out one specific, pinned release
$ git checkout v6.6.41

Expected output when the checkout succeeds:

Note: switching to 'v6.6.41'.

You are in 'detached HEAD' state. ...
HEAD is now at 1a2b3c4d5e6f Linux 6.6.41

The “detached HEAD” message is expected and fine — you’re not on a branch, you’re sitting exactly on a tagged commit, which is precisely what you want for a build that has to be reproducible byte-for-byte across your whole team.

Working From a Local Branch Instead

If you plan to carry your own patches on top of this version (very common in embedded work), create a local branch from the tag rather than staying detached:

$ git checkout -b ep-board-6.6.41 v6.6.41

Now any commits you make — board-specific device tree changes, driver fixes — live on a named branch you can rebase or diff against the original tag at any time:

$ git diff v6.6.41 ep-board-6.6.41 -- arch/arm64/boot/dts/

Downloading a Tarball Instead

If you just need one snapshot and don’t care about history, kernel.org also serves plain tarballs, organized by major version series:

$ wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.41.tar.xz
$ tar -xJf linux-6.6.41.tar.xz
$ cd linux-6.6.41

Tip: kernel.org publishes a detached PGP signature (.sign) alongside every tarball. For anything beyond casual experimentation, verify it before building:

$ wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.41.tar.sign
$ xz -d -k linux-6.6.41.tar.xz
$ gpg --verify linux-6.6.41.tar.sign linux-6.6.41.tar

Architecture Diagram: Choosing Your Path

Real-World Use Case: Team Build Reproducibility

Imagine three engineers on a team each build firmware from “the kernel” without pinning an exact tag. Six months later, one of them can’t reproduce a bug the others are seeing, because they cloned at different times and landed on different commits. The fix is procedural, not technical: always record the exact tag or commit hash in your build scripts and README, e.g. KERNEL_VERSION=v6.6.41, and have your build system fail loudly if that tag isn’t what’s actually checked out.

Common Mistakes and Troubleshooting

• Forgetting to check out a tag — building straight off a freshly cloned default branch means your “stable” build silently drifts as upstream changes land.
• Losing track of which commit a tarball came from — always note the exact version and download date in your build documentation.
• Shallow-cloning by default — a shallow clone (--depth 1) saves bandwidth but breaks git bisect and full-history diffing later; only use it if you’re sure you’ll never need history.
• Skipping signature verification — for anything going into a product, verify the PGP signature; a corrupted or tampered tarball is a real supply-chain risk.

Best Practices

• Always pin an exact tag or commit hash for any build that has to be reproducible.
• Prefer git over tarballs for any kernel you’ll be patching or upgrading over time.
• Record the exact version string in your build system’s output, not just your notes.
• Verify tarball signatures for anything beyond quick local experiments.

Summary / Key Takeaways

• Git clone gives you full history and easy version switching; tarballs are a smaller one-shot snapshot.
• Always check out (or download) an exact tagged version — never build off a moving default branch for a real product.
• Use a local branch on top of a tag if you plan to carry your own patches.
• Verify tarball signatures when integrity matters.

Conclusion

Getting the source is the easy, mechanical first step — but doing it in a way that’s reproducible six months later is what separates a hobby build from a maintainable product. With a pinned kernel tree in hand, the next lecture in this free linux kernel development course walks through the actual directory layout so you know where to look for anything you need.

Frequently Asked Questions

PREV_LEC NEXT_LEC