ОБНОВЛЕНИЕ: Я проверил, что описание ниже также работает на Ubuntu 16.04. Другие пользователи сообщили о работе над 17,10 и 18.04.1.

Примечание: Это ПРАКТИЧЕСКОЕ РУКОВОДСТВО не даст Вам LVM. Если Вы хотите LVM также, попробуйте Установку рабочий стол Ubuntu 18.04 RAID 1 и LVM на машине с BIOS UEFI вместо этого.

После дней попытки у меня теперь есть рабочая система! Короче говоря, решение состояло из следующих шагов:

1. Начальная загрузка с помощью Ubuntu Живой CD/USB.
2. Делит SSD как требуется.
3. Установка недостающие пакеты (mdadm и личинка-efi).
4. Создайте разделы RAID.
5. Запустите установщик Повсеместности (но не загружайтесь в новую систему).
6. Исправьте установленную систему (initramfs) для включения начальной загрузки из корня, на который СОВЕРШАЮТ РЕЙД.
7. Заполните раздел EFI первого SSD с GRUB и установите его в цепочку начальной загрузки EFI.
8. Клонируйте раздел EFI к другому SSD и установите его в цепочку начальной загрузки.
9. Готово! Ваша система будет теперь иметь дублирование RAID 1. Обратите внимание, что ничто особые потребности, которые будут сделаны после, например, обновление ядра, поскольку разделы UEFI являются нетронутыми.

Ключевой компонент шага 6 решения был задержкой последовательности начальной загрузки, которая иначе вывела меня прямо к подсказке GRUB (без клавиатуры!), если любой из SSD отсутствовал.

Подробное ПРАКТИЧЕСКОЕ РУКОВОДСТВО

1. Начальная загрузка

Начальная загрузка с помощью EFI от карты с интерфейсом USB. Точно, как будет варьироваться Вашей системой. Выберите человечность Попытки без установки.

Запустите эмулятор терминала, например. xterm выполнять команды ниже.

1.1 Вход в систему от другого компьютера

При испытании этого я часто находил легче войти в систему от другого, уже полностью настроенный компьютер. Это упрощенное вырезание и вклейка команд, и т.д. Если Вы хотите сделать то же, можно войти в систему через ssh путем выполнения следующего:

На компьютере, который будет настроен, установите openssh сервер:

sudo apt-get install openssh-server

Изменить пароль. Пароль по умолчанию для пользователя ubuntu пробел. Можно, вероятно, выбрать пароль средней силы. Об этом забудут, как только Вы перезагружаете свой новый компьютер.

passwd

Теперь можно войти в человечность живая сессия от другого компьютера. Инструкции ниже для Linux:

ssh -l ubuntu <your-new-computer>

Если Вы получаете предупреждение о подозреваемом man-in-the-middle-attack, необходимо очиститься, ssh ключи раньше определяли новый компьютер. Это вызвано тем, что openssh-server генерирует новые ключи сервера каждый раз, когда это установлено. Команда для использования обычно печатается и должна быть похожей

ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>

После выполнения той команды необходимо смочь войти к человечности в живую сессию.

2. Диски раздела

Очистите любые старые разделы и блоки начальной загрузки. Предупреждение! Это уничтожит данные по Вашим дискам!

sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb

Создайте новые разделы на самом маленьком из Ваших дисков: 100M для ESP, 32G для ПОДКАЧКИ RAID, отдыха для корня RAID. Если Ваш диск sda является самым маленьким, следуйте за Разделом 2.1, иначе Раздел 2.2.

2.1 Создайте таблицы разделов (/dev/sda, меньше),

Сделайте следующие шаги:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sda
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sda
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sda

Скопируйте таблицу разделов в другой диск и повторно создайте уникальные UUID (на самом деле повторно создаст UUID для sda).

sudo sgdisk /dev/sda -R /dev/sdb -G

2.2 Создайте таблицы разделов (/dev/sdb, меньше),

Сделайте следующие шаги:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sdb
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sdb
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sdb

Скопируйте таблицу разделов в другой диск и повторно создайте уникальные UUID (на самом деле повторно создаст UUID для sdb).

sudo sgdisk /dev/sdb -R /dev/sda -G

2.3 Создайте файловую систему FAT32 на/dev/sda

Создайте файловую систему FAT32 для раздела EFI.

sudo mkfs.fat -F 32 /dev/sda1
mkdir /tmp/sda1
sudo mount /dev/sda1 /tmp/sda1
sudo mkdir /tmp/sda1/EFI
sudo umount /dev/sda1

3. Установка недостающие пакеты

