Comment 31 for bug 67299

Dave Gilbert wrote:
> Hi Fabio, That deb seems to work fine for me (reporter of 68888); some
> comments:
>
> 1) The /etc/mdadm/mdadm.conf you create in the initrd is now very different
> from the mdadm.conf you would find in your running system - perhaps it should
> have a different name (mdadm.uuids ?) (Incidentally that is a wonderful sed
> line, I think I've managed to understand it all except for the '!' near the
> start of the first pattern)

It's not necessary. You don't interact with that file directly and it's just a
cosmetic change. I need to keep the delta to fix these issues as small as
possible in order to make it into a stable release and this change is not really
required.

>
> 2) I think it is actually just relying on finding at least one device out of
> each RAID - we seem to have a choice; ideally we would wait for all the
> elements of a RAID to get consistency,

There is no easy way to do that. I have been there already and....

 but if one of the devices has died
> what do we want to do?

... there is no way to know if one of the devices is dead. We can't rely on the
md super block information since they might still report the device as active.

> For a RAID5 we would want most of the devices to be
> there just to be able to get / up, and if the devices are on different
> controllers then there is no guarentee that one won't be a few seconds behind
> the other.

As i said in one of the previous emails, there is no way to know when all
devices will be available to the point were the only moment that we will know
that is at shutdown (think at hot pluggable devices being part of a raid). So we
need to balance our choises and what to do.

> 3) In the non-quiet case can you add a 'waiting for UUID's' and then list all
> the UUIDs in both the initial begin message and everytime we find one?

No sorry.. as i said i need to keep the delta as small as possible. There are
already changes in the package that might be rejected by our QA team.

> 4) Why do you redirect errors from the modprobe to /dev/null? Wouldn't we
> want to know about the errors?

Because we know for a fact that if you are running an ubuntu kernel these
modules will be there and loaded, but if you are running a custom kernel they
might be built in and the error will just annoy the hell out of you :) (just
showing the opposite case of what you are asking for.. somebody will complain
that the errors are there).

Fabio

--
I'm going to make him an offer he can't refuse.