Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Summary on building a kernel from upstream

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
darkpenguin
Posts: 8
Joined: 2014-06-22 13:05

Summary on building a kernel from upstream

#1 Post by darkpenguin »

(TL;DR) The questions are:
- So, to build a kernel from kernel.org, you just grab the kernel, configure it, make-kpkg, and install it, is that right?
- This way is preferred over make deb-pkg or make install only due to installation/removal simplicity, and there's no other differences or "anything I should know" to choose the preferred way?..
- What do they (repository maintainers) do to the kernel when they add it to the debian repo? Are there any differences/drawbacks with using a "kernel.org" kernel instead of one from the repo? I don't know, some optional Debian-specific set of patches?..
- Is there any reason to use the one in the repo instead? Maybe those patches actually do something useful?..

---

Greetings,

I want to discuss all the information I've found about building a kernel that is not included in the Debian repository. I've found a lot of information on the matter, but certain things are still inclear, as one sources contradict other (and things seem to change with time). So, I want to compile a summary.

On Wheezy, we have very limited options of which kernel to use; either an "old but stable" 3.2 from the Wheezy repository, or the "newest" one from backports (which is 3.16 at the moment of writing), which is neither "stable", nor "longterm" according to kernel.org . So, it would be nice to have a more modern kernel than 3.2, but I would rather use one of the "long-term" kernels than follow the ever-changing one in the backports. If only they kept the most recent long-term one there, along with adopting the newest ones!.. One of my reasons is that I'm using more than one PC, and I would like to have the same kernel on each one of them; I don't like the situation when I'm installing Debian on a new PC and I can't just get the kernel I'm used to. I can either copy it from another PC, or prepare to get acquantainced with a new major kernel release, which is not much of a problem for some people, but I prefer to pay more attention to my updates. So it would be better to get used to one of the "long-term" kernels and use it until I want to update to the next one. (Am I wrong with some of this? Are there reasons I would want to change my mind?..)

So, I started to look for information about building "upstream" kernels.

The first question that comes to my mind in this situation is: there are supposed to be differences between the "upstream" kernels and Debian ones, aren't there?.. That could easily be deduced from the description of the kernel package from the repository: "Linux kernel source for version ... with Debian patches". The Debian FAQ has little to comment on this matter: "Can I use upstream kernels without patches? - Yes, you can." But I would like to know more specific information about exactly what kind of differences are there; surely not only cosmetic changes, otherwise it wouldn't be so much of a problem for the Debian team to adopt/backport a new kernel, and they're still at 3.16, while there is 3.18 already. I tried to unpack linux-source-3.2-rt.parch.bz2 to see what's inside, but, well, seems like it's not really a .bz2 but a .patch.bz2, so that didn't really help... What are those differences, and what are the drawbacks with using an upstream kernel, even if they are purely ideological?

In the Kernel handbook, there's something about "orig"-somethings and "debian/rules", no explanation for either of those, and I don't even have a "debian/rules" neither in Debian kernel source, nor in the upstream one (I just wanted to read what's there in order to understand more about it). I don't think this applies to me, but it makes me feel stupid because I don't understand what those are, then.

Next, Debian Handbook says we are advised to use make-kpkg to build a .deb package with the kernel and install it. Here, however, it says that the Debian Kernel Team recommends to use make deb-pkg instead, which apparently builds a .deb package too, but I haven't found any reference to "deb-pkg" in the 3.14 upstream kernel README file. (Neither do I have any in the 3.2 source from the repository.) I guess that leaves only make-kpkg, which is preferred over the "old" way of "make install; make modules_install" because it's easier to install and remove, is that right?..
Last edited by darkpenguin on 2015-03-05 11:51, edited 1 time in total.

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Summary on building a kernel from upstream

#2 Post by stevepusser »

You might backport the upstream kernel by following this: https://wiki.debian.org/SimpleBackportCreation

But it looks like they did need changes that might be beyond you: http://metadata.ftp-master.debian.org/c ... _changelog

The MEPIS mcr120 Liquorix kernel builds are confirmed to run on Wheezy, and get good reviews: http://main.mepis-deb.org/mepiscr/testr ... -liquorix/
MX Linux packager and developer

darkpenguin
Posts: 8
Joined: 2014-06-22 13:05

Re: Summary on building a kernel from upstream

#3 Post by darkpenguin »

As far as I understand, you can "backport" something from the testing repo, but not something from outside - that would need more effort to add to the repo... But that's not the question, anyway. The questions are:

- So, to build a kernel from kernel.org, you just grab the kernel, configure it, make-kpkg, and install it, is that right?
- This way is preferred over make deb-pkg or make install only due to installation/removal simplicity, and there's no other differences or "anything I should know" to choose the preferred way?..
- What do they do to the kernel when they add it to the debian repo? Are there any differences/drawbacks with using a "kernel.org" kernel instead of one from the repo? I don't know, some optional Debian-specific set of patches?..
- Is there any reason to use the one in the repo instead? Maybe those patches actually do something useful?..

And why would I use the MEPIS builds instead of kernel.org... Hey, those are BUILDS, and I'm talking about sources - I'm building the kernel myself! I'm not talking about builds, but about "Debian repo sources / Kernel.org sources" comparison!..

1of12
Posts: 27
Joined: 2015-02-23 09:38

Re: Summary on building a kernel from upstream

#4 Post by 1of12 »

darkpenguin wrote:As far as I understand, you can "backport" something from the testing repo, but not something from outside - that would need more effort to add to the repo... But that's not the question, anyway.
Just read the definition of "backport".
darkpenguin wrote:The questions are:

- So, to build a kernel from kernel.org, you just grab the kernel, configure it, make-kpkg, and install it, is that right?
make-kpg is one way of building a kernel using Debian package management tools yes.
darkpenguin wrote:- This way is preferred over make deb-pkg or make install only due to installation/removal simplicity, and there's no other differences or "anything I should know" to choose the preferred way?..
The difference is that one method uses the package manager to install the kernel, the other method does not. I prefer the "make" (autotools) method and building as root from /usr/src - old habits die hard. If you're going to build your own kernel anyway, you're going to have to maintain it, so there's not really much point in packaging it.
darkpenguin wrote:- What do they do to the kernel when they add it to the debian repo? Are there any differences/drawbacks with using a "kernel.org" kernel instead of one from the repo? I don't know, some optional Debian-specific set of patches?..
Download the package, unpack it and find out. Debian stable kernels usually have some backported patches, apart from that it's the same as an upstream Linux kernel.
darkpenguin wrote:- Is there any reason to use the one in the repo instead? Maybe those patches actually do something useful?..
Unpack the deb files and have a look at the patches?

The distribution's kernel is stable and it's maintained for you. This means "apt-get upgrade" will fetch the updated kernel and install it. If you maintain your own kernel, that means patching and rebuilding yourself every time there is an update.

darkpenguin
Posts: 8
Joined: 2014-06-22 13:05

Re: Summary on building a kernel from upstream

#5 Post by darkpenguin »

1of12 wrote:I prefer the "make" (autotools) method and building as root from /usr/src - old habits die hard. If you're going to build your own kernel anyway, you're going to have to maintain it, so there's not really much point in packaging it.
My habits die hard, too - I do it the same way. :) Obviously, I will have to "maintain it", that is, update it when I want to - that's the whole point of using an "upstream" kernel. I just thought, why do people use make-kpkg then?.. I guess people like to see all their kernels in the package manager, which makes sense.

