Что такое Launch efi shell from filesystem device?
Обычно данный пункт настроек BIOS можно встретить на материнских платах, поддерживающих загрузку в UEFI (EFI) режиме. Почти всегда он находится на вкладке Exit (Safe & Exit).
Пункт “launch efi shell from filesystem device” на платах Asus
В этой статье мы более подробно поговорим о EFI/UEFI , а также о том, что же все таки позволяет делать пункт меню “Launch efi shell from filesystem device”.
Отличия BIOS и UEFI
BIOS является базовой системой ввода/вывода, которая запускается еще до загрузки операционной системы. Те, кто имеет хоть какой – то опыт в настройке компьютеров прекрасно знает как он выглядит:
Внешний вид настроек BIOS
UEFI, что расшифровывается как Unified Extensible Firmware Interface, является следующим этапом развития базовых управляющих интерфейсов материнских плат. У него, по сравнению с BIOS, есть ряд преимуществ:
- Ускоренная загрузка за счет отсутствия необходимости поиска загрузчика на всех дисках;
- Возможность использование жестких дисков более 2ТБ;
- Более простая подготовка загрузочных носителей;
- Наличие собственного менеджера загрузки;
- Повышенный уровень безопасности загрузки;
- Более удобный графический режим конфигурирования компьютера с поддержкой и мыши.
Что делает пункт Launch efi shell from filesystem device?
Перевод данной фразы на русский язык звучит так: запуск EFI оболочки с файловой системы внешнего устройства. Под внешним устройством следует понимать флешку, CD/DVD диск, жесткий диск и т.д.
Штатные BIOS/UEFI материнской платы всегда располагаются на отдельной микросхеме памяти, находящейся недалеко от батарейки.
Иногда появляется необходимость в запуске сторонней оболочки EFI, например для установки операционной системы Linux. Для этого создается загрузочная флешка, на которую помещаются не только установочные файлы, но и сам EFI загрузчик.
Вставив эту флешку в USB порт и выбрав пункт Launch efi shell from filesystem device в биосе, осуществляется ее запуск.
Вот так выглядит запущенная оболочка EFI Shell
Лучшая благодарность автору — репост к себе на страничку:
BootDev
Представим ситуацию, что по какой то причине, вместо обычной загрузки операционной системы, перед вами появилась командная строка UEFI Shell, с сообщением «Press ESC in 1 in seconds to skip staurtup.nsh or any other key to continue». Что делать?
Возможные Причины
Загрузка в UEFI происходит согласно загрузочным записям. Если в BIOS данные записи представляли просто список имеющихся жестких дисков, то UEFI в данном плане действует по другой схеме. По умолчанию UEFI определяет все диски с таблицей разделов MBR и GPT, с последующим поиском на них разделов отформатированных в поддерживаемую файловую систему. Таковой является FAT(12, 16, 32). Данные диски попадают в загрузочный список. Приоритет загрузки данного списка можно конфигурировать через интерфейс UEFI, или с помощью командной оболочки UEFI Shell.
Каждая загрузочная запись может указывать либо просто на диск, в котором содержится соответствующий FAT-раздел, либо на конкретный *.efi файл. В первом случае UEFI будет искать загрузочный файл по умолчанию. Таковыми, к примеру, являются /EFI/boot/bootx64.efi, /EFI/boot/bootia32.efi, /EFI/boot/bootarm.efi или /EFI/boot/bootaa64.efi. В данном случае указаны файлы boot*.efi предназначены для разных архитектур ПК.
Исполняемые файлы boot*.efi выполняют запуск основного загрузчика операционной системы, таких как Windows Boot Manager, GRUB2, rEFInd, Clover, Xorboot и других. Загрузчик в свою очередь, уже выполняет запуск ядра операционной системы.
Учитывая все сказанное, можно сделать вывод. Раз перед нами красуется UEFI Shell, то значит подсистеме UEFI по какой то причине не удалось найти необходимый загрузочный *.efi файл. Он может быть поврежденным, или просто отсутствовать. Или как говорилось немного выше, может быть просто изменен приоритет загрузочных записей. И последний вариант, просто отсутствует необходимая загрузочная запись.
UEFI Shell — это инструмент управления загрузкой вручную. Если вы не инициировали запуск данной командной оболочки, то это означает, что нужно проверить загрузочную конфигурацию. И не обязательно делать это именно через командную строку. Сперва разбираемся с конфигурацией в меню UEFI. И если результатов нет, то переходим к следующему разделу.
Что Делать в UEFI Shell
Оказавшись в UEFI Shell, первым делом необходимо будет, на удивление, настроить цвета консоли и ее размер. Делается это для того, чтобы избавиться от нечитаемого синего текста на черном фоне. Изменение размера консоли, позволит отображать больше информации. Подправить внешний вид помогут команды cls и mode .
После настройки внешнего вида, необходимо будет просмотреть информацию о загрузочных записях. Эта информация позволит определить, какие загрузочные EFI-приложения должны грузиться, в какой последовательности, и на каких разделах они должны располагаться. Команда bcfg .
Последний шаг, это проверка вручную возможность загрузки с указанного EFI-приложения или диска.
Важным нюансом данного шага, является то, что необходимое EFI-приложение может присутствовать. Но может отсутствовать приложение которое запускается этим приложением. Или оно может быть повреждено.
К примеру, приложение /EFI/Boot/bootx64.efi, указанное в загрузочной записи, запускает /EFI/Microsoft/Boot/bootmgfw.efi, которое запускает приложение выполняющее запуск операционной системы с другого раздела /Windows/System32/Boot/winload.efi.
Если же загрузочная запись указывает просто на диск, то при загрузке с такой записи, на указанном накопителе будет производиться поиск загрузочного EFI-раздела, и в случае его нахождения, поиск на нем загрузочного EFI-приложения по умолчанию (/efi/boot/boot*.efi).
Для такой записи необходимо проверить наличие на диске EFI-раздела, и EFI-приложения расположенного в папке /EFI/boot/. В этом помогут команды map , cd и dir .
Вводим Команды
Все последующие операции будут производиться на виртуальной машине VirtualBox. На виртуальный диск которой, установлено две операционные системы, Windows 10 и Ubuntu 18.10. В качестве основного загрузчика используется GRUB2. Загрузчик Windows Boot Manager, так же присутствует, но не используется.
Не лишним будет, перед началом работы с UEFI Shell, ознакомиться с описанием данной командной оболочки, доступным по этой ссылке https://www.bootdev.ru/2018/05/EFI-Shell.html.
Настройка Консоли
Зададим параметры цвета фона и текста оболочки UEFI Shell. Оптимальными для читабельности, на мой взгляд, являются цвета — серый для фона, и черный для текста.
cls 7 0
Доступные варианты цветов можно посмотреть в справке по команде.
cls -? -b
Размер консоли задается командой mode . Сперва вводим данную команду без каких либо аргументов, чтобы определить доступные разрешения консоли.
А уже после, с указанием нужного разрешения.
mode 128 40
Вывод Загрузочных Записей
Любую проблему загрузки, нужно начинать с анализа загрузочных записей. Выведем список текущих записей.
bcfg boot dump
Текущая загрузочная конфигурация состоит из трех записей.
Запись 0 — загрузка с дисковода.
Запись 1 — загрузка с жесткого диска.
Запись 2 — загрузка встроенной командной оболочки UEFI Shell.
Из присутствующих записей, только одна может осуществлять загрузку операционной системы, это запись под номером 1 (по факту вторая). Запоминаем номер диска и его тип из параметра DevPath.
Если имеются проблемы с загрузкой операционной системы, то необходимо проверить, наличие указанного диска, и присутствие на нем EFI-радела и EFI-приложения.
Проверка Наличия EFI-раздела
Все распознанные дисковые (или блочные) устройства можно просмотреть командой map .
Вывод команды, представляет список точек монтирования FS x : и BLK x :, где x это номер.
Точки монтирования начинающиеся с префикса FS (File System), указывают на разделы или диски (в данном случае имеются в виду CD-диски) файловую систему которых подсистема UEFI смогла определить. То есть, с таким разделом/диском можно полноценно работать. Чтение, редактирование, создание, копирование, удаление, перемещение файлов и каталогов.
Точки монтирования начинающиеся с префикса BLK, это разделы или диски (в этом случае, подразумеваются любые диски), файловая система которых неизвестна UEFI. Или это точка монтирования многотомного диска, то есть она указывает на сам диск, а не на его разделы. Каждый раздел этого диска так же будет иметь свою точку монтирования.
Для понимания, ниже, на снимке экрана, отмечены все точки монтирования указывающие на диски (то есть доступ к данным начинается с первого сектора диска).
Все что не отмечено, это разделы отмеченных дисков.
Исключением из правила, что точки монтирования BLK не определяются, так же возможны. А возможны они если к примеру есть точка монтирования FS и BLK указывающие на один и тот же раздел/диск. Ниже, на снимке, отмечены таковые.
Теперь собственно ответ на вопрос, какой из указанных разделов или дисков может являться для подсистемы UEFI загрузочным, то есть может быть EFI-разделом. Таким может быть любая FSx: точка монтирования. Здесь логика проста, если UEFI может прочитать содержимое указанной точки монтирования, то значит возможен поиск загрузчика по умолчанию (тот что располагается в папке /efi/boot/).
В предыдущем разделе, при просмотре загрузочных записей, мы выяснили что загрузочным диском является диск Sata(0x0, 0x0, 0x0). К данному диску относятся следующие записи, отмеченные на снимке ниже.
Понятной в плане файлового доступа, на уровне UEFI, является лишь запись — FS0:. Эта точка монтирования в данном случае, является загрузочным EFI-разделом (по крайней мере для подсистемы UEFI).
Что было бы, если доступных разделов было бы больше одного. При условии что загрузочная запись указывает на диск в целом. В этом случае, загрузка проходила бы в порядке очереди следования разделов. До момента, пока не будет обнаружено *.efi приложение запускаемое по умолчанию. Нам, в этом случае, пришлось бы проверять каждый на наличие соответствующих загрузочных файлов.
Проверка Наличия EFI-приложения
Определившись с разделом, который может выступать в качестве загрузочного, необходимо проверить наличие на нем соответствующих загрузочных файлов. Из прошлого раздела, мы выяснили, что в качестве такого может выступать раздел смонтированный под меткой FS0.
Для удобства восприятия, далее по тексту, метки точек монтирования, я буду называть дисками. По аналогии с дисками операционной системы Windows, буква после которой идет знак двоеточия. UEFI Shell в этом плане, как раз копирует, по своим повадкам в большей степени, именно командную оболочку Windows CMD.
Выполним переход на диск FS0.
Приглашение ввода команд изменится, и будет отображать текущее ваше местоположение в файловой системе. На данный момент это корень диска FS0. Просмотрим его содержимое.
В корне диска, присутствует только каталог EFI. Перейдем в данный каталог и посмотрим что в нем находится.
cd EFI ls
Внутри каталога EFI находится три подкаталога Boot, Microsoft и ubuntu. Каталог Boot является в данном случае загрузочным по умолчанию. В нем располагаются загрузочные приложения boot*.efi, которые запускаются подсистемой UEFI автоматически. Просмотрим содержимое данного каталога.
ls Boot
Вывод команды показывает, что в каталоге Boot содержится три файла, один из которых bootx64.efi. Данный файл запускается подсистемой UEFI автоматически. Хочу обратить ваше внимание на цвета данных файлов, в выводе команды ls, они зеленые. Это говорит о том, что данные файлы являются исполняемыми, и их можно запустить вручную.
Если сейчас выполнить запуск файла bootx64.efi, то загрузится загрузчик GRUB2.
Boot\bootx64.efi
Каталоги Microsoft и ubuntu, содержат файлы загрузчиков Windows Boot Manager и GRUB2 соответственно.
ls ubuntu ls Microsoft
Для каталога Microsoft, основные файлы загрузчика располагаются в подкаталоге Boot.
ls Microsoft\Boot -b
Основной загрузчик на данный момент GRUB2. Это означает, что файл /EFI/Boot/bootx64.efi как то использует содержимое каталога /EFI/ubuntu/. Будь то запуск исполняемого файла, либо чтение файла конфигурации. Взглянем внимательно содержимое папок /EFI/Boot/ и /EFI/ubuntu/.
Обратите внимание на файлы shimx64.efi и bootx64.efi, а точнее на их размер. Думаю вы догадались, что данные файлы идентичны. А это означает что, файлу bootx64.efi нет смысла запускать свою копию. Остается два варианта, либо это файл grubx64.efi, что более очевидно исходя из имени файла, либо mmx64.efi. Запустим файл mmx64.efi, чтобы убедиться что это не то приложение.
ubuntu\mmx64.efi
Ожидания подтвердились, открылся явно не загрузчик GRUB2.
Подведем промежуточный итог. Файл /EFI/Boot/bootx64.efi на само деле является файлом /EFI/ubuntu/shimx64.efi. Приложение /EFI/Boot/bootx64.efi при запуске, вызывает другое приложение, а именно /EFI/ubuntu/grubx64.efi. В последнем можно убедиться, просто переименовав файл /EFI/ubuntu/grubx64.efi, с последующей попыткой загрузки с данного диска.
Что полезного можно извлечь из этой информации? Самое важное, это то, что папка /EFI/ubuntu/ содержит полный набор файлов. Если вдруг по какой либо причине, оригинальный файл /EFI/Boot/bootx64.efi будет удален или поврежден, то его можно будет лего восстановить, простым копированием файла /EFI/ubuntu/shimx64.efi с последующим переименованием в bootx64.efi.
Такое поведение, характерно и для директории /EFI/Microsoft/Boot/. В ней так же содержится все необходимое. Роль файла /EFI/Boot/bootx64.efi будет исполнять /EFI/Microsoft/Boot/bootmgfw.efi. Который в свою очередь будет запускать файл /EFI/Microsoft/Boot/bootmgr.efi. То есть, выполнив такую подмену, вместо загрузчика GRUB2 будет запускаться Windows Boot Manager. Попробуем провести такую подмену.
# переименование текущего bootx64.efi mv Boot\bootx64.efi Boot\bootx64.efi_ # копирование файла bootmgfw.efi в bootx64.efi cp Microsoft\Boot\bootmgfw.efi Boot\bootx64.efi # просмотр полученного результата ls Boot
Windows Boot Manager успешно запустился, и загрузил операционную систему Windows 10.
Чтобы вернуть на место загрузчик GRUB2, достаточно просто удалить (или переименовать) текущий файл /EFI/Boot/bootx64.efi, и переименовать /EFI/Boot/bootx64.efi_ к своему прежнему имени bootx64.efi.
# переходим в каталог Boot cd Boot # смотрим список файлов ls # удаляем текущий файл bootx64.efi (стартер загрузчика Windows) rm bootx64.efi # переименовываем обратно, то есть возвращаем на место файл загруpчика GRUB2 mv bootx64.efi_ bootx64.efi # смотрим что получилось ls
Добавление Загрузочных Записей
При обычных условиях, в моем примере с виртуальной машиной, происходит загрузка исполняемого файла по умолчанию /EFI/Boot/bootx64.efi. Этому способствует загрузочная запись указывающая на диск в целом.
bcfg boot dump
В прошлой главе, для того чтобы вернуть вместо загрузчика GRUB2 загрузчик Windows Boot Manager, приходилось производить файловые манипуляции. Переименование и подмена файла bootx64.efi. Точно такого же результата можно добиться просто добавив загрузочную запись, указывающей на нужный исполняемый файл необходимого загрузчика. Добавим ее.
# добавляем загрузочную запись в позицию 0, то есть на первое место bcfg boot add 0 \EFI\Microsoft\Boot\bootmgfw.efi "Start Windows 10" # смотрим текущую загрузочную конфигурацию bcfg boot dump
Посмотрим на загрузочное меню, после добавление новой записи.
Аналогичным образом можно добавить запуск любой исполняемой программы *.efi. Теперь попробуем переместить добавленную запись. Или иначе говоря, изменить приоритет загрузки. Передвинем нашу запись на третье место.
# установка для записи 0 нового порядкового номера 2 bcfg boot mv 0 2 # вывод загрузочной конфигурации bcfg boot dump
Взглянем на загрузочное меню.
И последнее что осталось сделать, это удалить добавленную запись.
# удаление записи под номером 2 bcfg boot rm 2 # вывод загрузочной конфигурации bcfg boot dump
Смотрим загрузочное меню.
Загрузочная запись полностью удалена.
Важным нюансом является нумерация. Учтите что она начинается с нуля. То есть если речь идет о третей записи по списку, ее номер будет 2.
Итог
В данном материале были затронуты следующие вопросы: Что делать если вместо операционной системы загрузилась UEFI Shell? Как работать с UEFI Shell? Как работать с файлами в UEFI Shell? Как восстановить, вернуть прежний загрузчик через UEFI Shell? Как определить загрузочный EFI-раздел? Как работать с загрузочными записями через UEFI Shell? Как добавить загрузочную запись UEFI Shell? Как изменить приоритет загрузочной записи через UEFI Shell? Как удалить загрузочную запись в UEFI Shell? Как выполнить запуск приложений EFI? Как загрузить операционную систему через UEFI Shell?
Думаю это не последняя статья на тему UEFI Shell. В следующих, мы поговорим о загрузке драйверов в UEFI Shell. И установке дополнительного загрузчика через UEFI Shell.
P.S. Некоторые цветовые схемы которые могу вам приглянуться cls 3 11, cls 7 0, cls 5 15 .
Launch EFI Shell from filesystem device что это в биосе? (плюс перевод на русский)
Ребята, сегодня у нас будет материал, который посвящен загадочному пункту Launch EFI Shell from filesystem device, его можно встретить в биосе. И если вы сюда попали, то вы наверно его таки встретили и теперь гадаете что он означает, я прав? Так что приготовьтесь, будем разбираться
Начал ребята в общем я гуглить.. И таки нагуглил! Значит ребята немного сложновато. Короче получается что Launch EFI Shell from filesystem device это пункт для запуска оболочки UEFI. Эта оболочка, или как она еще называется UEFI Shell, то это типа внешняя программная оболочка, которая может быть загружена из корневого каталога диска.. Сложновато реально.
Так, вот еще читаю, что Launch EFI Shell from filesystem device это загрузка оболочки UEFI с носителя, вероятно что и флешка подходит для этого дела. И эта оболочка нужна для выполнения некоторых функций, например настройка чего-то, установка операционной системы, воспроизведение CD/DVD дисков, и все это без загрузки операционки! То есть оболочка является типа программой, но которая работает без операционки, ну короче как-то так, но интересно блин.
Вот еще узнал, что пункт Launch EFI Shell from filesystem device может быть даже на ноуте, например он есть на модели Asus N73S и находится в меню Exit. Но может быть спрятан и в разделе Advanced options, как понимаю это зависит от модели.
Вот еще нашел инфу о том что такое UEFI Shell, это среда работы с окружением EFI, которая позволяет на ходу запускать efi-загрузчики и выполнять всякие примитивные функции (уже писал какие именно).
Ну и теперь ребята давайте уже наконец-то переведем название Launch EFI Shell from filesystem device на русский язык, не против? Пошел я кароч в гугловский переводчик, вставил туда название:
Ну и вот какой перевод:
Я думаю что комментарии излишни
Я ребята нашел также картинки, как этот пункт выглядит, ну так на заметку вам. Смотрите, вот первый вариант:
Второй вариант (не знал что пункт может быть и в биосе старого формата):
Ну и третий вариант (это биос игровой материнки):
В принципе хоть немного, но понятно, да? Я понял только то, что этот пункт чисто для тех, кто в теме так бы сказать. Для меня это все темный лес…
На этом все господа, искренно надеюсь что информация вам была полезной, ну хоть немного. Удачи вам и здоровья!
Заметки по ходу дела
Время летит быстро и вот уже на повсюду на прилавках магазинов маячат 2ТБ накопители. И всё бы шло своим чередом в плане увеличения ёмкости, ставь более вместительный HDD да ставь, вот только при установке накопителя в 2.5ТБ пользователь уже сталкивается с проблемой — ограничение 2,2ТБ на раздел. В этом случае надо уже использовать GPT таблицу разделов. И тут мы, пользователи линуксов подходим к другому ограничению — загрузчик grub не понимает таблицу разделов GPT. grub2 понимает, а вот grub в своё время этому не научили. Казалось бы, современные дистрибутивы уже вполне таки обзаводятся grub2. Новые дистрибутивы да, обзаводятся. Но не надо забывать и о серверных дистрибутивах, в которых основная задача как раз поддержка системы с учётом неизменности мажорных версий ПО. Что же делать в этом случае? Нам поможет загрузка с помощью EFI BIOS!
Я давно уже хотел выяснить что же из себя представляет технология загрузки операционной системы из EFI BIOS. Технология разрабатывается давно, но понятной информации, представленной в виде последовательности шагов по переходу с обычной загрузки операционной системы при использовании “MBR” записи на накопителе на загрузку с использованием EFI BIOS я почему то не нашёл. Эта статья и призвана заполнить образовавшийся пробел.
Итак, нам требуется материнская плата с EFI BIOS, в целом скорее всего это будет любая материнская плата способная работать с Sandy Bridge архитектурой процессоров. Наверняка материнские платы с EFI BIOS есть и от компании AMD, мне они не знакомы. В любом случае есть ли поддержка подобного BIOS или такая поддержка отсутствует можно выяснить на сайте производителя конкретной материнской платы. Я приобрёл материнскую плату от ASUS P8Q77-M. Дальнейшая работа будет вестись с этой платой.
Новый накопитель, на который требуется перенести систему. Для себя я выбрал Seagate ST2000DM001. На него и будем переносить систему. Многие возразят, ведь данный накопитель ниже обозначенного предела в 2.2ТБ и в этом случае можно обойтись без загрузки с помощью EFI BIOS, разместив загрузчик в MBR. Что тут скажешь — это конечно же так. Вот только следующий порог ёмкости накопителя находится уже в районе 2.5ТБ и уж с ним точно возникнут сложности. Я решил не откладывать решение этого вопроса на потом, когда у меня появится накопитель бОльшей ёмкости, а попробовать разобраться во всём сейчас.
И наконец установленная в данный момент система CentOS 6.3, которую и надо перенести на новый накопитель.
- Система включается, запускаются POST тесты
- Загружается EFI BIOS
- В EFI BIOS находится собственный менеджер загрузки, с помощью которого выясняется какие EFI приложения должны запуститься и откуда (например указан диск, раздел)
- Менеджер загрузки запускает EFI приложения с раздела отформатированного под файловую систему FAT (HFS/HFS+ для Apple-Intel Mac). Этот раздел зовётся EFI System Partition (ESP)
- EFI приложения могут запускать другие приложения
Исходя из этой информации можно понять что для загрузки операционной системы нам требуется указать менеджеру загрузки который находится в EFI BIOS требуемый диск на котором находится наше EFI приложение.
- Переменные с информацией о путях загрузки EFI приложений можно указать с помощью так называемого UEFI Shell. Скачиваем его по ссылкам, вскоре он нам понадобится. Указанная оболочка достаточно мощное средство работы с EFI BIOS, нам же требуется только указание пути к EFI приложению.
x86_64 UEFI Shell 2.0 (Beta)
i386 UEFI Shell 2.0 (Beta) - EFI приложение поставляется вместе с CentOS 6 (RHEL 6) и находится в директории “/boot/efi/EFI/redhat/”. В этой директории находится только один файл — grub.efi
Если диск который будет установлен размечается на разделы в отдельной операционной системе, эти файлы лучше сразу скопировать куда нибудь на переносной носитель. Если же новый диск подключен к системе которая будет переноситься, просто запоминаем местонахождение скачанного файла EFI Shell и EFI файла приложения от Red Hat.
Разметка нового диска
Размечать новый диск будем программой parted, поскольку fdisk и не может работать с GPT таблицами разделов. Перед разметкой желательно уточнить тип физического сектора который имеет диск — 512Б или 4КБ. Это можно выяснить запустив программу parted с указанием нового диска. Как можно видеть из вывода parted, модель диска которую я приобрёл имеет 4КБ сектор взамен стандартного 512Б. А это значит что для избежания просадки в скорости работы требуется ровнять создаваемые разделы по границе в 1МБ.
Для разметки в этом случае к программе parted применяется ключ “-a optimal” и первый раздел начинается не с нуля, а с 1МБ. Обратитесь к статье Выравнивание раздела диска в случае необходимости.
Итак, запускаем parted с указанием нового диска который требует разметки
parted -a optimal /dev/new_disk
Приступаем к созданию новых разделов
(parted) mklabel gpt (parted) unit MB (parted) mkpartfs "EFI System Partition" fat16 1 20 (parted) mkpartfs primary ext2 20 200 (parted) mkpart primary 201 -1 (parted) set 1 boot on (parted) set 3 lvm on (parted) p
- Первый раздел у нас будет так называемый EFI System Partition (ESP). Файловая система на нём должна быть обязательно FAT, разрядность не важна. Можно создать FAT12, FAT16 или FAT32. В последнем случае минимальный раздел у этого типа — 512МБ, что явно избыточно для маленького системного раздела который требуется. FAT16 с минимумом в 20МБ будет вполне достаточно. Именно на этот раздел будут помещены EFI файл оболочки и EFI файл представленный компанией Red Hat.
- Второй раздел требуется для директории /boot. В этой директории находится grub, файлы ядер (kernel) и образов (initrd). Из файловых систем для этой цели лучше всего подходит ext2. Поскольку у grub отсутствует возможность загружаться из LVM раздела нам требуется выделить под него отдельный раздел. Если LVM не планируется, достаточно будет сделать второй раздел корневым и отвести ему всю оставшуюся ёмкость накопителя. В случае использования менеджера логических томов LVM, переходим к созданию заключительного раздела на накопителе.
- Третий раздел отводится под LVM. Под этот раздел отводится вся оставшаяся ёмкость диска.
- Устанавливаем дополнительные флаги разделов: boot и lvm
При просмотре таблицы разделов командой должна появиться приблизительно следующая информация.
Перенос системы на новый накопитель
Монтируем созданный системный раздел в подходящую директорию
$ sudo mount -t vfat /dev/sda1 /mnt
На этот раздел требуется скопировать файл оболочки и EFI файл приложения от Red Hat. Скачанный файл оболочки размещаем под именем Shellx64.efi прямо в корень раздела, а файл приложения который находится в директории “/boot/efi/EFI/redhat/” переносим в созданную директорию “/EFI/redhat/”. В эту же директорию требуется скопировать файл конфигурации grub.conf, который находится в директории “/boot/grub/grub.conf”. Следует учесть, что поскольку нумерация разделов изменилась, требуется отредактировать файл grub.conf на актуальную конфигурацию, замените в этом файле строки с (hd0,0) на (hd0,1).
На этом работу с системным разделом EFI можно считать завершённой. Отключаем системный раздел командой umount и монтируем раздел который у нас будет как /boot.
$ sudo mount /dev/sda2 /mnt
На вновь подключенный раздел копируем всё что находится у нас в директории /boot с диска на котором в данный момент находится система. Если раздел /boot находится у вас на корневом разделе, то копируем и остальные файлы системы. В случае если у вас корневой раздел, /swap, /home и прочие разделы находятся на LVM, переносим LVM на новый диск. Подробнее о том как это сделать можно прочитать в Повести о Linux и LVM Помним о том что требуется изменить файл /etc/fstab, указав в нём местонахождение разделов нового накопителя. При использовании LVM в файле /etc/fstab возможно потребуется изменить только местонахождение корневого раздела.
Запуск EFI Shell
Перезагружаем систему и заходим в EFI BIOS. Нам требуется отыскать надпись «Launch EFI Shell from file system device». Эта надпись может находиться в разделе “Boot Option Menu”, либо при явном выборе меню “Exit”. Подтверждаем выбор и после этого менеджер загрузки начинает искать EFI приложение на подключенных накопителях (HDD, USB Flash и пр.), с последующим запуском найденного приложения.
У вас на экране монитора должно появиться запущенное приложение EFI Shell. Возможно, после подтверждения выбора надписи «Launch EFI Shell from file system device» у вас появится сообщение о том что “FileName.efi not found”, в этом случае файл Shellx64.efi следует переименовать на то имя которое запрашивается.
Итак, EFI Shell запущен, теперь можно приступать к указанию пути к EFI приложению размещённому так же на системном разделе.
Просмотрим информацию о загрузочных записях которые существуют в данный момент
Shell> bcfg boot dump -v
Добавим четвёртую (счёт начинается с нуля) опцию к загрузочному меню. Обратите внимание на то что для указания пути используется обратный слэш.
Shell> bcfg boot add 3 fs0:\EFI\redhat\grub.efi "CentOS"
Если потребуется удалить вновь созданную четвёртую опцию, поможет команда
Shell> bcfg boot rm 3
Для изменения позиции с #4 на #0 поможет команда
Shell> bcfg boot mv 3 0
Последнее можно сделать и из меню EFI BIOS, в разделе приоритетов загрузки.
С дополнительной информацией можно ознакомиться в статье по UEFI
Как видите EFI Shell предоставляются достаточно большие возможности по работе со значениями EFI BIOS находящимися в NVRAM. Выходим из EFI Shell по команде exit, перезагружаем систему и при повторном посещении EFI BIOS мы видим что в разделе приоритетов загрузки (Boot option priorities), помимо выбора подключенных накопителей появилась возможность выбора опции «CentOS (ёмкость накопителя)». После выбора новой опции, требуется изменить дополнительно опции в разделе «CSM» (Compatibility Support Module) — «Launch CSM» — «auto» и в разделе «Secure boot» — «OS Type» — «Other OS». В BIOS разных производителей эти разделы могут именоваться несколько иначе, суть в том чтобы указать загрузку именно EFI приложения с системного раздела, а не MBR запись. В последнем случае у вас на дисплее появится сообщение о том что MBR запись не найдена (что вполне логично, потому что она действительно должна отсутствовать на новом накопителе). Перезагружаем систему и видим запуск знакомого загрузчика grub на новом накопителе!
Финальные штрихи
В целом система готова к использованию, осталась лишь пара деталей. При обновлении ядра системы у нас обновляются также и опции загрузки нового ядра в файле “/boot/grub/grub.conf”, но теперь файл grub.conf находится в директории “/EFI/redhat/” на другом разделе накопителя. Поэтому при очередном обновлении всё равно будет загружено предыдущее ядро, поскольку записи в этом файле не будут обновлены. Чтобы это исправить, примонтируем ESP раздел к директории “/boot/efi” и создадим символьную ссылку на новый файл конфигурации в директории “/boot/grub” (неиспользуемый файл конфигурации в этой директории следует удалить). Будет разумнее сделать монтированием с использованием UUID раздела. Узнать его можно с помощью команды
blkid /dev/partition_name
Добавляем записи в файл /etc/fstab
UUID=b460fc21-d517-4592-9e3e-348b7a88c8f0 /boot ext2 defaults 1 2 UUID=A774-EAC4 /boot/efi vfat rw,umask=077 0 0
Создаём символьную ссылку на файл grub.conf
ln -s /boot/efi/EFI/redhat/grub.conf /boot/grub/grub.conf
Перенос системы завершён, протестируем новый накопитель.