CENTOS boot over raid partition

[Antanas Masevicius]

Hello,

i see your point. File corruption should really be taken into account. This
is what cannot be solved on HW raid setup. Thus having /boot on md0 is
comparable in this context with having /boot on hw raid. That is raid in
this case gives protection from disk physical failure excluding corruption.
Yet, for some users it might be sufficient.

Thank You for advices.


best regards,

Antanas Masevicius
TENDO LT
https://tendo.lt


On Tue, Nov 25, 2014 at 9:57 AM, Thomas Neumann <blacky+fai at fluffbunny.de>
wrote:

> On Tuesday 25 November 2014 09:16:28 Antanas Masevicius wrote:
> > Yes, thats a solution, but still, it would be better to have some kind of
> > automation. One way probably would be to run some kind of configuration
> > engine, or write some script fixing md mbr from init.d. How would you do
> > that?
>
> During/after installation of a new machine:
>   install mbr on second disk and never touch it again
>
>
> _After_ successfully booting the new kernel:
>   synchronize contents of /boot to second disk
>   (adjust hd0 / hd1 as necessary)
>
> Implement this is as a small script but _never_ call this script
> automatically
> _during the installation of a new kernel package_. (This prevents
> promoting a
> logical error to your backup /boot filesystem.)
>
> If you want to fully automate it then you could add this script to be run
> from
> /etc/rc.local or similar. If you've reached this stage you can be
> reasonably
> sure the kernel has managed to boot and mount all required filesystems.
> (However there's no guarantee the network works as expected, so you should
> make sure the relevant modules are included in the initrd or have console
> access available.)
>
>
> Yes, this is a bit more work then trying to get a software-raid /boot to
> work.
> But it has 2 distinct advantages:
>  - if something accidentally deletes / corrupts a file in /boot there's
>    still a reasonable chance for recovery _during system boot_
>  - it works with all combinations of fat/gpt/md/lvm/crypt/btrfs
>
> bye
> thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20141125/992bb8e5/attachment.html>