I tried unpacking a "vanilla" 3.16 kernel source and a "backports" kernel source (source, not deb), and took a look at them, but... well, I'm not good enough to find (and much more, understand) any differences between them unless there's a file with a summary of any changes done... and that's what I'm trying to find. Well, I see that the whole "firmware" folder is missing, which is apparently due to Debian licensing policy, but I'm going to need a more "human-friendly" description...

:idea: Speaking of descriptions... Oh, why didn't I think about it before!! apt-cache show linux-source-3.16 gives exactly the answer I've been looking for:

Code: Select all

This package provides source code for the Linux kernel version 3.16. This source closely tracks official Linux kernel releases. Debian's modifications to that source consist of security fixes, bug fixes, and features that have already been (or are believed to be) accepted by the upstream maintainers.
Damn. What a lamer I am. :lol:
Last edited by darkpenguin on 2015-03-06 20:48, edited 1 time in total.

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Summary on building a kernel from upstream

#6 Post by stevepusser »

Well, I'm a sharing kind of guy :lol: so building packages is the only way I can share my work with others.

Usually, debian packagers will have the patches inside the debian folder (it's the debian.tar.gz or tar.xz file) inside a folder called "patches". That's how the very heavily patched Liquourix kernel does it. I've never backported a Debian kernel, it takes long enough to build the Liquorix ones on my poor laptop.
MX Linux packager and developer

darkpenguin
Posts: 8
Joined: 2014-06-22 13:05

Re: Summary on building a kernel from upstream

#7 Post by darkpenguin »

There's no "patches" nor "debian" folder in the Debian kernel source. I would expect it to be already patched.

Anyway, I've learned what I wanted: building a "vanilla" kernel is done exactly the same way as building one from the repository, and the only difference is that the Debian one may include bugfixes that are still "on their way" to the vanilla kernel. Thank you!

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Summary on building a kernel from upstream

#8 Post by stevepusser »

darkpenguin wrote:There's no "patches" nor "debian" folder in the Debian kernel source. I would expect it to be already patched.

Anyway, I've learned what I wanted: building a "vanilla" kernel is done exactly the same way as building one from the repository, and the only difference is that the Debian one may include bugfixes that are still "on their way" to the vanilla kernel. Thank you!

The real Debian source that you can use to rebuild with the package building tools are (an example): here: https://packages.debian.org/experimenta ... -trunk-586

over on the right side. The orig.tar file is the unchanged source tarball from kernel.org The patches are found in the debian tarball, in the /patches folder. The build process applies the patches, and builds a kernel, by default for the host system's architecture.

Note that this kernel's headers is set to use gcc-4.9. If you only have an older gcc, you'll have to grep through the files in the /debian folder and change it to what you have available. That's what I do for the Liquorix kernel with every build.
MX Linux packager and developer

suberimakuri
Posts: 16
Joined: 2010-01-28 10:21

Re: Summary on building a kernel from upstream

#9 Post by suberimakuri »

Sorry this is an older post, but I'm looking at moving to trunk kernels to get newer device support.

Maybe I'm misunderstanding the OP and most people who want to build kernel from source..... but the desire is to use a newer kernel right?

Why not run with the trunk pre-built kernels in experimental?
pin experimental priority low in apt so you can just selectively "-t experimental" as needed?

Unless there's a particular feature that isn't selected in .config by Debian kernel team, I don't see why need to build from source?

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Summary on building a kernel from upstream

#10 Post by stevepusser »

Do the newer kernel's headers need a newer gcc version? That essentially would make them a non-starter for Jessie, and you need the headers for things like Virtual Box or many drivers.

I make backports of the Liquorix kernel for Jessie for that reason; they use Jessie's gcc-4.9.

https://build.opensuse.org/project/show ... r:codelite
MX Linux packager and developer

Post Reply