Debian - it updates with the same verison of kernel that is running ?

I've encountered this "problem" several times.
I do an update from the gnome menu, and it install a kernel that is the same version as the one currently running. And then it gives me a warning message that I'm installing the same version kernel and that as soon as the update is finished I need to reboot because some module need to be rebuilt or some such thing.

After the update I reboot and everything is fine.

WTF is going on ?

This is in debian etch.

 

It is a precautionary measure. After the upgrade, the modules on disk have changed but your running kernel is still the old one until you reboot. If a module which was not previously loaded needs to be loaded *after* the upgrade you run into two possible major scenarios:

1. The module versioning system notices that the module is not made for the currently running kernel and refuses to load it. The symptom to you is that some kernel functionality is not working anymore. At least not until you reboot. The problem is that for the vast majority of users, the reason why the system no longer works correctly is very obscure. It is safer to ask everyone to reboot.

2. The module versioning system does not catch that the module should not be loaded and lets the new module load. If this module depends on a modification in the new kernel, you can run into trouble because you are still running the old kernel.

I don't know what module versioning can and cannot catch. (Module versioning is probably not even the official name.) I just know that in general there's a limit to what versioning systems can catch.

So anyway to make sure that general users don't end up in a situation where the system does not work, they recommend that you reboot. Often in the past I've delayed rebooting for several hours without any problem. But then again, I know what to look for if the system starts behaving strangely.

 

No, my question was, why is the update doing an update with the same version of kernel that is running

 

Are you sure it's the same exact version? Or maybe they did some modifications that didn't warrant a version number increase.

 

If it is asking you to reboot, it is not quite the same version. Debian and Debian-based systems add a version number specific to the distribution. When you query the kernel version number you can see something like 2.6.24-11, 2.6.24-16. The actual kernel version in these is 2.6.24. The "-11", "-16", etc. are the additional numbers specific to the distribution. They need to do that because distributions typically customize the kernel for their users. Whenever a change is made to software and that change is released, the version number must change. (That's just good software engineering.) But the distributions cannot just change kernel version number. If Debian changes 2.6.24, they can't release 2.6.25. That kind of version change is the prerogative of the kernel developers, not distributors. What they can do is tack on a "-number" at the end of the version number. (They can't use 2.6.24.1 because the fourth number is also used by the kernel developers, I think.)

The question now is how much of a difference does a difference make? When you install 2.6.24-16 over 2.6.24-11, you are clearly installing a different kernel. But this is not the same difference as installing 2.6.24-11 over 2.2.17-4. When you install 2.6.24-16 over 2.6.24-11, you can say:

1. From the perspective of kernel specifications, you are installing the same kernel because both are 2.6.24. Both are designed to provide the same functionality. So if you use a system tool like "udev" which says it needs 2.6.24, that tool with work with both because at the level of specs they are the same kernel.

2. You are installing a different kernel because one is 2.6.24-11 and the other 2.6.24-16 from the perspective of the internals. The implementation is different.

BTW, I think my explanation of modules above is no longer true. I mean the risk of cross loading modules is in theory possible. However, in modern distributions modules for different kernel versions are installed in their separate directories so there should be no risk of 2.6.24-11 loading a 2.6.24-16 module. So the only reason I can see to ask for a reboot is just to be on the safe side. Presumably, the new kernel fixes bugs that were present in the old one. Better switch to the new kernel as soon as possible.

 

Hmm, maybe I was wrong on the older kernel number.
Uname -r gives 2.6.18-6-686
I thought the old one was exactly the same, but maybe not.

 

Well, if you ever see an upgrade in which the previous kernel number and the newer one are exactly the same, either a) there was a bug in packaging somewhere or b) the maintainers are doing something I've never seen before.

Regarding "a)", I've seen cases where a bug in packaging caused upgrades to reinstall a package over itself. That was weird but real.