воскресенье, 19 июня 2016 г.

Установка и настройка Open vSwitch в Debian

В прошлой заметке я создал виртуальную машину с AltLinux, которая работает под управлением Xen. Там сетевой интерфейс виртуальной машины соединяется мостом с интерфейсом хост-машины (или вернее - домена-0).

Такой способ настройки может оказаться не безопасным, если на интерфейсе имеется несколько VLAN, часть которых не должны быть доступны внутри виртуальной машины. В качестве примеров можно привести случай предоставления Xen-хостинга или попытку отделить друг от друга виртуальные машины, работающие в локальной сети и в интернете. Например, через VLAN 2 может быть доступна локальная сеть, а через VLAN 3 - сеть интернет. При том способе настройки, который был описан в прошлой статье, хозяин виртуальной машины, которая должна работать только в локальной сети, может настроить внутри виртуалки VLAN-интерфейс для доступа в интернет, прослушать трафик, попытаться подобрать свободный IP-адрес и получить таким образом доступ в интернет. Или другой пример - злоумышленник может получить доступ к виртуальной машине, доступной из сети интернет, настроить VLAN-интерфейс и продолжить взлом уже внутри локальной сети.

Чтобы ограничить передаваемые в виртуальную машину VLAN, рассмотрим использование виртуального коммутатора Open vSwitch.

1. Установка Open vSwitch

Для установки виртуального коммутатора, нужно установить в систему всего-лишь один пакет:
# apt-get install openvswitch-switch
2. Настройка виртуального коммутатора средствами Debian

В составе пакета имеются скрипты для настройки коммутатора привычными для Debian средствами, через файл /etc/network/interfaces. Почитать о настройке можно в файле /usr/share/doc/openvswitch-switch/README.Debian.gz, открыв его, например, при помощи zless, или в статье Boot integration of the Openvswitch in Ubuntu. Благодаря Open vSwitch, я смог избавиться от интерфейсов vlan и br, настроенных стандартными средствами Linux, и заменил их на функционально эквивалентные им интерфейсы Open vSwitch:
auto ovs0
allow-ovs ovs0
iface ovs0 inet manual
  ovs_type OVSBridge
  ovs_ports eth0 ovs0-vlan2 ovs0-vlan3 ovs0-vlan4

allow-ovs0 eth0
iface eth0 inet manual
  ovs_type OVSPort
  ovs_bridge ovs0
  ovs_options vlan_mode=native-untagged tag=2 trunks=2,3,4

allow-ovs0 ovs0-vlan2
iface ovs0-vlan2 inet static
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=2
  address 169.254.254.1
  netmask 255.255.255.0
  
allow-ovs0 ovs0-vlan3
iface ovs0-vlan3 inet dhcp
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=3

allow-ovs0 ovs0-vlan4
iface ovs0-vlan4 inet static
  ovs_bridge ovs0
  ovs_type OVSIntPort
  ovs_options tag=4
  address 0.0.0.0
  netmask 255.255.255.0
Интерфейс ovs0 соответствует созданию одного виртуального коммутатора. При необходимости их можно создать несколько. В этот коммутатор подключается порт eth0, по которому могут передаваться тегированные пакеты для VLAN 3 и 4, а не тегированный трафик помечается как принадлежащий VLAN 2. Следующие три интерфейса соответствуют этим трём VLAN'ам.

Если через интерфейсы, принадлежащие Open vSwitch, устанавливаются другие подключения, вроде pppoe или pptp, то эти интерфейсы можно упомянуть в опции ovs_ports после используемого им интерфейса. Далее останется только удалить опцию auto и добавить вместо неё опцию allow-ovs0 для того, чтобы поднятие этого интерфейса происходило уже по команде от демона Open vSwitch. Интерфейсы поднимаются демоном в том порядке, в котором они указаны в опции ovs_ports.

3. Ручная настройка виртуального коммутатора

