Запущенный ранее виртуальный аплайнс Avaya Meetings (Equinox) Management Server 9.1 может функционировать в формате Hyper-V Gen1, так как на его виртуальном диске используется таблица разделов MBR и загрузчик Legacy BIOS. Если мы хотим улучшить конфигурацию ВМ до уровня Hyper-V Gen2, то нам потребуется выполнить процедуры преобразования таблицы разделов на диске в формат GPT и подготовки гостевой ОС Red Hat Enterprise Linux (RHEL) к использованию UEFI загрузчика. В этой заметке мы рассмотрим данные процедуры на примере "родственного" аплайнса Avaya Meetings (Equinox) Media Server 9.1 на базе ОС RHEL 7.6.
Судя по документу "Red Hat Knowledgebase : Is it possible to switch the BIOS boot to UEFI boot on preinstalled Red Hat Enterprise Linux machine?" задача перехода от Legacy BIOS к UEFI для предустановленной системы RHEL относится к разряду "миссия невыполнима":
* The answer is No, it's not possible.
* The BIOS boot doesn't contain /boot/efi partition with efi filesystem in it, and the Red Hat Enterprise Linux bootloader is installed on first sector MBR whereas in UEFI, this partition exists and grub in installed on first sector of /boot partition, so lots of filesystem changes which can't be achieved to match once the system is installed.
* It's required to have a clean reinstall to make it UEFI boot.
Однако наш предыдущий опыт и статья "Enable Sysadmin : Move your Linux from legacy BIOS to UEFI in place with minimal downtime" говорят об обратном.
Рассматриваемая далее процедура будет состоять из следующих этапов:
1) Расширение виртуального диска ВМ под новый раздел UEFI
2) Создание ВМ Hyper-V Gen2 и загрузка в RHEL Rescue Mode
3) Конвертация таблицы разделов диска из MBR в GPT
4) Создание раздела под EFI System Partition
5) Подготовка гостевой ОС RHEL 7.6 под EFI загрузчик
Этап 1. Расширение виртуального диска под новый раздел UEFI
Для начала изучим текущую конфигурацию диска с предустановленной гостевой ОС. Нужно понять то, где будет размещён выделенный раздел с файловой системой FAT, который потребуется для хранения загрузочного микрокода UEFI. Сначала оценим вообще все блочные устройства, которые есть в системе. Затем проверим объём и текущее состояние раздела, который отвечает за загрузку
# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
# df -h /boot
Как видим, в нашем случае раздел sda1, который используется у нас под монтирование /boot, имеет скромный размер и поэтому "откусить" от этого раздела нужное нам место под новый раздел UEFI - не самая лучшая идея.
Посмотрим, какова ситуация со свободным неразмеченным местом на всём диске:
# parted /dev/sda print free
В нашем примере практически вся ёмкость диска уже занята используемыми разделами. Но так как у нас виртуальная машина, нам никто не мешает увеличить размер виртуального диска VHDX.
Выключаем ВМ и средствами Hyper-V расширяем диск, например, на 1GB (хотя в под раздел UEFI нам достаточно ~300MB).
Снова включаем ВМ и проверяем ситуацию со свободным местом повторно
Как видим, теперь в конце диска у нас появилось свободное место, достаточное для того, чтобы создать раздел под UEFI.
Этап 2. Создание ВМ Hyper-V Gen2 и загрузка в RHEL Rescue Mode
Выключаем исходную ВМ Hyper-V Gen1, затем создаём новую ВМ формата Hyper-V Gen2 и подключаем к ней копию виртуального диска от исходной ВМ. В свойствах новой ВМ не забываем отключить Secure Boot.
Все последующие манипуляции с гостевой системой мы будем выполнять в offline-режиме, загрузив ВМ с образа инсталляционного диска RHEL 7.6.
Вкладываем в привод новой ВМ Gen2 ISO-образ, меняем порядок загрузки ВМ на загрузку с привода и включаем ВМ. В меню загрузки инсталляционного диска выбираем пункт Troubleshooting
В меню Troubleshooting выберем пункт Rescue a Red Hat Enterprise Linux system.
В меню Rescue выберем пункт "1", чтобы система, расположенная на диске виртуальной машины, была смонтирована в каталог /mnt/sysimage.
Запустится режим Rescue Mount и мы получим приглашение командной строки.
Этап 3. Конвертация таблицы разделов диска из MBR в GPT
Находясь в режиме Rescue Mode, с помощью утилиты gdisk выполняем конвертацию таблицы разделов диска из MBR в GPT
# gdisk /dev/sda
Войдя в интерактивный режим работы утилиты gdisk вызовем опцию восстановления и трансформации с помощью клавиши "r".
Выберем клавишу "f" для построения GPT таблицы разделов из имеющейся MBR таблицы. После этого нам будет задан вопрос о том, действительно ли мы хотим удалить текущую таблицу разделов (MBR). Утвердительно вводим "y".
Сразу после этого вводим "w", чтобы произвести запись новой таблицы разделов (в формате GPT) на диск и утвердительно отвечаем на последующий вопрос "y".
После успешного обновления таблицы разделов на диске утилита gdisk завершит свою работу.
Этап 4. Создание раздела под EFI System Partition
Снова вызовем утилиту gdisk, чтобы создать новый раздел под загрузчик EFI в ранее добавленном свободном месте в конце диска.
# gdisk /dev/sda
Обратим внимание на то, что теперь утилита отображает информацию о том, что на нашем диске используется таблица разделов GPT, а из перечня ключевых клавиш нам нужно выбрать "n" для создания нового раздела.
На последующий запрос о вводе номера раздела, выбираем предлагаемый по умолчанию номер (в нашем случае это "4").
Следующие два запроса будут определять номер начального и конечного сектора диска для создаваемого раздела. Для того, чтобы использовать всё ранее добавленное нами дисковое пространство, достаточно согласиться с предлагаемыми по умолчанию значениями номеров секторов и просто два раза нажать Enter. В нашем случае под новый раздел достаточно использовать ~300MB, поэтому при указании конечного сектора укажем "+300M".
На следующий запрос о выборе типа раздела укажем значение "ef00".
Записываем отредактированную нами таблицу разделов диска с помощью ключевой клавиши "w" и утвердительно отвечаем на вопрос о перезаписи существующей таблицы разделов – "y".
В результате успешного обновления таблицы разделов утилита завершит свою работу.
Заставим систему перечитать информацию о разделах, чтобы увидеть вновь созданный раздел sda4:
# partprobe
Следующим шагом нужно отформатировать только что созданный ESP-раздел в файловую систему FAT32.
С помощью lsblk ещё раз проверим имя раздела, который нужно отформатировать и выполним его форматирование.
# lsblk /dev/sda
# mkfs.vfat /dev/sda4
На данном этапе мы имеем сконвертированную в формат GPT таблицу разделов диска и у нас появился специальный выделенный раздел под загрузчик EFI. Однако, этот раздел пока пуст и в самой гостевой Linux системе нет упоминаний об этом разделе.
Этап 5. Подготовка гостевой RHEL 7 под EFI загрузчик
Нам потребуется создать chroot–окружение и выполнить реконфигурацию загрузчика ОС, так как в нашей RHEL нет необходимых файлов для EFI-загрузки. Этот этап будет состоять из следующей последовательности шагов:
1) Переход в chroot-окружение
2) Монтирование EFI раздела
3) Подключение репозиториев для yum
4) Переустановка пакетов GRUB
5) Генерация файла grub.cfg
6) Корректировка файла fstab
Шаг 1. Переход в chroot-окружение
Для перехода в chroot окружение выполняем последовательность команд:
# mount --bind /proc /mnt/sysimage/proc
# mount --bind /dev /mnt/sysimage/dev
# mount --bind /sys /mnt/sysimage/sys
# mount --bind /run /mnt/sysimage/run
# chroot /mnt/sysimage
Шаг 2. Монтирование EFI раздела
Смонтируем в нашем chroot-окружении ранее созданный EFI-раздел c файловой системой FAT (sda4) в каталог /boot/efi (обратите внимание на то, что если в вашем случае на исходной системе каталог /boot размещается на отдельном дисковом разделе, то перед монтированием /boot/efi сначала нужно будет отдельно смонтировать соответствующий раздел диска в /boot).
# mount /dev/sda4 /boot/efi
Разумеется, после такого монтирования этот каталог будет пустой. Но в нём должна быть структура файлов, относящихся к EFI-загрузке, в том числе интересующие нас файлы типа grubx64.efi для стандартной загрузки UEFI (shimx64.efi для загрузки UEFI с поддержкой Secure Boot).
Шаг 3. Подключение репозиториев для yum
Нужно доустановить в систему пакеты, которые будут полезны для работы с UEFI. После установки этих пакетов в системе должны появиться файлы EFI-загрузки в /boot/efi.
Чтобы провести установку, можно настроить в системе сеть и установить нужные пакеты из онлайн-репозиториев. Но мы поступим немного проще. Напомню, что в приводе ВМ у нас ISO дистрибутива RHEL 7.6. Его мы и добавим в качестве репозитория в наше chroot-окружение.
# mkdir -p /mnt/iso
# mount /dev/sr0 /mnt/iso
# cp /mnt/iso/media.repo /etc/yum.repos.d/rhel7dvd.repo
# chmod 644 /etc/yum.repos.d/rhel7dvd.repo
# echo "enabled=1" >> /etc/yum.repos.d/rhel7dvd.repo
# echo "baseurl=file:///mnt/iso/" >> /etc/yum.repos.d/rhel7dvd.repo
# yum clean all
Шаг 4. Переустановка пакетов GRUB
После того, как репозиторий подключен, мы можем произвести замену пакетов загрузчика GRUB.
Суть процедуры в том, чтобы заменить базовый пакет (и его зависимые пакеты) grub2-pc на пакет grub2-efi. Однако оба этих пакета используют ряд других зависимых пакетов, например grub2-tools-*, которые могут отличаться по версиям на нашем инсталляционном диске RHEL и в гостевой системе. Поэтому, чтобы избежать проблем неразрешённых зависимостей пакетов, мы удалим из гостевой системы все ранее установленные пакеты и заново установим их с инсталляционного диска.
Удаляем все ранее установленные в гостевой ОС пакеты grub2 связанные с Legacy BIOS, типа grub2-pc, grub2-pc-modules и другие:
# yum remove grub2*
Затем устанавливаем пакеты GRUB для работы с EFI-загрузкой и утилиты, которые могут пригодиться в дальнейшем:
# yum install grub2-efi grub2-efi-modules grub2-tools-efi shim efibootmgr tree
Проверим, что получилось:
# yum list installed | grep grub
Снова проверим содержимое каталога /boot/efi и теперь мы должны в нём увидеть структуру efi-файлов
# tree /boot/efi
Как видим, необходимый в нашем случае файл grubx64.efi на месте.
Переустанавливаем загрузчик GRUB:
# grub2-install --efi-directory=/boot/efi --target=x86_64-efi --bootloader-id=redhat /dev/sda
При выполнении последней команды мы не должны получить никаких ошибок и предупреждений, так как мы фактически выполняем её на системе, загруженной в UEFI-окружении (ВМ Hyper-V Gen2). Если подобную команду выполнять в Legacy BIOS окружении (ВМ Hyper-V Gen1), то могут появиться предупреждения типа "EFI variables are not supported on this system".
Данная команда фактически вызовет утилиту efibootmgr с опциями регистрации новой записи в UEFI-загрузчик. Пример работы с загрузочными записями UEFI с помощью efibootmgr мы рассматривали ранее.
Чтобы посмотреть то, как изменилась таблица загрузочных записей UEFI в нашей виртуальной системе, можем выполнить команду:
# efibootmgr -v
Также можем заглянуть в свойства нашего виртуального сервера в оснастке управления Hyper-V и увидим, что появилась информация о загрузчике UEFI:
Шаг 5. Генерация файла grub.cfg
С помощью утилиты grub2-mkconfig нам нужно сгенерировать файл grub.cfg, в котором будет размещаться информация о том, какие в системе должны использоваться загрузочные образы initramfs (собственно то, что потом будет отображаться в загрузочном меню GRUB). Теоретически, должно быть достаточно наличия файла grub.cfg в каталоге /boot/efi/EFI/redhat, но есть мнение, что дополнительно можно продублировать файл также в каталог /boot/grub2.
# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
# grub2-mkconfig -o /boot/grub2/grub.cfg
После генерации файлов, убедимся в том, что они появились в указанных нами местах в подкаталогах каталога /boot :
# tree -h /boot -P *.cfg
Опять же обращаю внимание на то, что выполнять команду grub2-mkconfig мы должны именно в UEFI окружении (ВМ Hyper-V Gen2), чтобы результирующий файл grub.cfg имел корректный формат. Если же выполнять команду в Legacy BIOS окружении (ВМ Hyper-V Gen1), то в результирующий файл grub.cfg в записи загрузочного меню GRUB попадут переменные типа linux16/initrd16 (вместо необходимых типа linuxefi/initrdefi), что в последующем приведёт к ошибкам загрузки ОС с сообщениями типа "error: cant find command linux16".
Достаточно заглянуть в файл и убедиться в том, что в нём используются корректные переменные GRUB для описания корневого раздела Linux и образа initramfs:
Шаг 6. Корректировка файла fstab
В качестве заключительного шаг нам нужно внести правку в файл /etc/fstab гостевой системы, добавив туда директиву для монтирования загрузочного раздела EFI. Но для этого нам понадобиться узнать идентификатор UUID этого раздела. Так как раздел EFI уже смонтирован в нашей системе, мы можем выяснить идентификатор UUID ESP-раздела командой вида:
# ls -lh /dev/disk/by-uuid
Как видим, в нашем случае ESP-раздел /dev/sda4 имеет идентификатор UUID равный "95A0-D41C"
Откроем в нашем chroot-окружении на редактирование принадлежащий гостевой системе конфигурационный фaйл fstab ...
# nano /etc/fstab
... добавим в конец файла запись о необходимости монтирования EFI раздела, указав соответствующий идентификатор UUID этого раздела. В нашем случае строка монтирования раздела будет выглядеть так:
UUID=95A0-D41C /boot/efi vfat umask=0077 0 1
На данном этапе можно считать, что в гостевой системе RHEL у нас всё готово для того, чтобы она могла запускаться с EFI-загрузчика. Выходим из chroot-окружения и выключаем ВМ.
# exit
# poweroff
В свойствах ВМ извлекаем инсталляционный ISO образ RHEL и меняем порядок загрузки на загрузку с диска. Включаем ВМ и проверяем результат. Система должна успешно загрузиться c EFI-раздела
В заключении стоит отметить, что описанная процедура справедлива не только для аплайнсов Avaya Meetings (Equinox) Media Server 9.1 и Management Server 9.1 , но и для любой другой предустановленной системы на базе RHEL 7.6.
RSS - Записи
Добавить комментарий