sane behavior for wrong /etc/mdadm/mdadm.conf

Bug #73710 reported by Alan Tam
2
Affects Status Importance Assigned to Milestone
mdadm (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

After upgraded to Edgy, my system took 3 minutes on boot before i can leave the initrd. After careful investigation of the scripts in the initrd, I found that there is a wrong UUID embedded in /etc/mdadm/mdadm. This caused the loop in /usr/share/initramfs-tools/scripts/local-top/md to spin for 180 seconds before it dies.

I guess there is a better way to do that. 180 seconds is too long. I guess no device would need more than 15 seconds to be activated. This long wait make people feel that they machine is actually frozen, since no progress bar is shown during the time. I know it doesn't want to print something to mess up usplash, but they added up (no progress + 180 seconds) gives an insane experience.

Revision history for this message
Alan Tam (at) wrote :

I do not agree this bug is a duplicate of bug 67299. I was aware of bug 67299 and bug 68888 when I reported it.

This bug concerns when the config is wrong. Bug 68888 is about when the config is correct but in an unexpected format. Bug 67299 is about when the whole disk is used for RAID.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

I already explained in the other bug why we can't wait only 15 seconds. We do have machines where devices keep appearing for over a minute.

The wrong UUID is also one of the reasons why everybody was waiting 3 minutes and it has been addressed in the update. Clearly unmerging this bug you lost the information and the option to verify that the bug fix is actually working and making all of us spending more time re-triaging this bug.

Fabio

Revision history for this message
Alan Tam (at) wrote :

I see in the other bug that the UUID is mis-extracted. But I do have a couple of systems here that have a wrong UUID (i.e. it looks like a 128-bit UUID but it isn't what the RAID's UUID). That's why I think it is another bug at all.

The question becomes: when is the file /etc/mdadm/mdadm.conf updated? I don't see it is anywhere in use in dapper (some of my dapper systems even don't have this file), so perhaps they will also get the same problem when I upgrade them?

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

There was no such thing as copying mdadm.conf in dapper. It was introduced in edgy. The UUID you are talking about is the FS UUID required to find any mount point / device that's nothing to do with the raid UUID used by mdadm.

the file is updated each time the initramfs is updated.

Fabio

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

The fixed package is now available in edgy-updates.

Fabio

Changed in mdadm:
status: Unconfirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.