Для ручной настройки всего этого хозяйства сгодились бы следующие команды:
# ovs-vsctl add-br ovs0
# ovs-vsctl add-port ovs0 eth0
# ovs-vsctl set port eth0 vlan_mode=native-untagged tag=2 trunks=2,3,4
# ovs-vsctl add-port ovs0 ovs0-vlan2 tag=2 -- set Interface ovs0-vlan2 type=internal
# ifconfig ovs0-vlan2 inet 169.254.254.1/24 up
# ovs-vsctl add-port ovs0 ovs0-vlan3 tag=3 -- set Interface ovs0-vlan3 type=internal
# dhclient ovs0-vlan3
# ovs-vsctl add-port ovs0 ovs0-vlan4 tag=4 -- set Interface ovs0-vlan4 type=internal
# ifconfig ovs0-vlan4 up
Чтобы удалить порт из коммутатора, можно воспользоваться такой командой:
# ovs-vsctl del-port ovs0-vlan2
Чтобы удалить сам коммутатор, можно воспользоваться такой командой:
# ovs-vsctl del-br ovs0
Посмотреть на текущие настройки виртуального коммутатора можно командой, которая уже была продемонстрирована выше:
# ova-vsctl show
Стоит также отметить, что имена коммутаторов и портов могут быть совершенно произвольными. Названия ovs0 и ovs0-vlan2 и т.п. были даны лишь для наглядности. При этом, название интерфейса eth0 соответствует реальному интерфейсу, который нужно подключить к порту виртуального коммутатора, поэтому он фигурирует под своим настоящим именем.

Описанное выше - лишь очень малая часть того, что умеет этот виртуальный коммутатор. Он поддерживает агрегацию портов, обнаружение петель, зеркалирование портов, сбор статистики о трафике на NetFlow-коллектор и многие другие вещи. Поддерживается даже специальный протокол OpenFlow, предназначенный для централизованного управления такими коммутаторами. Я же тут ограничился самыми простыми вещами, которые мне понадобились лишь для того, чтобы передать вовнутрь виртуальной машины под управлением Xen строго определённые VLAN.

Сама коммутация пакетов происходит на уровне ядра, что обеспечивает максимальную производительность, но поддерживается и коммутация в пользовательском пространстве. В таком случае из-за частых переключений между режимами ядра и пользователя производительность должна оказаться уже не столь высокой.

Вот так, например, можно убедиться в том, что по крайней мере некоторая часть openvswitch работает в пространстве ядра:
# lsmod | grep vs
openvswitch            63932  0 
gre                    12777  1 openvswitch
vxlan                  35053  1 openvswitch
libcrc32c              12426  1 openvswitch
5. Виртуальный коммутатор и Xen

Для того, чтобы включить в виртуальный коммутатор интерфейс виртуальной машины, работающей под управлением Xen, можно воспользоваться соответствующими настройками в файле конфигурации виртуальной машины. Например, вот фрагмент файла конфигурации /etc/xen/inet.cfg виртуальной машины inet:
vif = ['script=vif-openvswitch,bridge=ovs0.2']
Таким образом виртуальная машина будет включена в нетегированный порт коммутатора в VLAN 2.

Чтобы передать в виртуальную машину VLAN'ы 3 и 4 в тегированном режиме, можно воспользоваться следующим способом настройки:
vif = ['script=vif-openvswitch,bridge=ovs0:3:4']
О других возможностях настройки сети в виртуальных машинах Xen можно почитать здесь: Xen Networking

P.S. 25 июня 2016. Внесён ряд правок, связанных с автоматическим восстановлением настроек при перезагрузке.

воскресенье, 12 июня 2016 г.

Запуск AltLinux как domU в Xen

При помощи утилиты xen-create-image можно легко создавать виртуальные машины с любой операционной системой, поддержка которой присутствует в каталоге /usr/share/xen-tools/. Заинтересовал вопрос, как же можно создать виртуальную машину не из списка поддерживаемых? В качестве предмета для экспериментов я выбрал AltLinux. Статья делится на две части: подготовка образа для многократного дальнейшего использования и создание из этого образа одной виртуальной машины.

Сразу предупреждаю, что тут я в хвост и в гриву пользуюсь LVM. Во-первых, это удобно. Во-вторых, ну не зря же я мучился? У кого нет LVM, выпутывайтесь сами ;-P

1. Подготовка образа для последующего использования

Скачиваем один из образов из каталога http://ftp.altlinux.org/pub/distributions/ALTLinux/p7/images/starterkits/

