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