On Mon, Oct 05, 2015 at 05:17:49PM +0100, Tony van der Hoff wrote: > >> Thanks for the quick response, Reco. > >> > >> 1. Kernel is stock wheezy: > >> 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux > > > > But very old one. Current one is 3.2.68-1+deb7u4. > > > > It's a shot in the dark, but - what does this show: > > > > apt-cache policy linux-image-3.2.0-4-amd64 > > > > Hm, I don't understand what that means, but here it is: > > root@tony-lx:~# apt-cache policy linux-image-3.2.0-4-amd64 > linux-image-3.2.0-4-amd64: > Installed: 3.2.68-1+deb7u4 > Candidate: 3.2.68-1+deb7u4 > Version table: > *** 3.2.68-1+deb7u4 0 > 500 http://security.debian.org/ wheezy/updates/main amd64 Packages > 100 /var/lib/dpkg/status > 3.2.68-1+deb7u3 0 > 500 http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages > > apt-get upgrade isn't offering me anything better, so I guess this is > the correct wheezy kernel.
Indeed. And it shows the root cause of a problem (in conjunction with "uname -a") the best way possible. tl;dr version - fix your bootloader. Long version is: - You upgraded your kernel package several times since the initial install, replacing contents of /lib/modules/3.2.0-4-amd64 (where kernel modules reside), /boot/vmlinuz-3.2.0-4-amd64 (kernel itself) and /boot/initrd.img-3.2.0-4-amd64 (initramfs image). - Yet your VPS' bootloader continued to use original (as of installation) kernel and initramfs. Such anomaly did not prevent your VPS from booting - old kernel used old kernel modules (which were put into initramfs at install time) for the boot process. Since apparently your install does not require *that* many modules from outside of initramfs - the problem was unnoticed for the long time. As a "bonus" you are using the kernel with known vulnerabilities, and this goes on for a long time. All your kernel upgrades were silently ignored. So to solve the problem you need to convince whatever thing your VPS uses instead of conventional bootloader to use your current vmlinuz and initrd.img. Don't forget to repeat the process on next kernel upgrade. Alternative way to solve it would be to force rebooting to a "good" kernel with kexec-tools. Big warning is - misusing kexec-tools *will* produce a kernel panic. Hope you have a console access available :) Yet another way would be to migrate from this VPS anywhere they use more-or-less conventional bootloader. Reco