Например, я взял altlinux-p7-vm-net-20160312-x86_64.img.xz:
$ cd /home/stupin
$ wget http://ftp.altlinux.org/pub/distributions/ALTLinux/p7/images/starterkits/altlinux-p7-vm-net-20160312-x86_64.img.xz
Распакуем его:
$ cd /home/stupin
$ 7z x altlinux-p7-vm-net-20160312-x86_64.img.xz
Получится файл с именем altlinux-p7-vm-net-20160312-x86_64.img размером 504 мегабайт.

Посмотрим при помощи утилиты file, что представляет собой этот файл:
# file /home/stupin/altlinux-p7-vm-net-20160312-x86_64.img
/home/stupin/altlinux-p7-vm-net-20160312-x86_64.img: DOS/MBR boot sector, LInux i386 boot LOader; partition 1 : ID=0x83, start-CHS (0x0,32,33), end-CHS (0x40,63,63), startsector 2048, 1030144 sectors

Это образ диска с таблицей разделов в стиле DOS.

Создадим логический том такого же размера, что и образ и скопируем в него этот файл посекторно:
# lvcreate -n image -L 528482304b stupin
# cd /home/stupin
# dd if=altlinux-p7-vm-net-20160312-x86_64.img of=/dev/mapper/stupin-image
Если при помощи fdisk посмотреть таблицу разделов в образе, то можно ещё раз убедиться в том, что в образе имеется таблица разделов DOS:
# fdisk -l /dev/mapper/stupin-image

Disk /dev/mapper/stupin-image: 504 MiB, 528482304 bytes, 1032192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xd6c97625

Device                    Boot Start     End Sectors  Size Id Type
/dev/mapper/stupin-image1       2048 1032191 1030144  503M 83 Linux
Смонтируем файловую систему из первого раздела в каталог /mnt/root:
# partprobe
# mount /dev/mapper/stupin-image1 /mnt/root
Исправим файл etc/inittab, убрав оттуда две консоли и создав вместо них консоль, которая будет доступна из dom0:
1:2345:respawn:/sbin/mingetty hvc0
#1:2345:respawn:/sbin/mingetty --noclear tty1
#2:2345:respawn:/sbin/mingetty tty2
Также я отредактировал файл etc/fstab, прописав монтирование корневой файловой системы по имени устройства вместо монтирования по идентификатору:
/dev/xvda     /                       ext4    relatime                        1 1
#UUID=5b7c2d58-0afa-4bf4-9a42-542935636a05 / ext4 relatime 1 1
Чтобы в дальнейшем меньше пришлось вписывать в файл конфигурации виртуальной машины, создадим файл конфигурации для загрузчика pygrub. Для этого создадим каталог boot/grub:
# cd /mnt/root/boot
# mkdir grub
Внутри каталога создадим файл menu.lst со следующим содержимым:
default         0
timeout         2

title           AltLinux p7 x86_64
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/xvda ipv6.disable=1 ro
initrd          /boot/initrd.img

title           AltLinux p7 x86_64 (Single-User)
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/xvda ipv6.disable=1 ro single
initrd          /boot/initrd.img
Поменяем пароль по умолчанию у пользователя root:
# chroot /mnt/root
# passwd
# exit
Теперь создадим архив для последующего разворачивания новых виртуальных машин:
# cd /mnt/root
# tar cjvf /home/stupin/altlinux-p7-vm-net-20160312-x86_64.tbz *
Наконец, раздел можно отмонтировать и уничтожить:
# umount /mnt/root
# dd if=/dev/zero of=/dev/mapper/stupin-image
# partprobe
# lvremove /dev/mapper/stupin-image
2. Создание виртуальной машины

Создадим LVM-раздел для размещения корневого раздела будущей виртуальной машины:
# lvcreate -n inet-root -L 20G stupin
Создадим файловую систему:
# mkfs.ext4 /dev/stupin/inet-root
Смонтируем файловую систему:
# mount /dev/stupin/inet-root /mnt/inet/
И распакуем в неё подготовленный архив с системой:
# cd /mnt/inet/
# tar xjvf /home/stupin/altlinux-p7-vm-net-20160312-x86_64.tbz
Размонтируем корневую файловую систему будущей виртуальной машины:
# cd /
# umount /mnt/inet
Теперь создадим файл конфигурации виртуальной машины /etc/xen/inet.cfg:
bootloader = '/usr/lib/xen-4.4/bin/pygrub'
#kernel = '/boot/vmlinuz'
#ramdisk = '/boot/initrd.img'

