Comment 69 for bug 872220

boot_required is simply deduced by interrogating fstab, to find mount points which are 'required' to boot, (ie have a pass value not 0).

The script logs anything (and all) of the strings which it thinks might enable it to identify at boot time, a device which might be subsequently required. Currently, that means the device name and the UUID returned from mdadm when a device given, returns a device either with mdadm --misc --detail <device> or mdadm --misc --explain <device>

If fstab identification only comes up with a /dev/mapper/VolGroup00-LogVol00 device name, which mdadm can't identify as a softraid device, it won't be added to the list of required deviced

In my setup, I don't use lvm, so I've considered it.

My concern is that if 'a disk is really not present', so an array 'is truely degraded', that we should not boot, that effectively means that mdadm is not compatible with remote servers, that use soft raid, on non-essential disks, as an error which could be repaired by a remote opporater, will effectively prevent the server from rebooting. It is that, which I am seeking to avoid.

Clearly changes made to fstab after update-initramfs has been run, won't be included in the boot_required file, but as the alternative, in my production environment is having to uninstall mdadm, this seemed an imperfect improvement.

That said, it would probably be a better course, to include a boot option, boot_degraded=required which would then check the boot_required file. I would also go further to say that if boot_degraded=true, it should ALWAYS boot, even if an array is degraded. It is not acceptable, that currently there is no option to allow the system to boot, regardless of degraded status (of secondary disks).

I do accept that it is wise to default, to not booting, when arrays are degraded. But there must be a configurable option to an alternative. In your example, my suggested change would detect that the sda/sdb array was 'required' and log the uuid for it to boot_required. Booting to sda with that array degraded, would be picked up as in boot_required, and fall to an initramfs shell. It is just not a valid assumption that any degraded array, will cause data loss. If an operator knows it won't they should be able to configure that.