Problem/Justification
I understand that it may not be possible to do N-mirrored boot pools, but assigning spares would get most of the way there.
Impact
It provides an extra option to minimize the risk of losing the boot pool. I don’t know of any disadvantages, other than that it requires one or more “wasted” drives (but welcome to replication).
User Story
The bad situation:
User is away on holiday/asleep/at work on the ISS/drunk, or otherwise not immediately available.
First drive fails. There are extra drives which could be assigned to the boot pool, but the user is not available to log in and manually assign the new drive.
Second drive fails. Now there is no boot pool. Oops.
Temporary power loss. Now the user can no longer stream Columbo from home until they get back to Earth to fix everything.
The good situation:
User is away on holiday/asleep/at work on the ISS/drunk, or otherwise not immediately available.
First drive fails.
A spare drive is immediately swapped in, likely finishing the mirror in a few seconds.
One downfall (one that is shared with simply having a single mirror of the boot pool) is that if the boot pool doesn’t suffer a failure that causes it to be fully invisible to the motherboard, it is quite common to have to go into the BIOS & actually select the 2nd assumed working boot drive.
Spare boot is less of bulletproofing & more of a time reduction vs re-installing & uploading config for systems that either need high uptime or for users (like myself) that aren’t always as religious about backing up config as they should be.
“Possible” and “exposed through the installer/GUI” are two different things. It can, of course, be done at the CLI, though I expect getting the bootloader installed properly would be a little fiddly. It used to be exposed through the installer, but I understand that’s no longer the case. And it’s never been available through the GUI AFAIK.
But the situation where you’re going to fail two boot devices before you can get skilled hands on the system seems a little fanciful.
I think your situation could be also solved with KVM such is PiKVM or TinyPilot.
This way you can get into BIOS remotely and reassign boot drive to spare one manually and even solve other problems.
…or better yet, IPMI, which your server motherboard should have anyway. But that doesn’t really solve the stated problem[1]–it can adjust the boot order, but it can’t resurrect the failed second drive.
though it highlights another one, in that a boot device failure doesn’t mean the system will automatically roll over to booting from its mirror ↩︎