name = 'inet'

vcpus = 1
memory = 1024

#root = '/dev/xvda ro'
disk = ['phy:/dev/stupin/inet-root,ioemu:xvda,w']
vif = ['script=vif-bridge,bridge=xenbr0']

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
on_xend_start = 'ignore'
on_xend_stop = 'ignore'
Параметры kernel, ramdisk и root закомментированы, потому что внутри образа имеется файл /boot/grub/menu.lst, в котором прописано, в каком файле лежит образ ядра и образ минимального корневого диска, а также прописаны все параметры, передаваемые загрузчиком ядру. В том числе прописан параметр, настраивающий имя устройства, содержащей корневую файловую систему.

воскресенье, 5 июня 2016 г.

Перенос системы с mdadm RAID1 на mdadm RAID1+LVM

Ранее я уже писал о том, как перевести установленную на диск систему на два диска, объединённые в программный массив RAID1: Перевод работающей системы Debian на RAID 1. На этот раз я задумался о том, чтобы переделать DOS-разделы диска в логические тома LVM. LVM может пригодиться для размещения виртуальных машин под управлением Xen, для более безболезненного переноса системы на другие физические диски, для изменения размеров разделов, их создания и уничтожения.

Стратегия перехода была такая:
  1. Исключаем из настроенного RAID-массива один из дисков, так что у нас появляется один свободный диск и один деградировавший RAID-массив,
  2. Создаём деградировавший RAID-массив на освободившемся диске, выполняем разбивку, переносим на него данные,
  3. Выполняем загрузку системы с флешки, синхронизируем накопившиеся изменения, настраиваем загрузку системы с нового диска,
  4. Грузим систему с нового диска, удаляем старый RAID-массив, разбиваем его аналогично новому, включаем в новый RAID-массив в качестве второй половинки.
В комментариях к прошлой статье о переходе на RAID1 мне писали, что статья не годится, т.к. кто-то сломал систему и теперь не может её загрузить. Сам я по той статье переводил три системы и с проблемами не сталкивался. Насчёт этой статьи хочу сразу предупредить, что здесь нет готового на 100% работающего рецепта. Мне самому пришлось изрядно помучиться на этапе загрузки системы с флешки и последующей загрузки новой системы, т.к. нужно хорошо разбираться в нюансах ручной сборки RAID-массивов, определения LVM-томов, генерации файлов конфигурации загрузчика GRUB, создания загрузочных образов системы initramfs и работы с режимом восстановления на загрузочной флешке. Для этого этапа я лишь приведу несколько команд, которые наверняка пригодятся вам, если вы всё-таки решите попробовать проделать то же самое.

Приступим.

1. Извлечение одного из дисков из RAID-массива

Посмотрим на разделы одного из двух дисков:
# fdisk -l /dev/sda 

Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x9a7a0fdb

Device     Boot     Start        End    Sectors   Size Id Type
/dev/sda1            2048    1977979    1975932 964,8M fd Linux raid autodetect
/dev/sda2         1978368   41064512   39086145  18,7G fd Linux raid autodetect
/dev/sda3  *     41066496   62208035   21141540  10,1G  7 HPFS/NTFS/exFAT
/dev/sda4        62210048 1953525167 1891315120 901,9G  5 Extended
/dev/sda5        62212096  140352192   78140097  37,3G  7 HPFS/NTFS/exFAT
/dev/sda6       140355584 1953525167 1813169584 864,6G fd Linux raid autodetect
Разделы sda1, sda2 и sda6 - это половинки RAID-массивов md1, md2, md6. На md1 расположен раздел подкачки, на md2 - корневой раздел Linux, на md6 - раздел home.

Разделы sda3 и sda5 являются разделами NTFS, на первый из которых когда-то был установлен Windows, а второй использовался для хранения данных для Windows. На разделах sdb3 и sdb5 были расположены посекторные резервные копии этих разделов.

Выведем из RAID-массивов диск /dev/sda:
# mdadm --manage /dev/md1 --fail /dev/sda1
# mdadm --manage /dev/md2 --fail /dev/sda2
# mdadm --manage /dev/md6 --fail /dev/sda6
2. Новая разбивка диска

Я решил воспользоваться консервативной схемой разбивки, когда GRUB будет находиться вне логических томов LVM, на отдельном разделе. Мне показалось, что так будет проще его починить, если что-то пойдёт не так. Новая схема разделов стала следующей:
# fdisk -l /dev/sda 

Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x382c6e6a

