Re: OpenVPN fails
Hi.
On Tue, Oct 06, 2015 at 05:16:29PM +0100, Tony van der Hoff wrote:
> On 06/10/15 16:03, Reco wrote:
> > I propose an experiment.
> >
> > 1) Remove "insmod mdraid1x" from grub.cfg. By using any text editor, *do
> > not* run update-grub.
> > 2) Reboot.
> > 3) While in grub, press 'e' while the default boot entry is selected.
> > 4) Check whenever boot entry still contains "insmod mdraid1x".
> > 5) Boot (Ctrl+x).
> > 6) Run "uname -v".
> >
>
> This box contains 2 500GB disks, configured to raid1.
>
> I don't understand what you're trying to show with this experiment, but
> I removed every instance of insmod raid1 from grub.cfg, and rebooted.
> In grub, sll boot entries still contain that stanza. Wouldn't that be
> expected, having not run update-grub?
Allow me to explain then.
You did not run update-grub, so whatever changes you made to grub.cfg
were expected to be honored on reboot.
Yet on reboot "insmod mdraid1x" was there.
That can only mean one thing: you actually have two *different* /boot
filesystems.
One that gets mounted in Debian (and contains the fresh kernel).
And another one, that is used by grub for grub itself, grub.cfg, and,
the most important - old kernel and old initrd.
And you're using wrong /boot every time you try to use it ;)
Whenever it's a local setup issue (i.e. Debian mounts /dev/sda1 to /boot
instead of /dev/md0 for instance), or some mdraid bug - that remains to
be seen.
Try to change boot disk from one to another - and your problem should go
away. But that's kind of 'sweeping a trash under the rug' approach.
A correct solution would be to ensure that you have exactly one /boot
that's mirrored on two disks.
> After reboot, Uname -v still yields 3.2.57-3+deb7u2
Expected, see above.
Taking all this into account. What does your configuration really look?
Meaning:
1) cat /proc/mdstat
2) cat /etc/fstab
3) cat /boot/grub/device.map
4) parted print on both disks
Reco
Reply to: