Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #177003 > unrolled thread

apt-get source linux-image-$(uname -r) downloads incorrect version

Back to article view | Back to linux.debian.user

Contents

  apt-get source linux-image-$(uname -r) downloads incorrect version David Wittman <dwittman@gmail.com> - 2017-01-26 01:50 +0100
    Re: apt-get source linux-image-$(uname -r) downloads incorrect version Sven Hartge <sven@svenhartge.de> - 2017-01-26 10:10 +0100
    Re: Re: apt-get source linux-image-$(uname -r) downloads incorrect version David Wittman <dwittman@gmail.com> - 2017-01-27 04:10 +0100
      Re: apt-get source linux-image-$(uname -r) downloads incorrect  version Reco <recoverym4n@gmail.com> - 2017-01-27 07:40 +0100
      Re: apt-get source linux-image-$(uname -r) downloads incorrect version Sven Hartge <sven@svenhartge.de> - 2017-01-27 11:10 +0100

#177003 — apt-get source linux-image-$(uname -r) downloads incorrect version

[Multipart message — attachments visible in raw view] — view raw

I am trying to download the kernel source so that I can patch a kernel
module, but I keep finding that it's pulling a more recent kernel release
than the one I specify. IE:

```
vagrant@debian-jessie:~$ uname -r
3.16.0-4-amd64
vagrant@debian-jessie:~$ dpkg-query --show linux-image-$(uname -r)
linux-image-3.16.0-4-amd64 3.16.39-1
```

So what ends up happening is `apt-get source linux-image-$(uname -r)` pulls
the source for the kernel at 3.16.39-1 instead of 3.16.0-4 and my module
builds with the incorrect magicver. I know I can do things to work around
the magicver, but I'm just curious as to why I cannot pull the exact kernel
specified.

I've experienced similar troubles with `apt-get linux-source-$(uname -r)`.

Cheers,

Dave

[toc] | [next] | [standalone]

#177004

David Wittman <dwittman@gmail.com> wrote:

> I am trying to download the kernel source so that I can patch a kernel
> module, but I keep finding that it's pulling a more recent kernel release
> than the one I specify. IE:

> ```
> vagrant@debian-jessie:~$ uname -r
> 3.16.0-4-amd64
> vagrant@debian-jessie:~$ dpkg-query --show linux-image-$(uname -r)
> linux-image-3.16.0-4-amd64 3.16.39-1
> ```

> So what ends up happening is `apt-get source linux-image-$(uname -r)`
> pulls the source for the kernel at 3.16.39-1 instead of 3.16.0-4 and
> my module builds with the incorrect magicver. I know I can do things
> to work around the magicver, but I'm just curious as to why I cannot
> pull the exact kernel specified.

3.16.0-4 is *not* the kernel version but the ABI name used. The real
kernel version (at the current time) is 3.16.39.

Everything behaves as it should and everything should work out of the
box.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#177022

[Multipart message — attachments visible in raw view] — view raw

Danke, Sven.

> 3.16.0-4 is *not* the kernel version but the ABI name used.

I feel dumb for asking, but the output of uname is not the exact kernel
version I'm running? That seems contradictory to everything I've learned
and read... including what I just read here[1]:

> Kernel version
> This is the version that appears in kernel messages, filenames, package
names and the output of 'uname -r'.

[1]: https://kernel-handbook.alioth.debian.org/ch-versions.html

[toc] | [prev] | [next] | [standalone]

#177027 — Re: apt-get source linux-image-$(uname -r) downloads incorrect version

	Hi.

On Thu, 26 Jan 2017 20:43:17 -0600
David Wittman <dwittman@gmail.com> wrote:

> Danke, Sven.
> 
> > 3.16.0-4 is *not* the kernel version but the ABI name used.
> 
> I feel dumb for asking, but the output of uname is not the exact kernel
> version I'm running? That seems contradictory to everything I've learned
> and read... including what I just read here[1]:
> 
> > Kernel version
> > This is the version that appears in kernel messages, filenames, package
> names and the output of 'uname -r'.

Handbook lies. uname(1) says that '-r' means 'kernel release' aka ABI,
and '-v' is the kernel version. And then in doubt you always trust
manpage, not book. Compare this:

$ uname -r
3.16.0-4-amd64

to this:

$ uname -v
#1 SMP Debian 3.16.39-1 (2016-12-30)

And as Sven said, they name kernel packages after the ABI ('release'),
not specific version.

Reco

[toc] | [prev] | [next] | [standalone]

#177030

David Wittman <dwittman@gmail.com> wrote:

>> 3.16.0-4 is *not* the kernel version but the ABI name used.

> I feel dumb for asking, but the output of uname is not the exact
> kernel version I'm running? That seems contradictory to everything
> I've learned and read... including what I just read here[1]:

>> Kernel version 
>> This is the version that appears in kernel messages,
>> filenames, package names and the output of 'uname -r'.

> [1]: https://kernel-handbook.alioth.debian.org/ch-versions.html

You have to quote the whole paragraph:

,----
| Upstream version
| The version that Linus or a stable series maintainer uses for a release.
| Currently Linus will use the version format: 4.x[-rcy]. Stable series
| maintainers use the version format: 4.x.y.
`----

,----
| Kernel version
| This is the version that appears in kernel messages, filenames, package
| names and the output of 'uname -r'. In official kernel packages it
| follows the format upstreamversion[-abiname][-featureset]-flavour. It is
| not changed for every new package version. The abiname is changed as
| explained below.
|
| Many programs parse the kernel version string reported by the uname
| system call or command and expect to find at least 3 version components
| separated by dots. For compatibility, the official kernel packages
| currently add '.0' to the upstream version.
`----

So the upstream version is "3.16" (without the added stable release
minor-number), a '.0' is appended and then the ABI version is added,
"-4" in the current case.

This has to be put into the value visible by "uname -r", because all
kernel with the same ABI are binary compatible and modules don't need
recompiling. But all tools use the string from "uname -r" to decide if
the module needs updating, so the Debian maintainers decided to put the
ABI into that value and the real version (including compile date) is
available via "uname -v".

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web