Device     Boot  Start        End    Sectors   Size Id Type
/dev/sda1  *      2048     411647     409600   200M fd Linux raid autodetect
/dev/sda2       411648 1953525167 1953113520 931,3G fd Linux raid autodetect
На созданных разделах я создал деградировавшие массивы RAID1, в которых пока что не хватает второй половинки:
# mdadm --create /dev/md11 -l1 -n2 missing /dev/sda1
# mdadm --create /dev/md12 -l1 -n2 missing /dev/sda2
Создадим файловую систему для будущего раздела /boot, на котором будет находиться загрузчик GRUB:
# mkfs.ext4 /dev/md11
Теперь установим менеджер томов, если он ещё не был установлен:
# apt-get install lvm2
Создадим физический том на разделе:
# pvcreate /dev/md12
Создадим группу томов stupin, в котором будет один физический том /dev/md12:
# vgcreate stupin /dev/md12
Создадим логический том размером 1 гигабайт для раздела подкачки:
# lvcreate -n dom0-swap -L 1G stupin
И разметим его как раздел подкачки:
# mkswap /dev/stupin/dom0-swap
Создадим логический том размером в 20 гигабайт для корневого раздела системы:
# lvcreate -n dom0-root -L 20G stupin
И разметим на нём файловую систему ext4:
# mkfs.ext4 /dev/stupin/dom0-root
Создадим логический том для раздела /home и разметим на нём файловую систему ext4:
# lvcreate -n dom0-home -L 800G stupin
# mkfs.ext4 /dev/stupin/dom0-home
3. Копирование разделов ext4

Для копирования ext4 я решил воспользоваться rsync. Создадим точки монтирования будущих разделов /mnt, /mnt/boot, /mnt/home:
# mkdir /mnt
# mount /dev/stupin/dom0-root /mnt/
# mkdir /mnt/boot
# mount /dev/md11 /mnt/boot/
# mkdir /mnt/home
# mount /dev/stupin/dom0-home /mnt/home/
И выполним первоначальное копирование данных на новые разделы:
# rsync -xavv --delete /home/ /mnt/home/
# rsync -xavv --delete / /mnt/
Этот этап копирования имеет целью уменьшить количество файлов, которые нужно будет скопировать во время загрузки системы с флешки. После загрузки системы с флешки копирование будет повторено с тем чтобы скопировать изменившиеся файлы.

4. Копирование NTFS-разделов

Для копирования NTFS-разделов я решил воспользоваться утилитой dd, хотя мог бы воспользоваться и утилитой ntfsclone. Здесь я изначально копировал диски остановленной системы, поскольку она бывает мне нужна лишь иногда и обычно выключена.

Создадим логические тома LVM с размером точно равным количеству секторов на исходных разделах:
# lvcreate -L 21141540S -n winxp-c-disk stupin
# lvcreate -L 78140097S -n winxp-d-disk stupin
И скопируем на них данные посекторно:
# dd if=/dev/sdb3 of=/dev/stupin/winxp-c-disk
# dd if=/dev/sdb5 of=/dev/stupin/winxp-d-disk
5. Загрузка с флешки

Этот момент - самый сложный и ответственный. По идее, если у вас ничего не получится, вы можете загрузить систему со старого диска, переразбить диск, который планировали использовать под LVM, и включить его обратно в зеркало. На этом неудачный опыт будет завершён и система вернётся в то состояние, в котором она находилась изначально.

Я использовал установочную флешку с Debian Jessie. Загрузившись с флешки нужно выбрать режим восстановления (rescue mode), через её меню определить RAID-массивы и логические тома, смонтировать корневой раздел и раздел /boot и перейти в командную строку в среду, где корнем является корневой раздел восстанавливаемой системы.

Попав в оболочку, для начала домонтируем будущий раздел /home:
# mount /dev/stupin/dom0-home /home
Теперь смонтируем разделы исходной системы для того, чтобы синхронизировать накопившиеся на ней изменения в будущую систему:
# mount /dev/sdb2 /mnt
# mount /dev/sdb6 /mnt/home
Скопируем изменения:
# rsync -xavv --delete /mnt/home/ /home/
# rsync -xavv --delete /mnt /
В прошлой статье я не останавливался подробно на моменте правильного переноса данных, поскольку считал, что статьёй воспользуются хорошо подготовленные пользователи, которые проделают ровно то же самое - синхронизируют изменения, загрузившись с флешки. В этот раз загрузка с флешки - необходимый этап, поэтому я решил чуть подробнее описать и момент переноса данных.

Теперь нужно сделать так, чтобы система загрузилась с нового диска. Сначала посмотрим идентификаторы UUID у имеющихся дисков и разделов:
# blkid
Впишем в файл /etc/fstab раздел подкачки, корневой раздел, разделы /boot и /home, указав их идентификаторы из вывода команды blkid:
# vim /etc/fstab
Обновим список RAID-массивов имеющихся в системе в образе initramfs:
# mdadm --examine --scan > /etc/mdadm/mdadm.conf
# update-initramfs -k all -u
Установим GRUB на новый диск и обновим его конфигурацию:
# grub-install /dev/sda
# update-grub
6. Загрузка новой системы

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

Если в процессе загрузки не появилось меню GRUB, то нужно проверить, что GRUB установлен, а его конфигурация обновлена. Для этого нужно снова загрузиться с флешки в режиме восстановления и убедиться, что grub-install сработал.

Если система не загрузилась и остановилась на этапе выполнения меню GRUB, то возможно дело в том, что GRUB не нашёл образ ядра или образ initramfs. В таком случае в загрузочной флешке нужно убедиться, что отработало обновление файла конфигурации GRUB при помощи команды grub-update.

Если система не загрузилась и перешла в оболочку initramfs, то скорее всего ядро не нашло корневой раздел. Нужно проверить, что корневой раздел определился в системе и имеется в каталоге /dev/stupin/ (stupin - имя логической группы) или в /dev/mapper/. Если он на месте, тогда нужно проверить, что он правильно указан в файле /etc/fstab.

В образе initramfs могут пригодиться следующие команды.

Поиск имеющихся RAID-массивов и обновление конфигурации:
# mdadm --examine --scan > /etc/mdadm/mdadm.conf
Сборка RAID-массивов вручную, после которой массивы должны появиться в каталогах /dev и /dev/md:
# mdadm --assemble /dev/md11
# mdadm --assemble /dev/md12
Определение доступных групп томов и логических томов LVM:
# vgchange -ay
Для редактирования файла /etc/fstab в образе initramfs имеется редактор vi.

После того, как вы убедились, что все RAID-массивы и логические тома определились системой, а в /etc/fstab указаны правильные разделы для монтирования, можно попробовать выйти из оболочки initramfs и продолжить загрузку системы.

В загрузившейся системе нужно повторить проделанные манипуляции, а затем обновить образ initramfs и файл конфигурации GRUB. После этого можно попробовать перезагрузить систему и проверить, грузится ли она автоматически, без ручного вмешательства. Когда система будет грузиться с нового раздела автоматически, можно подсоединить отсоединённый диск и продолжить. Если же вы не смогли добиться устойчивой автоматической загрузки системы, можно переключиться на загрузку со старого диска и вернуть всё обратно.

7. Добавление второй половины в новый RAID-массив

Теперь скопируем разбиение с нового диска на старый:
# sfdisk --dump /dev/sda | sfdisk /dev/sdb
И добавим разделы старого диска в зеркало:
# mdadm --manage /dev/md11 --add /dev/sdb1
# mdadm --manage /dev/md12 --add /dev/sdb2
Не забудьте поставить GRUB на второй диск:
# grub-install /dev/sdb
8. Переименование RAID-массивов

Есть ещё один не обязательный момент. Мне хотелось переименовать RAID-массивы так, чтобы они назывались md1 и md2, а не md11 и md12. Для этого я снова загрузился с флешки, разобрал RAID-массивы и собрал их уже под новыми именами:
# mdadm --stop /dev/md11
# mdadm --stop /dev/md12
# mdadm --assemble --update=name --name=1 /dev/md1 /dev/sda1 /dev/sdb1
# mdadm --assemble --update=name --name=2 /dev/md2 /dev/sda2 /dev/sdb2
Осталось обновить конфигурацию mdadm в initramfs:
# mdadm --examine --scan > /etc/mdadm/mdadm.conf
# update-initramfs -k all -u