Comment 25 for bug 573477

It does seem like there is a timing issue here. Some sort of race
condition causes the array to be assembled incorrectly, or not at all
perhaps. My gut tells me it's something to do with the new upstart
system that ubuntu moved to, because it never happened before they
switched.

I still haven't gotten around to rebuilding my entire array as
suggested... I've currently got quite a bit of data on the array that
I don't really want to have to spend the time to save elsewhere and
copy back.

I've been rebooting whenever it happens as a workaround, but I'm still
hoping someone can help out with finding a full solution.

On Mon, Sep 27, 2010 at 9:40 PM, Bob Blanchett
<email address hidden> wrote:
> I  started getting  an error on the ubuntusplash screen  when my PATA md array wouldnt mount.
> (S)kip mounting or M for manual recovery
> funnily enough goingin into manual mode and  looking at dmesg didnt throw up any errors
>
> /proc/mdstat showed the array as inactive partial and also named it
> /dev/md_p1  whe it had always been known as /dev/md3 (it was always an
> unpartitioned  whole disk md component
>
> Skipping mounting I was always able to get the array up via "disk
> utilty"  by stopping the array, restarting it  and then issuing a sudo
> mount -a (by specified uuid in fsatb .for affected array)
>
> issuing a dpkg-reconfigure mdadm seemed to work through 2 reboots
>
> but then the system after the next reboot  mounted one of the component disks on the mountpoint where the array is
> (dev/sdc1 instead of /dev/md3p1)
>
> unmounted did dpkg-reconfigure again rebooted and got "skip"
>
> mdstat showed the array as up, but umounted
>
> substituted the dev path for the uuid in fstab and its currently
> rebooted ok..
>
> Is there a timing issue somewhere?
>
> --
> Mdadm array fails to assemble on boot.
> https://bugs.launchpad.net/bugs/573477
> You received this bug notification because you are a direct subscriber
> of the bug.
>