Linux Kernel 4.6 Has Reached End of Life, Users Urged To Move To Linux 4.7.1

Reader prisoninmate writes: Immediately after announcing the availability of the first point release for the Linux 4.7 kernel series, Greg Kroah-Hartman also informed the community about the launch of Linux kernel 4.6.7, which is the seventh maintenance update for the Linux 4.6 stable kernel branch, but it also looks like it's the last one for the series, which has now officially reached end of life. Therefore, if you're using a GNU/Linux operating system powered by a kernel from the Linux 4.6 branch, you are urged to move to Linux kernel 4.7 as soon as possible by installing the brand new Linux kernel 4.7.1 build.

Comments

Too slow

[wonkey_monkey]

Firefox is already on version 47 or something. You guys are going way to slow.

Hmm, I'm still only on 2.6. I need to get a wiggle on too!

Re:Too slow

[thegarbz]

That's very outdated thinking. Version numbers are meaningless. There should only be one Linux which magically changes in the background and is always up to date. That's far less confusing.

Re:Too slow

[Anonymous Coward]

Also, that Linux should go around killing other Linuxes and absorbing their power!

THERE CAN BE ONLY ONE!!!

Re:Too slow

[RavenLrD20k]

Considering that this is Linux and not organic immortals we're talking about...

I think it's less Highlander; more Mega Man.

Re:Too slow

[Penguinisto]

Hmm, I'm still only on 2.6. I need to get a wiggle on too!

I know, right?

[root@oneOfMyProdServers ~]# uname -a
Linux oneOfMyProdServers 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

*sigh*... guess it's time to tell my $2bn/yr-revenue employer to get off their asses and get everyone onto systemd while I'm at it (*shudder*).

All joking aside, though... I know of corps still using really ancient RHEL 2.x stuff, mostly because they cannot justify migrating off it, but at the same time the thing still has enough justification to stay plugged-in (albeit on its own isolated network...)

Pretty sure not everyone is going to heed TFA's call, eh?

Re:Too slow

[elal1862]

Why is it outdated thinking and what changes do you have in mind?
Remember that version numbers are mostly intended for developers (to keep track of code revisions), not end-users. My only gripe with version numbers would be that every developer seems to use their own definition of what's a major or a minor revision, rendering the decimal point moot.
But in the end, an arbitrary number is just that: an arbitrary number — and if you rather don't want to deal with that, Manjaro may be a distro for you.

Re:Too slow

[ls671]

I beat you:

uname -a:
Linux oneOfMyProdServers 2.6.30.5 #4 SMP Sun Dec 29 21:46:53 UTC 2013 i686 unknown unknown GNU/Linux

32 bits!

Re:Too slow

[thegarbz]

Why is it outdated thinking and what changes do you have in mind?

Well the key important change is that you update your Sarcasm detector 2.4.27p-3 to Sarcasm360 powered by Windows 10 IoT. Then you won't be in a situation where you're left with a Sarcasm detector that is unable to detect the updated sarcasm of the day based on frigging stupid industry trends. The benefits of the new Sarcasm360 is that it's the last one you will ever buy. From this point forward Sarcasm detection will be a subscription based model and the product will randomly change while you use it. Best of all you can use it anywhere you have an internet connection, unfortunately when your internet connection drops so will the Sarcasm360. We only provide offline access to the Sarcasm360 if you buy the enterprise server to host the back end environment. This enterprise version of Sarcasm360 will also allow you to schedule when updates happen and it won't send every piece of Sarcasm you're lolling at back to the mothership. This is only $9000/year for a 2 seat license.

Sarcasm360 cloud edition can be yours now for only $10/month which is less than the price of 2 skinny chai lattes, a favourite among our hipster millennial development team.

Re: Too slow

[corychristison]

I know you're joking, but I pay for Kernel Care to do something along those lines on a few servers I own.

Re:Too slow

[inode_buddha]

oh fuck that was funny

Re:Too slow

[dunkelfalke]

I beat you

uname -a
Linux (none) 2.4.18-rmk3 #1309 Wed Feb 3 15:56:53 2010 armv4l unknown

Re:Too slow

[Shirley Marquez]

I'd have given this a point but it's already maxed out at 5.

Re:Too slow

[thegarbz]

Glad I could help :)

Re:This is why I stay away from Linux.

[bluefoxlucid]

Data center professionals shouldn't custom-compile new kernels, either. The distribution maintainers backport security fixes; there's no need to upgrade Ubuntu/CentOS/whatever with some frankenkernel that then doesn't work with your ACPI and udev userland.

Re:This is why I stay away from Linux.

[Gaygirlie]

What a load of rubbish. Your distro provides you with kernel-images, there's no need for you to go mucking about with such unless you specifically want to.

How about that TCP bug

[urbster1]

