Comment 38 for bug 290885

Here's my findings after testing the packages (grub, grub-installer, initramfs-tools and mdadm) from hardy-proposed.

My testing was carried out on both virtual and physical hardware. The testing on a virtual machine was under VMware using two SCSI disks connected to a LSI Logic controller. The physical test machine was an Intel SuperMicro based 1U server with two SCSI disks also connected to a LSI Logic controller.

I didn't follow the test case exactly as in your first comment, instead of allowing the disks to become out of sync I resynchronised the disks (with mdadm add) after steps 6 and 7 although I don't believe this invalidates my results in any way.

In addition to the test case steps from your first comment I also tested the different 'degraded boot' options (kernel/interactive/static) listed on the Wiki page found here:

https://wiki.ubuntu.com/BootDegradedRaid

I'm delighted to report that everything works as intended.

I have the following comments:

1. I didn't experience any hangs on shutdown as experienced by Bill. It looks like the issue Bill observed is unrelated to these updates.
2. The delay on boot of a newly degraded array is too long and provides no output to the console. Most sysadmins (including myself on the first boot!) would give up waiting long before the degraded array message is displayed and would simply hit the reset button. A 'spinner' or message indicating the reason for the delay would be helpful to show that the server hasn't simply hung.
3. Conversely, the delay at the degraded array prompt is too small. After waiting the 3 minutes for the message to actually appear it seems the delay on the actual message before passing through to the default option is too small. I simply missed it on a couple of occassions as I did other stuff while waiting for the 3 minutes to expire.

Other than that, it all looks good to me. Thanks to Dustin for his work in this area, it's appreciated.