initramfs/udev/mdadm/lvm2 integration

[Reinhard Tartler]

Scott James Remnant <scott at ubuntu.com> writes:

> On Fri, 2007-09-14 at 09:58 -0700, Kees Cook wrote:
>
>> On Fri, Sep 14, 2007 at 11:17:13AM -0400, Phillip Susi wrote:
>> > Kees Cook wrote:
>> > > So, the question is, which is the "least surprising"?
>> > > 
>> > > a) having the machine spew "I can't mount, here's what you can do...",
>> > >    potentially endangering SLA and/or convenience.
>> > > b) mounting degraded, possibly due to poor timing, potentially endangering
>> > >    partitions and/or data.
>> > > 
>> > > I personally think "b" is more surprising.  I don't think it would be
>> > > hard to add another boot-time flag that means "auto-boot-when-degraded"
>> > > (which could be mentioned in the spew from "a").
>> > 
>> > I find A to be a lot more surprising.  The whole purpose of having a 
>> > raid 5 setup is so the system will continue to operate just fine in the 
>> > event of a drive failure.  This includes booting up, which is often when 
>> > failures occur.  Sure, needlessly degrading the set isn't good, but the 
>> > system does what it was designed to: keep running.
>> 
>> This is, I think, where we may need to turn to the tech board to get
>> a decision.  Unless Scott trumps us  ;)
>> 
> Since this stuff is being actively fixed both by other distributions and
> Upstream, I think it would be premature to make a TB decision at this
> point since our decision could be different to what gets implemented
> upstream.

Err, Scott, excuse-moi, but are you seriously talking here about system
boot behavior, or how udev-mdadm-lvm-cryptsetup integration should be
implemented? 

I have serious doubts that upstream should decide if a system is able to
boot with a degraded array or not. This should rather be a decision for
the ubuntu-server team, shouldn't it?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4