Re: OpenVPN fails
On 06/10/15 13:22, Reco wrote:
> 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.
>
Thanks for your help, Reco,
OK, when I boot, I get a "Welcome to Grub" screen. Various kernel
options, but the default is 3.2.0-4-amd64
> Something like 'file -sL /dev/sda' should help here. It says "GRand
> Unified Bootloader" for me (along with other things, of course).
No... root@tony-lx:~# file -sL /dev/sda
/dev/sda: sticky x86 boot sector; partition 1: ID=0x5, starthead 32,
startsector 2046, 976769026 sectors, code offset 0x63
> While you're at it, check /boot/vmlinuz-3.2.0-4-amd64 with file too.
>
root@tony-lx:~# file -sL /boot/vmlinuz-3.2.0-4-amd64
/boot/vmlinuz-3.2.0-4-amd64: Linux kernel x86 boot executable bzImage,
version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 3.,
RO-rootFS, swap_dev 0x2, Normal VGA
> Second, check /boot/grub/grub.cfg *and* /boot/grub/menu.lst to determine
> what are you really booting by default.
>
I have no /boot/grub/menu.lst
in grub.cfg, I think this is the relevant part:
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian
--class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod raid
insmod mdraid1x
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(mduuid/8e5e48a0c66f10d579cf8c0a04d62d50)'
search --no-floppy --fs-uuid --set=root
58e7a627-6465-4959-8915-af739abc90ac
echo 'Loading Linux 3.2.0-4-amd64 ...'
linux /vmlinuz-3.2.0-4-amd64
root=UUID=43ee739e-a815-4d1a-8a6e-fbc8319d6582 ro quiet
echo 'Loading initial ramdisk ...'
initrd /initrd.img-3.2.0-4-amd64
}
menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 (recovery mode)'
--class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod raid
insmod mdraid1x
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(mduuid/8e5e48a0c66f10d579cf8c0a04d62d50)'
search --no-floppy --fs-uuid --set=root
58e7a627-6465-4959-8915-af739abc90ac
echo 'Loading Linux 3.2.0-4-amd64 ...'
linux /vmlinuz-3.2.0-4-amd64
root=UUID=43ee739e-a815-4d1a-8a6e-fbc8319d6582 ro single
echo 'Loading initial ramdisk ...'
initrd /initrd.img-3.2.0-4-amd64
}
> Last, check /boot for anything off such as extra kernels or initrds.
>
Nothing untoward, I think:
root@tony-lx:~# ls -l /boot
total 16788
-rw-r--r-- 1 root root 129281 Sep 20 17:40 config-3.2.0-4-amd64
drwxr-xr-x 3 root root 8192 Oct 6 12:09 grub
-rw-r--r-- 1 root root 12012066 Sep 22 08:52 initrd.img-3.2.0-4-amd64
drwxr-xr-x 2 root root 49152 Dec 22 2011 lost+found
-rw-r--r-- 1 root root 2114662 Sep 20 17:40 System.map-3.2.0-4-amd64
-rw-r--r-- 1 root root 2842592 Sep 20 17:33 vmlinuz-3.2.0-4-amd64
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England |
Reply to: