[Question]: Can't checkout _exact_ kernel release

Fri Sep 18 00:54:33 UTC 2020

[resending, forgot to CC kernel-team!]

Hi Cascardo,

Thank you very much for the detailed explanation - I hope I understood
it correctly.

Am I correct in understanding that, by adding the "xxx.zzz" at the
end, and keeping the "4.4.0" instead of "4.4.y", it lets you make your
own choices about how to apply the LTS kernel.org patchset?

========
Let's say for example, kernel.org releases 4.4.0

Canonical takes this, applies their own patch C1, and releases
Ubuntu-4.4.0-1.0, which is patchset [C1] on top of kernel.org 4.4.0

Then, let's say kernel.org releases 4.4.1, which is patchset [P1, P2,
P3] on top of 4.4.0

Then, let's say Canonical wants to get these patches too, but decides
to modify P2 with C2, and reverts patch P3 with C3.

Having done this, Canonical releases Ubuntu-4.4.0-1.1, which is
patchset [C1, P1, P2, C2, P3, C3] on top of kernel.org 4.4.0, or in
other words patchset [P1, P2, C2, P3, C3] on top of Ubuntu-4.4.0-1.0

So effectively, the kernel.org patchset between 4.4.0..4.4.y gets
taken by Canonical, potentially modified, and the "y" is effectively
mapped to xxx.zzz, and we keep the 4.4.0 base version number, since
its not really 4.4.y - because the patches between 4.4.0 to 4.4.y are
potentially shuffled and modified by Canonical.
========

Am I on the right track? I hope that example wasn't completely
ridiculous. I am definitely showing my ignorance about kernel
versioning.

I am also interested about exactly what the naming rules for xxx.zzz
are - I had a look at the Debian page you linked, but it seemed quite
open-ended regarding how to interpret the string. I assume Canonical
has rules for how to increment xxx and zzz? You mentioned the
"186-generic" being the ABI flavour - does xxx get incremented when we
can no longer guarantee ($xxx - 1) modules working with $xxx? What
about zzz?

Having said that I would really like to try building the kernel
"properly", i.e. how you guys do it. What's the difference between the
debian/ and debian.master/ directory? I know debian/ is the standard
directory where debian-package-manager specific stuff goes, but I
noticed the "updateconfigs" target in "debian/rules.d/1-maintainer.mk"
invokes the "kernelconfig" script, and there's one in both debian/ and
debian.master/

Thanks again for your detailed answer,

Best Regards,
Maxim Blinov

