У меня были такие ситуации в прошлом: файловая система могла быть предоставлена на другом физическом оборудовании, но только одно из этих блочных устройств могло быть подключено одновременно. Что касается ОС, «какую бы вы ни нашли, смонтируйте ее как / source (или что-то еще)».
Затем сегодня я настраивал сборку AWS EC2 и увидел аналогичную проблему: AWS не может гарантировать, что том будет отображаться как блочное устройство, и их обходной путь - жестко запрограммировать UUID блочного устройства. Это нормально до тех пор, пока вам не понадобится сборка, которая с радостью принимает что-либо в (например) «/ dev / sdc» и работает с тем, что ей дано (управление подключенными томами через консоль AWS).
Это заставило меня задуматься ... как лучше всего делать запасные части, например:
Моя первая мысль заключалась в том, чтобы расположить их в обратном порядке приоритета и просто продолжать устанавливать каждый поверх предыдущего. Если когда-либо будет подключено только одно из устройств, «неудачные» крепления не будут иметь никакого эффекта.
Я думаю, что это работает, за исключением того, что это не оставляет вам никакой обработки ошибок, когда НИ ОДИН из них не успешен.