On 05/10/15 18:33, Reco wrote: > Hi. > > On Mon, Oct 05, 2015 at 06:15:58PM +0100, Tony van der Hoff wrote: >> 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. > > Oh. I missed that detail. Does not change things much. > Simplifies a console access though :) > > >> 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 +). > > As long as "uname -v" output is consistent with "apt-cache policy > linux-image-3.2.0-4-amd64" output there's nothing to worry about IMO. > > They stopped to change kernel version (i.e. 3.2.0-4) as of Squeeze IIRC, > "because our updates do no change kernel ABI". Since then the full > kernel version ("uname -v") became the only criteria one should check. > As a side note - now we see how stable abovementioned ABI really is. >
Well, even after a night's sleep, I'm getting increasingly confused here. According to synaptic, I have selected the metapackage linux-image-amd-64, which depends on linux-image-3.2.0-4-amd64, the installed version of which is 3.2.68-1+deb7u4. According to uname -v, I am running #1 SMP Debian 3.2.57-3+deb7u2. So, that appears to mean I'm running an out-of-date kernel on this box. As I understand you, that's probably because the boot loader (grub) has become corrupt. I've never touched it, primarily because I don't understand it. But how do I fix it now? -- Tony van der Hoff | mailto:[email protected] Buckinghamshire, England |
