Just nitpicking a bit, but the kernel files and packages are labeled with version "4.4" in /boot but /etc/lib/modules are labeled "4.4.0" - a bit confusing when looking in /boot while setting up to run mkinitrd

In other news: this beta is even faster and slicker than prior current in the old MSI netbok (Intel Atom N280)!

This is the way the kernel outputs by default. If you untar the kernel source, it'll do it to linux-4.4/, but when you go to install the modules, it'll put it in 4.4.0/. I'd imagine the naming in /boot is based off the linux source folder, not the modules folder.

But, by the time the stable release is put out, I'd imagine Pat will be using the latest point release of the 4.4 series, so the issue likely won't be visible in 14.2.

D'OH! "Use the source, Luke."

I had the same thought after upgrading the kernel from 4.1.15 to 4.4.0. I took a look in /boot and saw that the kernel was named "4.4", but when I manually edited mkinitrd.conf and put "4.4" in the version line, mkinitrd -F threw back an error. Of course I figured it out later, but I couldn't help thinking something like: hey, here's one of Slackware's extremely rare inconsistencies.

There is no inconsistency.
The source tarball is called "linux-4.4.tar.xz" which determines the package version however the running kernel announces itself as 4.4.0.

3 members found this post helpful.

... except, then you get this: /boot/vmlinuz-huge-4.4, and /lib/modules/4.4.0, which is clearly an inconsistency between the components that combine at runtime to make up the kernel.

Regardless, of what the package itself is called, it'd probably be worth adding $SUBLEVEL to at least the vmlinuz filename just to make it match its run-time modules directory name (and uname -r). Though, I doubt Slackware will ever ship with a .0? so, its somewhat of an academic issue (but still a trivial fix).


I've been using my own kernel packaging and naming scheme for a few years now, and this was one of the things I decided I wanted to fix. I run a .0 far more often that Slackware does after all.

For anyone interested, this is how my locally built kernel packages look:
/usr/obj/... is the out-of-tree build directory I use when building the kernel, which helps keep the source pristine. Source is in /usr/src/linux-4.4.y and is a single-branch shallow git clone from kernel.org's stable.git

The inconsistency comes from upstream. And yes, I wish they would release such kernel tarballs as linux-4.4.0.tar.xz, not linux-4.4.tar.xz. But I'm not about to repack it (and lose the GPG sig) just to fix that only for the .0 that won't last long in -current.

2 members found this post helpful.

Thanks for the clarification. I guess this can be filed under "first world problems".

Marking as "solved" so as to not get into a theological discussion. I was just taken by surprise during testing on one of the laptops and I didn't think to check the original source archive; it has been so long that I got an error running mkinitrd that I was befuddle (getting old I guess). As our BDFL says: it won't last long.

Let's just blame L. Torvalds - he yells at enough people anyway so should be able to take it.