Is that fixed in 4.7? (referring to this https://linux.slashdot.org/sto... )

Re:How about that TCP bug

[Anonymous Coward]

Yes, see the announcement: http://lkml.iu.edu/hypermail/linux/kernel/1608.2/00687.html

and you find the following fixes included:
Eric Dumazet (1):
tcp: make challenge acks less predictable

Jason Baron (1):
tcp: enable per-socket rate limiting of all 'challenge acks'

Note that several distros patched it even earlier (Fedora seems to have fixed it in their kernel 4.6.4-301 according to koji).

Still waiting for zfs support

[james_marsh]

Sadly still no stable support for 4.7 from the zfs on Linux packaging for Debian :(

Re:Still waiting for zfs support

[bluefoxlucid]

I'm more interested in budget fair queuing, which is an instant performance maximization with no trade-offs.

Re:Still waiting for zfs support

[james_marsh]

I thought that was meant to be making its way upstream ages ago?

Re:Still waiting for zfs support

[bluefoxlucid]

Yeah, it was. Haven't heard anything about that in a while.

Stick with LTS kernels

[crow]

If the idea of your kernel no longer getting point releases bothers you, you should stick with the Long Term Stability releases. For most users, this is done by default using the distribution kernels. For users that build their own kernels, upgrading to the next release isn't much more difficult than upgrading to the next bugfix point release. If you're building your own kernel and use commercial kernel modules (e.g., VMWare), then stick with LTS kernels to minimize version conflicts.

So for most Linux users, this story is a non-story.

distro specific upgrade paths

[nimbius]

this might not make a lot of sense for many users, so here are a few upgrade paths by distro:
Fedora: no worries. the kernel was rolled into systemd ages ago and now exists as a ruby implementation of the original lua rewritten systemd.kernel.target.branch.effluent.geezer.pickledbeef
Debian: as per the agreement, this new kernel will require a minimum of ninety (90) days of furious argument and flamewar. please switch to capslock now.
Ubuntu: Did you sign the agreement? what about the waiver? Is mark still staring in through the window with a bucket of off-brown latex paint? I heard he keeps the last person to challenge the kernel revision in an ambulatory dresser in his bathroom.
Gentoo: Follow the Arch documents
Arch: get around to documenting the new kernel for Gentoo.
Slackware: Did you hear what the kids did with this years kernel? oh sweet gods theyll kill us all with their damned agile programming. i saw one the other day on a hovering board and it make me so furious I briefly considered leaving the basement.
LFS: if slackware leaves the basement youll need to crawl out from under their desk and steal a few handfulls of corn chips and a swig of mountain dew. once thats done reference this kernels dependencies as youve scrawled them into the burger wrapper slackware dropped last week. and remember, sunlight is exactly how Riddick depicts it.

Re:distro specific upgrade paths

[stinerman]

Heh. For Debian, I think they're almost ready to move to the 3.x series. Maybe. In a few years.

That was sarcasm. I use Debian and love it.

Re:This is why I stay away from Linux.

[bondsbw]

Yep, this message is first and foremost for distro maintainers. If you didn't custom build your kernel, you probably don't need to start doing so.

Re:This is why I stay away from Linux.

[ls671]

Is there any distro that doesn't provide kernel sources/compile configuration as well for their kernel images, in case you need to add functionality/tweak stuff?

I need to recompile on every kernel security/bug fix but I use the sources/compile configuration from my distro with a couple changes to the config. It is not because I want to, it is because I need to.

Re:I guess this means no VMware!

[nnull]

Although, not official, you can get it to compile and working by changing a single line in vmnet. Unfortunately, VMware has been seriously slacking in linux support lately since 4.6.

Re:Ubuntu 4.4.0?!?!?

[Narishma]

I believe 4.4.x is an LTS version and those are supported much longer than regular versions.

Re:This is why I stay away from Linux.

[ls671]

You silly, I get the security/bug fix from my distro owner but I need to recompile to add functionality not provided in the kernel images.

Am i safe?

[Espectr0]

espectr0@lunix:/home/espectr0# uname -a
Linux lunix 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux

hey Greg...

[advocate_one]

fsck off...

Re:I guess this means no VMware!

[Tanktalus]

I have the same problem with the nvidia drivers - last time I tried using 4.7.0, the nvidia drivers crapped out during installation. I know there's a patch out there somewhere, I'd rather get it from Nvidia.

Re: This is why I stay away from Linux.

[corychristison]

This is why I use Funtoo on my personal machines.

Building a new kernel with my configuration file is a single command, and one more command to install it into the bootloader.

Re:This is why I stay away from Linux.

[Anonymous Coward]

The Linux kernel is extremely stable. There is no need to backport anything. The distros should just upgrade. Fedora already does this.

Android

[hackel]

Google and the Android developers better hurry up and get their act together... The 3.4 kernel on my Nexus 5 is woefully outdated—over 4 years old now! I know they were trying to get all of their patches merged upstream, I hope that happens soon.

Re:Android

[hackel]

3.4 doesn't actually reach EOL until Sept. I'm sure knowing Google's and OEMs' track records, they'll get everyone upgraded by them. Good times.

Re:Ubuntu 4.4.0?!?!?

[yusing]

You are correct sir.