On 05/10/15 17:38, Reco wrote: > 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 >
Reco, thank you very much for taking the time to explain things, but I think we're at cross-purposes. The problem is with my home box, ie the client, and all the information above relates to that box. However, I guess your comments apply nonetheless. Presumably I need to look at grub to fix the boot process. Strangely, the VPS is running the same kernel (3.2.0.4) but tun is loading correctly, so I don't think I should be messing with that end. It's not had a reboot for a while (uptime: 74 days +). You ave me worried about the state of the VPS, however; so maybe the simplest solution would be to upgrade to Jessie. I have full root access, and an oob console to the box. I shall be knocking off for the night now, but really appreciate your help. I'll continue the struggle tomorrow. Thanks, Tony -- Tony van der Hoff | mailto:t...@vanderhoff.org Buckinghamshire, England |