Thanks! Yea that's what I thought. In our case these will always be headless servers in customer environments where X11Forwarding won't be an option. So the only means of cleaning up (which appears to only involve the unused linux-image-* packages in this case) would be with a careful apt-get purge.

Thanks for the replies. I was clearly misunderstanding dist-upgrade quite a bit.

Tom

I'm reviving an old topic here to clarify something regarding these kernel upgrades (within the same major version). Yesterday I upgraded my kernel on a Jessie install and here's what I ran into. I just wanted to make sure this is expected:

There was clearly a new kernel available for the linux-image-amd64 meta package. When I tried to get this via "apt-get upgrade" here's what I got:

apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  linux-image-amd64
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

What I finally figured out was that I could get the new kernel using this instead:

apt-get install --only-upgrade linux-image-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  linux-image-3.16.0-6-amd64
Suggested packages:
  linux-doc-3.16 debian-kernel-handbook
The following NEW packages will be installed:
  linux-image-3.16.0-6-amd64
The following packages will be upgraded:
  linux-image-amd64
1 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 34.5 MB of archives.
After this operation, 168 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

That worked and appears to have run update-grub as well. When I rebooted I was running that new version. Apparently at that point if I wanted to remove the unused kernel, I could then do:

apt-get purge linux-image-3.16.0-5-amd64
update-grub

I'm assuming the "apt-get upgrade" may not work simply because upgrade implies installing the new version and removing the existing(?) which is obviously unsafe for kernels. Is that correct?

Thanks!
Tom

Thanks! I think the fact that I used the expert non-graphical install may be how I ended up with just the jessie source. I've now added the security source. For our purposes I think that will do for now, as adding either the updates or the backports actually doesn't cause anything new to install anyway. Sorry for sending the thread a bit off topic too.

That doesn't do it either. What it gets me is even more confusing:

apt list --upgradable | grep linux

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

linux-image-3.16.0-4-amd64/stable 3.16.51-2 amd64 [upgradable from: 3.16.43-2+deb8u2]
linux-image-amd64/jessie-security 3.16+63+deb8u1 amd64 [upgradable from: 3.16+63]

I have no clue what that second one even is.

I do in fact have the linux-image-amd64 meta package installed. Nothing I do seems to find that linux-image-3.16.0-5-amd64, but rather newer versions of linux-image-3.16.0-4-amd64. Earlier I tried adding jessie-updates and that didn't work either and was even more confusing. That wanted to pull in a version of linux-image-3.16.0-4-amd64 that was 3.16.51-3, but NOT the 3.16.51-3+deb8u1 that actually has the fix. Insane.

My company is sort of really dying for this one. I hope someone has suggestions because this is getting more confusing with everything I try.

SOLVED: OK...Now I think I get it. That new version of the linux-image-amd64 meta package from jessie-security (3.16+63+deb8u1) actually ends up pulling in linux-image-3.16.0-5-amd64 with the 3.16.51-3+deb8u1 version.

That was confusing. Is there some reason that the default sources.list from the install wouldn't include that by default? I can also see we were missing a number of updates because of that.

Tom

This is odd. I currently have 3.16.43-2+deb8u2 installed. I've done "apt update", however "apt list --upgradable" only shows 3.16.51-2 and not 3.16.51-3+deb8u1:

apt list --upgradable | grep linux

linux-image-3.16.0-4-amd64/stable 3.16.51-2 amd64 [upgradable from: 3.16.43-2+deb8u2]

Am I missing something here or am I maybe just hitting a mirror that hasn't synced yet or something?

EDIT: Now I'm even more confused. Bear with me as I'm fairly new to apt etc, but when I run the exact command you did I get this:

apt-get -s install --only-upgrade linux-image-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
linux-image-amd64 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 74 not upgraded.

Why does that not at least show the 3.16.51-2? Totally lost now.

Thanks!
Tom

I think I'm clear on what we're going to try here. Looking at the existing steps we took to use our old CentOS 6 VM in hyperv, we didn't install any services at all. All we did was to ensure that the initramfs included hv_utils, hv_vmbus, hv_storvsc, and hv_netvsc. So I think all we need to do is to add those to
/etc/initramfs-tools/modules and run "update-initramfs -u". Hopefully that's all we need.

Tom

Totally. Under Gentoo I moved to Syslinux when I saw how grub 2 worked. Not a fan.

I actually was able to get the cli working by manually installing the library extracted from the downloaded deb file as described here:

https://preterhuman.net/forum/index.php?topic=98.0

...but that seems more than a little ugly. Still wondering if there's a better way. I noticed looking at the package details:

https://packages.debian.org/jessie/libstdc%2B%2B5

...that it appears to require an i386 libc6 >= 2.3, and I see that my install appears to have libc6-i386 2.19. Maybe that's related(??), though this seems to work.

Tom

No problem. Thanks! I'm not sure I we'd actually ever need that kernel command line, as I'm getting the eth0 name anyway, but I've added it to the grub config be safe.

Tom