Dear Ned, ... >>> That's pretty much what the article started with if you follow the long >>> history of the first thread on the contribution, but the consensus of >>> the people who commented was overwhelmingly in favor of /boot on RAID1, >> ? ? ... >> >> My response was simply in reply to the 'I can't think of a >> good argument' comment by 'Ned Slider'. >> >> To respond to 'the consensus ... overwhelmingly' remark, the >> mice also overwhelmingly voted to bell the cat. ?Counting >> noses does not make a bad answer more correct; using raid >> rather than flat RO /boot partitions is still less robust >> > > Well it seems you are alone in your view (at present, on this list). I > have yet to see a convincing argument to change my opinion to not place > /boot on a software RAID1 where one has chosen to use software RAID1. > > You state 'putting /boot on raid adds complexity' - I disagree in this > case (for software raid1), it removes the additional complexity of > having to manually resync /boot if it's *not* on the software RAID1 > every time it's updated, and that appears to be the opinion held by > others (and the very reason the page was created in the first place). > Why add complexity - why not let the raid do the work for you. If either > drive fails the system will still boot and the faulty drive can be replaced. > > More robust, but with additional complexity doesn't necessarily make a > better solution for new (inexperienced) users. Best practices are > usually derived through discussion and consensus, something I believe > this thread is striving to achieve. I totally agree and also think it's not so hard to handle /boot on RAID1 even in recovery situations. As mentioned we could add some d-r sections describing some typical scenarios. Best Regards Marcus