Ubuntu Живой CD появляется без двух ключевых пакетов; личинка-efi и mdadm. Установите их. (Я не 100%-я верная личинка-efi, необходим здесь, но поддержать симметрию с ближайшей установкой, ввести его также.)

sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm

Вам, возможно, понадобится grub-efi-amd64-signed вместо grub-efi-amd64 если у Вас есть безопасная включенная начальная загрузка. (См. комментарий Alecz.)

4. Создайте разделы RAID

Создайте устройства RAID в ухудшенном режиме. Устройства будут завершены позже. Создание полного RAID1 действительно иногда давало мне проблемы во время ubiquity установка ниже, не уверенный, почему. (монтируйте/размонтируйте? формат?)

sudo mdadm --create /dev/md0 --bitmap=internal --level=1 --raid-disks=2 /dev/sda2 missing
sudo mdadm --create /dev/md1 --bitmap=internal --level=1 --raid-disks=2 /dev/sda3 missing

Состояние Verify RAID.

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 0/2 pages [0KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Разделите md устройства.

sudo sgdisk -z /dev/md0
sudo sgdisk -z /dev/md1
sudo sgdisk -N 1 -t 1:8200 -c 1:"Linux swap" /dev/md0
sudo sgdisk -N 1 -t 1:8300 -c 1:"Linux filesystem" /dev/md1

5. Запустите установщик

Запустите установщик повсеместности, исключая загрузчик, который перестанет работать так или иначе. (Отметьте: Если Вы зарегистрировались на пути ssh, Вы, вероятно, захотите для выполнения этого на Вас новый компьютер вместо этого.)

sudo ubiquity -b

Выберите Something else в качестве типа установки и измените md1p1 введите к ext4, формат: да, и точка монтирования /. md0p1 раздел будет автоматически выбран как подкачка.

Получите чашку кофе, в то время как установка заканчивается.

Важный: После того, как установка закончилась, выбор Продолжают тестировать, поскольку система еще не является начальной загрузкой, готовой.

Завершите устройства RAID

Присоедините ожидание sdb разделы к RAID.

sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3

Проверьте, что все устройства RAID в порядке (и дополнительно sync'ing).

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sdb3[1] sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (465536/216269952)  finish=17.9min speed=200000K/sec
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sdb2[1] sda2[0]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Процесс ниже может продолжиться во время синхронизации, включая перезагрузки.

6. Настройте установленную систему

Настроенный для включить chroot в систему установки.

sudo -s
mount /dev/md1p1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
cat /etc/resolv.conf >> /mnt/etc/resolv.conf
chroot /mnt

Настройте и установите пакеты.

apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm

Если Вы, которые md устройства все еще sync'ing, можно видеть случайные предупреждения как:

/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

Это нормально и может быть проигнорировано (см. ответ в конце этого вопроса).

nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0

Отключение quick_boot избежит, чтобы записи Diskfilter не были поддерживаемыми ошибками. Отключение quiet_boot имеет персональное предпочтение только.

Измените/etc/mdadm/mdadm.conf для удаления любых ссылок маркировки, т.е. изменения

ARRAY /dev/md/0 metadata=1.2 name=ubuntu:0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 metadata=1.2 name=ubuntu:1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

кому:

ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

Этот шаг может быть ненужным, но я видел, что некоторые страницы предполагают, что схемы именования могут быть нестабильными (name=ubuntu:0/1), и это может мешать превосходному устройству RAID собраться во время начальной загрузки.

Измените строки в /etc/default/grub читать

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Снова, этот шаг может быть ненужным, но я предпочитаю загружаться открытыми глазами...

6.1. Добавьте сценарий сна

(Было предложено сообществом, чтобы этот шаг мог бы быть ненужным и может быть заменен с помощью GRUB_CMDLINE_LINUX="rootdelay=30" в /etc/default/grub. По причинам, объясненным в нижней части этого ПРАКТИЧЕСКОГО РУКОВОДСТВА, я предлагаю придерживаться сценария сна даже при том, что это более ужасно, чем использование rootdelay. Таким образом мы продолжаем нашу обычную программу...),

Создайте сценарий, который будет ожидать устройств RAID для урегулирования. Без этой задержки монтирование корня может перестать работать из-за блока RAID, не заканчиваемого вовремя. Я нашел это твердым путем - проблема не показала вплоть до, я разъединил один из SSD для моделирования отказа диска! Синхронизация, возможно, должна быть скорректирована в зависимости от доступных аппаратных средств, например, замедляет внешние диски USB и т.д.

Введите следующий код в /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile:

#!/bin/sh
echo
echo "sleeping for 30 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 25 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 20 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 15 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 10 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 5 seconds while udevd and mdadm settle down"
sleep 5
echo "done sleeping"

Сделайте исполняемый файл сценария и установите его.

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u

7. Включите начальную загрузку из первого SSD

Теперь система почти готова, только параметры начальной загрузки UEFI должны быть установлены.

mount /dev/sda1 /boot/efi
grub-install --boot-directory=/boot --bootloader-id=Ubuntu --target=x86_64-efi --efi-directory=/boot/efi --recheck
update-grub
umount /dev/sda1

Это установит загрузчик в /boot/efi/EFI/Ubuntu (иначе. EFI/Ubuntu на /dev/sda1) и установите его сначала в цепочке начальной загрузки UEFI на компьютере.

8. Включите начальную загрузку из второго SSD

Мы почти сделаны. На данном этапе мы должны смочь перезагрузить на sda диск. Кроме того, mdadm должен смочь обработать отказ любого sda или sdb диск. Однако на EFI не СОВЕРШАЮТ РЕЙД, таким образом, мы должны клонировать его.

dd if=/dev/sda1 of=/dev/sdb1

В дополнение к установке загрузчика на втором диске это сделает UUID файловой системы FAT32 на sdb1 раздел (как сообщается blkid) соответствие соответствие sda1 и /etc/fstab. (Обратите внимание однако что UUID для /dev/sda1 и /dev/sdb1 разделы будут все еще отличаться - выдерживают сравнение ls -la /dev/disk/by-partuuid | grep sd[ab]1 с blkid /dev/sd[ab]1 после установки для проверки на себя.)

Наконец, мы должны вставить sdb1 раздел в порядок загрузки. (Отметьте: Этот шаг может быть ненужным, в зависимости от Вашего BIOS. Я получил отчеты, что некоторый BIOS автоматически генерирует список допустимого ESPs.)

efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

Я не протестировал его, но, вероятно, необходимо иметь уникальные маркировки (-L) между ESP на sda и sdb.

Это генерирует распечатку текущего порядка загрузки, например.

Timeout: 0 seconds
BootOrder: 0009,0008,0000,0001,0002,000B,0003,0004,0005,0006,0007
Boot0000  Windows Boot Manager
Boot0001  DTO UEFI USB Floppy/CD
Boot0002  DTO UEFI USB Hard Drive
Boot0003* DTO UEFI ATAPI CD-ROM Drive
Boot0004  CD/DVD Drive 
Boot0005  DTO Legacy USB Floppy/CD
Boot0006* Hard Drive
Boot0007* IBA GE Slot 00C8 v1550
Boot0008* Ubuntu
Boot000B  KingstonDT 101 II PMAP
Boot0009* Ubuntu #2

Обратите внимание, что Ubuntu № 2 (sdb) и Ubuntu (sda) являются первыми в порядке загрузки.

Перезагрузка

Теперь мы готовы к перезагрузке.

exit # from chroot
exit # from sudo -s
sudo reboot

Система должна теперь перезагрузить в Ubuntu (Вам, вероятно, придется удалить Ubuntu Живой установочный носитель сначала.)

После начальной загрузки можно работать

sudo update-grub

для присоединения загрузчика Windows к личинке загружают цепочку.

Глюки виртуальной машины

Если Вы хотите испытать это в виртуальной машине сначала, существуют некоторые протесты: По-видимому, NVRAM, который содержит информацию UEFI, помнят между перезагрузками, но не между циклами перезапуска завершения работы. В этом случае можно закончить в консоли UEFI Shell. Следующие команды должны загрузить Вас в Вашу машину от /dev/sda1 (используйте FS1: для /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

Первое решение в главном ответе начальной загрузки UEFI в virtualbox - Ubuntu 12.04 могло бы также быть полезным.

Моделирование отказа диска

Отказ любого устройства компонента RAID может быть моделирован с помощью mdadm. Однако, чтобы проверить, что материал начальной загрузки пережил бы отказ диска, я должен был закрыть компьютер и отключающее питание от диска. Если Вы действительно так, сначала удостоверяетесь, что md устройства являются sync'ed.

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb3[2] sda3[0]
      216269952 blocks super 1.2 [2/2] [UU]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0] sdb2[2]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

В инструкциях ниже, sdX является неисправным устройством (X=a или b), и sdY хорошо устройство.

Разъедините диск

Завершите работу компьютера. Разъедините диск. Перезапуск. Ubuntu должна теперь загрузиться с дисками RAID в ухудшенном режиме. (Празднуйте! Это - то, чего Вы пытались достигнуть!;)

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Восстановитесь с неисправного диска

Это - процесс, чтобы следовать, если необходимо было заменить неисправный диск. Если Вы хотите эмулировать замену, можно загрузить в Ubuntu Живую сессию и использование

dd if=/dev/zero of=/dev/sdX

вытереть диск, чистый прежде, чем повторно перезагрузить в реальную систему. Если Вы просто протестировали дублирование начальной загрузки/RAID в разделе выше, можно пропустить этот шаг. Однако необходимо, по крайней мере, выполнить шаги 2 и 4 ниже для восстановления полной начальной загрузки / дублирование RAID для системы.

При восстановлении системы RAID+boot после того, как замена дисков требует следующих шагов:

1. Разделите новый диск.
2. Добавьте разделы к md устройствам.
3. Клонируйте раздел начальной загрузки.
4. Добавьте запись EFI для клона.

1. Разделите новый диск

Скопируйте таблицу разделов со здорового диска:

sudo sgdisk /dev/sdY -R /dev/sdX

Повторно рандомизируйте UUID на новом диске.

sudo sgdisk /dev/sdX -G

2. Добавьте к md устройствам

sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3

3. Клонируйте раздел начальной загрузки

Клонируйте ESP от здорового диска. (Осторожный, возможно, сделайте дамп в файл обоих ESPs сначала для включения восстановления при реальном завинчивании его.)

sudo dd if=/dev/sdY1 of=/dev/sdX1

4. Вставьте недавно восстановленный диск в порядок загрузки

Добавьте запись EFI для клона. Измените маркировку-L как требуется.

sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

Теперь, перезагрузка системы должна иметь его назад к нормальному (устройства RAID могут все еще быть sync'ing)!

Почему сценарий сна?

Было предложено сообществом, чтобы добавление сценария сна могло бы быть ненужным и могло быть заменено при помощи GRUB_CMDLINE_LINUX="rootdelay=30" в /etc/default/grub сопровождаемый sudo update-grub. Это предложение является, конечно, инструментом для очистки и действительно работает в отказе диска / сценарий замены. Однако существует протест...

Я разъединил свой второй SSD и узнал это с rootdelay=30, и т.д. вместо сценария сна:
1) Система действительно загружается в ухудшенном режиме без "неудавшегося" диска.
2) В неухудшенной начальной загрузке (оба существующие диска), уменьшается время начальной загрузки. Задержка только заметна со вторыми пропавшими без вести диска.

1) и 2) звучал великолепно, пока я не повторно добавил свой второй диск. При начальной загрузке RAID-массив не удался собраться и оставил меня в initramfs подсказка, не зная, что сделать. Возможно, было возможно спасти ситуацию путем a) начальной загрузки к Ubuntu Живой карты с интерфейсом USB, b) установки mdadm и c), повторно собирающий массив вручную, но... Я испортил где-нибудь. Вместо этого когда я повторно выполнил этот тест со сценарием сна (да, я действительно запускал ПРАКТИЧЕСКОЕ РУКОВОДСТВО с вершины в течение энного времени...), система действительно загружалась. Массивы были в ухудшенном режиме, и я мог вручную повторно добавить /dev/sdb[23] разделы без любой дополнительной карты с интерфейсом USB. Я не знаю, почему сценарий сна работает тогда как rootdelay не делает. Возможно, mdadm запутывается два, немного несинхронизированные устройства компонента, но я думал mdadm был разработан для обработки этого. Так или иначе, начиная с работ сценария сна, я придерживаюсь его.

Можно было утверждать, что удаление совершенно здорового устройства компонента RAID, перезагрузка RAID к ухудшенному режиму и затем передобавление устройства компонента являются нереалистичным сценарием: реалистический сценарий скорее, который одно устройство приводит к сбою и заменяется новым, оставляя меньше возможности для mdadm запутаться. Я соглашаюсь с тем аргументом. Однако я не знаю, как протестировать, как система терпит отказ оборудования кроме на самом деле отключить некоторые аппаратные средства! И после тестирования, я хочу возвратиться к избыточной, рабочей системе. (Ну, я мог подключить свой второй SSD к другой машине и сильно ударить его, прежде чем я повторно добавлю его, но это не выполнимо.)

Таким образом: К моему знанию, rootdelay решение является чистым, быстрее, чем сценарий сна для неухудшенных начальных загрузок, и должно работать на реальный сбой диска / сценарий замены. Однако я не знаю выполнимый способ протестировать его. Так, в настоящее время я буду придерживаться ужасного сценария сна.