Re: OpenVPN fails
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
Reply to: