ОНОВЛЕННЯ: Я переконався, що опис нижче також працює для Ubuntu 16.04. Інші користувачі повідомили, що працюють 17.10 та 18.04.1.
ПРИМІТКА: Цей спосіб не дасть вам НВМ. Якщо ви також хочете LVM, спробуйте встановити на робочий стіл Ubuntu 18.04 з RAID 1 та LVM на комп'ютері з UEFI BIOS .
Після днів спроб у мене зараз працює робоча система! Якщо коротко, рішення складалося з наступних етапів:
- Завантажте за допомогою Ubuntu Live CD / USB.
- Розділіть SSD, якщо потрібно.
- Встановіть відсутні пакети (mdadm та grub-efi).
- Створіть розділи RAID.
- Запустіть інсталятор Ubiquity (але не завантажуйтесь у нову систему).
- Патч встановленої системи (initramfs), щоб включити завантаження з кореня RAIDed.
- Заселіть розділ EFI першого SSD за допомогою GRUB та встановіть його у ланцюг завантаження EFI.
- Клонувати розділ EFI на інший SSD і встановити його в завантажувальний ланцюжок.
- Готово! Тепер у вашій системі буде надмірність RAID 1. Зауважте, що нічого особливого не потрібно робити, наприклад, наприклад, оновлення ядра, оскільки розділи UEFI недоторкані.
Ключовим компонентом кроку 6 рішення було затримка послідовності завантаження, яка в іншому випадку перекинула мене прямо на підказку GRUB (без клавіатури!), Якщо жоден із SSD-дисків відсутній.
Детально HOWTO
1. Черевик
Завантажте за допомогою EFI з USB-накопичувача. Як саме буде залежати ваша система. Виберіть Спробуйте ubuntu без встановлення .
Запустіть термінальний емулятор, наприклад, xtermзапустити команди нижче.
1.1 Вхід з іншого комп’ютера
Пробуючи це, мені часто було легше увійти з іншого, вже повністю налаштованого комп’ютера. Це спрощене вирізання та вставлення команд тощо. Якщо ви хочете зробити те саме, ви можете увійти через ssh, виконавши наступні дії:
На комп’ютері, який потрібно налаштувати, встановіть сервер opensh:
sudo apt-get install openssh-server
Змінити пароль. Пароль користувача за замовчуванням ubuntuпорожній. Можливо, ви можете вибрати пароль середньої міцності. Він буде забутий, як тільки ви перезавантажите новий комп'ютер.
passwd
Тепер ви можете увійти до прямої сесії ubuntu з іншого комп’ютера. Наведені нижче інструкції стосуються Linux:
ssh -l ubuntu <your-new-computer>
Якщо ви отримуєте попередження про підозрюваного в нападі на людину, вам потрібно очистити ключі ssh, які використовуються для ідентифікації нового комп'ютера. Це тому, що openssh-serverстворює нові ключі сервера щоразу, коли він встановлений. Команда для використання, як правило, друкується і повинна мати вигляд
ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>
Виконавши цю команду, ви зможете увійти в режим живого сеансу ubuntu.
2. Роздільні диски
Очистіть будь-які старі розділи та блоки завантаження. Увага! Це знищить дані на ваших дисках!
sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb
Створіть нові розділи на найменших дисках: 100M для ESP, 32G для RAID SWAP, решта для кореня 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 on / 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 Live поставляється без двох ключових пакетів; grub-efi та mdadm. Встановіть їх. (Я не на 100% впевнений, що grub-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якщо у вас включена безпечна завантажувальна система. (Див. Коментар Алеча.)
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
Перевірте статус 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
Виберіть щось інше як тип інсталяції та змініть md1p1тип ext4, відформатуйте: так, і точку монтажу /. md0p1Розділ буде автоматично вибрано в якості свопу.
Отримайте чашку кави, поки установка закінчиться.
Важливо: Після завершення встановлення виберіть Продовжити тестування, оскільки система ще не готова до завантаження.
Доповніть пристрої RAID
Приєднайте очікуючі розділи sdb до RAID.
sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3
Переконайтеся, що всі RAID-пристрої в порядку (і необов’язково синхронізування).
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-пристрої все ще синхронізуються, ви можете побачити випадкові попередження, наприклад:
/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-пристрої влаштуються. Без цієї затримки встановлення root може не вдатися через те, що збірка 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 не є RAIDed, тому нам потрібно його клонувати .
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 автоматично генерують список дійсних ESP.)
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 Live.)
Після завантаження ви можете запустити
sudo update-grub
приєднати завантажувач Windows до ланцюга завантаження grub.
Віртуальна машина
Якщо ви хочете спробувати це спершу у віртуальній машині, є деякі застереження: мабуть, NVRAM, що містить інформацію UEFI, запам'ятовується між перезавантаженнями, але не між циклами відключення-перезавантаження. У такому випадку ви можете опинитися на консолі оболонки UEFI. Наступні команди повинні завантажувати вас у вашу машину з /dev/sda1(використовувати FS1:для /dev/sdb1):
FS0:
\EFI\ubuntu\grubx64.efi
Перше рішення у верхній відповіді на завантаження UEFI у virtualbox - Ubuntu 12.04 також може бути корисним.
Імітація відмови диска
Відмова будь-якого пристрою RAID-компонента може бути змодельована за допомогою mdadm. Однак, щоб переконатися, що завантажувальний матеріал пережив збій на диску, мені довелося вимкнути комп'ютер та відключити живлення від диска. Якщо ви це зробите, спочатку переконайтеся, що пристрої md синхронізовані .
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 Live і використовувати
dd if=/dev/zero of=/dev/sdX
щоб витерти диск чистим перед перезавантаженням у реальну систему. Якщо ви просто перевірили надмірність завантаження / RAID у розділі вище, цей крок можна пропустити. Однак ви повинні принаймні виконати кроки 2 та 4 нижче, щоб відновити повне резервування завантаження / RAID для вашої системи.
Відновлення завантажувальної системи RAID + після заміни диска вимагає наступних кроків:
- Розділіть новий диск.
- Додайте розділи до пристроїв md.
- Клоніруйте завантажувальний розділ.
- Додайте запис 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 від здорового диска. (Обережно, можливо, спочатку зробіть дамп-файл у обох ESP, щоб увімкнути відновлення, якщо його справді викрутити.)
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 все ще можуть синхронізуватися)!
Чому сценарій сну?
Було запропоновано співтовариством , що додавання сценарію сну може бути непотрібним і може бути замінено використанням GRUB_CMDLINE_LINUX="rootdelay=30"в /etc/default/grubподальшому sudo update-grub. Ця пропозиція, безумовно, чистіша і працює в сценарії відмови / заміни диска. Однак є застереження ...
Я відключив свій другий SSD і виявив, що з rootdelay=30і т.д. замість сценарію сну:
1) Система завантажується в деградованому режимі без «невдалого» накопичувача.
2) У недеградованому завантаженні (присутні обидва диски) час завантаження скорочується. Затримка помітна лише при відсутності другого диска.
1) і 2) звучали чудово, поки я знову не додав свій другий диск. Під час завантаження масив RAID не вдалося зібрати і залишив мене під initramfsзапитом, не знаючи, що робити. Можливо, вдалося врятувати ситуацію шляхом: завантаження на USB-накопичувач Ubuntu Live, б) встановлення mdadmта в) повторного складання масиву вручну, але ... я десь заплутався. Натомість, коли я повторно запустив цей тест зі сценарієм сну (так, я запустив HOWTO з вершини втретє ...), система зробила завантаження. Масиви були в деградованому режимі, і я міг вручну додати /dev/sdb[23]розділи без додаткової USB-палички. Я не знаю, чому працює сценарій сну, тоді як rootdelayні. Можливо, mdadmзаплутаються два, трохи не синхронізовані компонентні пристрої, але я подумавmdadmбув розроблений для цього. У будь-якому випадку, оскільки сценарій сну працює, я його дотримуюся.
Можна стверджувати, що видалення ідеально здорового пристрою RAID-компонентів, повторне завантаження RAID в деградований режим і потім повторне додавання компонентного пристрою є нереальним сценарієм. Реалістичний сценарій полягає в тому, що один пристрій виходить з ладу і замінюється новим. , залишаючи менше можливостей для mdadmплутанини. Я згоден з цим аргументом. Однак я не знаю, як перевірити, як система переносить апаратні збої, за винятком того, щоб фактично відключити деяке обладнання! І після тестування хочу повернутися до надмірної, робочої системи. (Ну, я міг би приєднати свій другий SSD до іншої машини і проведіть пальцем перед тим, як його знову додати, але це неможливо.)
Підсумовуючи: Наскільки мені відомо, rootdelayрішення є чистим, швидшим, ніж сценарій сну для недеградованих черевиків, і повинен працювати для справжнього сценарію несправності / заміни диска. Однак я не знаю, як реально перевірити це. Отже, поки що я буду дотримуватися сценарію негарного сну.