Re: OpenVPN fails
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:tony@vanderhoff.org
Buckinghamshire, England |
Reply to: