And this how my /etc/apt/sources.list looks like:

Back to top

smxi always ignores any kernel that is less recent, so those are irrelevant, the only thing that is relevant is the backports kernel, smxi can't know to ignore things at random. It gets in your case, two kernels, compares versions, dumps the less recent one, the 3.2, and then proceeds with the backports one, which it knows about because when you use apt-cache show there are two showing.

So the only apt-cache policy that matters is the one for the linux image in backports, if that shoes empty, then smxi can never get that data because it does not exist.

policy may depend on the status of the repo, I have no idea, you can see it easily yourself.

ignore the 3.2, smxi does too, it excludes it because it is less recent than the 3.10 in backports.

since you use 3.2, it will never show anything, since it has already selected the latest kernel available in apt, which apparently apt-cache policy will not show, appears that way though. If you comment out the backports repo smxi should work fine again, since it will then have only one kernel to look at.
Back to top

Well, I already showed
apt-cache policy linux-image-3.10-0.bpo.2-amd64
So I guess I'm stuck because I really don't want to comment out the backports repo, and when a new kernel is available in stable, apt-get dist-upgrade will install it anyway.
Let me tell you that there is really a kernel detection issue in smxi.
I just fired up my little Acer netbook, ran smxi and got:
Your kernel version is: 3.2.0-4-686-pae
The latest kernel for your system is: NO KERNEL DATA
I have backports repo enabled there too.
So, what should I do, ignore warning?
Back to top

there's nothing I can do with backports, if apt-cache policy choses not to show that, then I can't force it to, unless you find some way to do that.

And I can't make smxi ignore the latest kernel that apt-cach show reveals, since that's how it is.

basically just let stable do its thing, it will update the kernels I believe, not sure, it usually does on my stable, during the du.

but I don't use backports, or if I do, I comment it out.

smxi works fine on stable, but it was really made with unstable/testing rolling release in mind.
Back to top

Looking at this once again, backports is given the same priority number, 100, as a locally installed package, which is what confused me.

So you have to manually create priorities in apt using the configuration file, you want the backports-wheezy repo to have a lower priority, like 200, than wheezy, which you make 500 or something.

This may resolve your issue, I believe, though I'm not certain.

smxi excludes all 100 priority items because those are usually what you have locally installed, in fact, I've never seen 100 used for anything other than a local package before this thread. I can't make smxi smart enough to detect that difference safely, and I can't make it ignore the newest kernel in apt, so now it makes sense, time to create an apt custom configuration file for yourself.

sample:
of course, you would change the release names and priority numbers, as long as the wheezy one is higher than the backports, and as long as backports is set to greater than 100, smxi should work to show latest, but it will never work to show the latest old kernel, ignoring backports.

if you play around with this, you might find a way to do it, no idea.
Back to top

I retained this phrase.
So in my netbook I went to jessie.
There are still some issues that I will have to sort out, but overall I am satisfied.
Since I have been on wheezy long before it became stable, there is no need to freak out if I go into testing again, so this is what I might do in my production system as well.
The new kernel was detected and installed without any problem.
I will try apt-pinning as you mentioned and post here the results, but I am also concerned because upgrade to jessie took a long time and it meant a big jolt to the whole system.
Considering that jessie is fairly new, imagine what it would be in a couple years time if I go from wheezy to jessie then.
To ensure a smooth transition, it makes sense to stay always on testing.
Back to top

So now my netbook is in Jessie, looking good, I am going to move everything to testing again.
Regarding smxi, today there was a small upgrade to the kernel point release, smxi detected something but not accurately, since it only seems to detect the point release, but it did prompt me to update kernel, although kernel specs were the same.
The upgrade did happen during dist-upgrade, but GRUB does not even show a different Debian kernel.
Just letting you know.
Back to top

I'm not clear on what you are saying, the jessie/testing kernels look like this:



They upgraded from 3.9 not too long ago. If you do not see changes in your /boot grub, is your /boot not mounted? this is the number one cause of not seeing the new kernel.

smxi in /var/log/smxi.log shows you what kernels were detected and installed, if I remember right.

stable kernels tend to not change version number, and usually get no new grub entry, if I remember right, because they are just a security fix on the existing kernel, not an actual new kernel, so only the debian version number changes.
Back to top

I do see the new kernel in GRUB, what I wanted to say is that after the upgrade (which was not a point release), nothing changed in GRUB.
smxi detected that there was an updated kernel, however behaved just like GRUB, reporting same numbers, not the ending.
It must have been a security update, as you mentioned.
I am back to reporting stuff about smxi.
Back to top