On Fri, 18 Sep 2020 at 01:52, Maxim Blinov <maxim.a.blinov at gmail.com> wrote:
>
> Hi Cascardo,
>
> Thank you very much for the detailed explanation - I hope I understood
> it correctly.
>
> Am I correct in understanding that, by adding the "xxx.zzz" at the
> end, and keeping the "4.4.0" instead of "4.4.y", it lets you make your
> own choices about how to apply the LTS kernel.org patchset?
>
> ========
> Let's say for example, kernel.org releases 4.4.0
>
> Canonical takes this, applies their own patch C1, and releases
> Ubuntu-4.4.0-1.0, which is patchset [C1] on top of kernel.org 4.4.0
>
> Then, let's say kernel.org releases 4.4.1, which is patchset [P1, P2,
> P3] on top of 4.4.0
>
> Then, let's say Canonical wants to get these patches too, but decides
> to modify P2 with C2, and reverts patch P3 with C3.
>
> Having done this, Canonical releases Ubuntu-4.4.0-1.1, which is
> patchset [C1, P1, P2, C2, P3, C3] on top of kernel.org 4.4.0, or in
> other words patchset [P1, P2, C2, P3, C3] on top of Ubuntu-4.4.0-1.0
>
> So effectively, the kernel.org patchset between 4.4.0..4.4.y gets
> taken by Canonical, potentially modified, and the "y" is effectively
> mapped to xxx.zzz, and we keep the 4.4.0 base version number, since
> its not really 4.4.y - because the patches between 4.4.0 to 4.4.y are
> potentially shuffled and modified by Canonical.
> ========
>
> Am I on the right track? I hope that example wasn't completely
> ridiculous. I am definitely showing my ignorance about kernel
> versioning.
>
> I am also interested about exactly what the naming rules for xxx.zzz
> are - I had a look at the Debian page you linked, but it seemed quite
> open-ended regarding how to interpret the string. I assume Canonical
> has rules for how to increment xxx and zzz? You mentioned the
> "186-generic" being the ABI flavour - does xxx get incremented when we
> can no longer guarantee ($xxx - 1) modules working with $xxx? What
> about zzz?
>
> Having said that I would really like to try building the kernel
> "properly", i.e. how you guys do it. What's the difference between the
> debian/ and debian.master/ directory? I know debian/ is the standard
> directory where debian-package-manager specific stuff goes, but I
> noticed the "updateconfigs" target in "debian/rules.d/1-maintainer.mk"
> invokes the "kernelconfig" script, and there's one in both debian/ and
> debian.master/
>
> Thanks again for your detailed answer,
>
> Best Regards,
> Maxim Blinov
>
> On Fri, 18 Sep 2020 at 00:41, Thadeu Lima de Souza Cascardo
> <cascardo at canonical.com> wrote:
> >
> > On Fri, Sep 18, 2020 at 12:08:39AM +0100, Maxim Blinov wrote:
> > > Hi everyone, apologies in advance for the noob question:
> > >
> > > I want to build exactly the same kernel version as the one that ships
> > > with my Ubuntu 16.04 release (yes I know it's quite old now), "Linux
> > > 4.4.0-186-generic". But everytime I checkout the git tag called
> > > "Ubuntu-4.4.0-186.216", `make menuconfig` insists that I'm building
> > > "4.4.228". Details below...
> > >
> > > So first I git clone the Ubuntu kernel code, and I'm a bit confused -
> > > there seem to be two git repos:
> > >
> > > git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
> > > (Recommended by this answer:
> > > https://askubuntu.com/questions/947833/where-to-get-ubuntu-linux-kernel-source-package)
> > >
> > > git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
> > > (Recommended by official docs:
> > > https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide)
> > >
> >
> > The second one is where we push things, so should be uptodate. The first one
> > mirrors the first one, so could be outdated.
> >
> > > I ofcourse lean towards using official Ubuntu documentation, and use
> > > the second link. But what is the difference between the two?
> > >
> > > But my major problem, is that I can't seem to checkout _exactly_ the
> > > same version as my running kernel: If I do `$uname -rs` on my
> > > workstation, I get "Linux 4.4.0-186-generic"
> > >
> > > So then I do `git tag` to find it in the repo, and I find this:
> > > Ubuntu-4.4.0-186.216
> > >
> > > Ok, I check it out, and I copy the .config from
> > > "/usr/src/linux-headers-4.4.0-186-generic/". Then I go into the kernel
> > > directory, do `make menuconfig`, and I see:
> > >
> > > ".config - Linux/x86 4.4.228 Kernel Configuration"
> > >
> > > at the very top of the ncurses menuconfig window. But I thought I
> > > checked out 4.4.0-186?
> > >
> > > If I then try to overwrite the .config file, the only change between
> > > .config and .config.old is like this:
> > >
> > > $ diff .config .config.old
> > > 3c3
> > > < # Linux/x86 4.4.228 Kernel Configuration
> > > ---
> > > > # Linux/x86_64 4.4.0-186-generic Kernel Configuration
> > >
> > > which proves to me that indeed, the git tag name does not seem to
> > > correspond with the Linux version. If someone could suggest the
> > > correct procedure for this, it would be greatly appreciated.
> > >
> > > (My motivation is for kernel hacking - I would like to be able to
> > > evaluate my kernel changes on a desktop system in the context of an
> > > official distribution.)
> > >
> > > Best Regards,
> > > Maxim Blinov
> > >
> > > --
> > > kernel-team mailing list
> > > kernel-team at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> >
> > 4.4.228 is the upstream linux version. kernel.org continues supporting 4.4 and
> > releases 4.4.y. Ubuntu picks up those updates and applies them to its kernels.
> >
> > However, in order not to have to update the orig.gz tarball (that is Debian
> > source package parlance) with new upstream versions, it is maintained as if
> > they are still 4.4.0. That prevents the mirrors from exploding with so many
> > large files, amongst other things.
> >
> > After the dash, that is, 186.216, is what is called a Debian revision. More
> > information about this, you will find at:
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
> >
> > Now, 4.4.0-186-generic (or for some, only 186-generic), is what is called ABI,
> > or rather, ABI-flavour. In practice the flavour is part of the ABI. Now, ABI
> > may refer to a bunch of interfaces. In this case, it refers to the ABI between
> > the kernel and its modules. Ubuntu moves the ABI for every version of the
> > kernel that it releases.
> >
> > Now that we have all that explained, the way Ubuntu puts the ABI into the
> > kernel uname is by using the debian build scripts under debian/. If what you
> > need is to build a kernel that is close to what Ubuntu ships, but you don't
> > care about these versions and ABIs as long as you are building the same
> > sources, just keep building the kernel as you are probably used to: make
> > menuconfig, make modules, etc.
> >
> > Otherwise, you should be using tools like dpkg-buildpackage, debuild, etc. And
> > in that case, if you need to tweak the config options, look at
> > debian.master/config/. Configs are kept there and may be updated after changing
> > some of its files by running 'fakeroot debian/rules updateconfigs'. Also,
> > notice there is a debian.master/config/annotations file, and that should be
> > kept in sync with the config options. It's kept manually, there is no tool to
> > help you there. So, if you are changing a couple of options, just edit
> > debian.master/config/config.common.ubuntu and debian.master/config/annotations
> > manually, run fakeroot debian/rules updateconfigs, commit your changes, then
> > try building with dpkg-buildpackage.
> >
> > Now, if you want to trim the config too much, maybe you are better off with
> > building the old way or maybe just try removing that annotations file, replace
> > debian.master/config/amd64/config.common.amd64 (or whatever architecture is
> > yours) with your config and try your luck. Another option is cloning the
> > linux-kvm repo and check if its config is a better fit for you. This kernel is
> > based on the same xenial one but has different config options and about 4
> > patches doing small boot time tweaks. Its repo is at
> > git://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-kvm/+git/xenial,
> > and if you git fetch --tags, you may find tag Ubuntu-kvm-4.4.0-1077.84 will
> > match closely Ubuntu-4.4.0-186.216.
> >
> > Cascardo.