Quote:
I don't know, that was the whole point of asking if it was possible and if so how !


I had some unrelated issues on another system here at home which brought this thread back to mind. You were asking about different boot scenarios and how the BIOS will handle them. Without going into the details of my issues here, let me say that I think there is no way to deal with every possible contingency to ensure the system boots properly.

Here are a couple situations I am quite confident will prevent your system from booting despite all the efforts to make everything redundant:
1) Drive spins up and identifies itself to the BIOS but is not functional, or at least not really functional enough to boot from
2) Drive is the master (or is on a SCSI bus) and is malfunctioning to the point of making the channel/bus unuseable. I had this happen where one drive (the second on the bus) went bonkers (not even a real crash), and prevented the other two drives from [effectively] communicating with the controller. And when this happened, half of the boot attempts hung without even giving a "non-system disk" error.
3) Any other type of failure that allows the BIOS to see the presence of the disk, but disk is not accessible.

All of those will likely give you one of those "non-system disk or disk error" messages on boot up. The best failure scenario is where the drive is completely dead or non readable by the BIOS, in which case it most likely will move onto the next device. As I understand it, since drives became auto-detectable by the BIOS years ago, this mechanism actually works by storing the parameters in a sector on the disk, and the BIOS reads that. So if the drive really fails to spin up, the BIOS can't possibly identify it.

It occurred to me that one possible way of testing how your BIOS reacts to this type of scenario where the device exists, has power, but is "not spinning up" is to test something similar but different. If you had two drives on different IDE channels, you could deliberately misconfigure the first to be a slave instead of master on its channel, or something of that nature. If that doesn't work, maybe there is something else along those lines you could do to essentially accomplish the same thing. Then you would see what the BIOS does in that circumstance, i.e. move onto the next drive or just choke.

Just some thoughts I wanted to pass along.

BTW, for those interested, I continue to be more and more a fan of this software RAID approach using a generic Linux distro. I was enamored first by the hardware RAID, then by the specialty NAS OS (with software RAID) approaches, for different reasons. I thought it nice to have a good customized NAS GUI with slick performance graphs and so forth, but in the end none of those options stacked up to just good ol Linux. Far more robust and resilient than anything else I have experimented with. Alas, I have to do some of the customization work and configuration, but in the end I have what I need and it works like I want it to.