Yesterday, I had to reboot one of my Linodes and although it was configured to use the latest 3.4 kernel during its set up some time back, it booted into 3.5.2 kernel, which I understand is the current "latest" kernel at Linode. I think such silent major version upgrade is a very bad idea. Yes, I was able to downgrade back to 3.4 kernel without problem, but only after I spent considerable time figuring out why one of my programs stopped working.

Moreover, kernel config as used by Linode is not kept in sync with the kernel:
zcat /proc/config.gz | grep CONFIG_IP_NF_QUEUE
says "CONFIG_IP_NF_QUEUE=y" on Linux 3.5, although this particular subsystem was removed completely in Linux 3.5.
I think Linode just used their 3.4 config on 3.5 kernels, which works, mostly, except that the deprecated and removed subsystems appear is if they are still in the kernel, when they are not...

I think at the very least, Linode should amend the kernel name in the administration interface. E.g. currently it says "Latest 3.5", while in fact it means "Latest kernel available", and it can get upgraded to brand new 3.6 kernel whenever Linode decides to.

Just pointing out that 3.4 -> 3.5 is a minor version number change, not a major one.

That said, I agree that "Latest 3.4" or "Latest 3.5" is a bad/confusing name and something like "Latest 3.x" would be less misleading.

The tl;dr of that is:

3.4 -> 3.5 is now equivalent to 2.6.4 -> 2.6.5, due to a change in version naming.

I agree that a kernel alias called "Latest 3.4" should not be switching to 3.5, but I disagree that users should not by default be silently upgraded to the latest minor revision unless they otherwise specify.

The next major kernel revision would be 3.x -> 4.0, which is the equivalent of 2.4 -> 2.6 was under the old naming system.

Use pv-grub, they YOU control what kernel you use.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

The point is, current settings are misleading. Using 3.4.x kernels is ok with me, 3.5.x are not. I thought setting named "Lastest 3.4 kernel" would allow me to keep using latest 3.4.x kernel, including possible security fixes, etc., without switching to more recent kernels. But I got upgraded to 3.5 kernel anyway, and it broke things on my server.

Using your own kernel requires additional testing. Although Linode uses vanilla kernels right now, it was not the case in the past. You cannot just deploy your distro's kernel on someone else's custom virtualization stack without careful testing. Linode does test the kernels it deploys with the major distros, I hope, so I would prefer to use these kernels. I just don't want to be upgraded to the "latest and greatest" unexpectedly.



I was wrong, apparently, and it's considered a minor version update, sort of... Pity Linus decided to pull perfectly working stuff out of the kernel during minor version upgrade (ip_queue got pulled out of 3.5). Yes, it was deprecated for some time, but you just don't break things in a minor version update for the sake of it. I cannot imagine Microsoft removing functionality from Windows during a service pack deployment. So, regardless of whether 3.4 -> 3.5 is a "big" or "small" update, I cannot just deploy it without testing on a staging/test servers first..

Then that's your fault. Deprecation is saying "Dont use this anymore. Migrate off of it. It *will* go away in a later version". The act of marking something deprecated is your notice of this. It was marked deprecated in favor of libnetfilter_queue in 2.6.14 which came out in 2005.

I'd also like to point out that you are more than welcome and able to choose a static kernel from the list. You don't HAVE to choose "Latest"

Yes, but it said "Latest 3.4", not "Latest 3.x". It should at least do what it says, because 3.5 and 3.4 are clearly two different numbers.

I agree the labels are a bit strange, 3.4-3.5 is still *minor*. If you *must* rest assured that your kernel will not change, choose a static one

Then you don't get security updates which is probably worse than having your kernel upgraded to a new minor version automatically.

Then don't do that. I think purrdeta was just saying if for whatever reason you don't want your kernel automatically updated, keep it at a static version.