Hi. On Tue, Oct 06, 2015 at 11:46:31AM +0100, Tony van der Hoff wrote: > 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?
First, ensure that you're using grub. Something like 'file -sL /dev/sda' should help here. It says "GRand Unified Bootloader" for me (along with other things, of course). While you're at it, check /boot/vmlinuz-3.2.0-4-amd64 with file too. Second, check /boot/grub/grub.cfg *and* /boot/grub/menu.lst to determine what are you really booting by default. Last, check /boot for anything off such as extra kernels or initrds. Reco
