Подсистема UEFI позволяет расширить свой функционал, с помощью загрузки внешних драйверов. Разберем данный вопрос подробнее.
Оригинальный архив доступен по ссылке https://downloadcenter.intel.com/ru/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers.
Ранее говорилось, что тестовая система содержит две файловые системы, которые будут недоступны в подсистеме UEFI, это NTFS и EXT4. Попробуем загрузить драйвера для данных файловых систем.
Итак, UEFI Shell загружен, подключаем флешку с скачанными драйверами и выполняем команду переопределения подключенных дисков.
В выводе команды ищем точку подключения флешки, в дальнейшем будем называть ее диском. В моем случае это диск FS3. Определить флешку можно по типу устройства, он будет USB. Переходим на данный диск и выводим его содержимое.
В корне диска располагается папка Drivers, созданная нами на этапе скачивания драйверов. Переходим в по пути Drivers\FS и смотрим что в нем находится.
В полученном списке файлов, присутствуют следующие, ntfs_x64.efi и ext2_x64.efi. Их мы будем загружать.
Перед загрузкой драйверов файловых систем, просмотрим на разделы которые на данный момент недоступны.
В полученном списке, не составит труда определить необходимые разделы. Это BLK1, BLK3, BLK4, BLK5. На данный момент они не доступны. Доступные для просмотра, то есть понятные системе UEFI, диски имеют префикс FSx.
Первым, загрузим драйвер ntfs_x64.efi. После чего выполним переинициализацию смонтированных дисков.
Разберем, что произошло после выполнения команд указанных выше. Первое, что бросается в глаза, это то, что диски BLK1 и BLK4 получили новые метки FS0 и FS2 соответственно. Это значит, что данные разделы имеют файловую систему NTFS. Проверим содержимое данных дисков.
По содержимому дисков можно соделать вывод, что FS0 это раздел восстановления Windows, а FS2 это раздел с установленной операционной системой Windows.
Еще одним замечанием, является то, что диск FS3 указывающий на флешку, и начал указывать на CD-привод. Флеш накопитель теперь смонтирован под меткой FS5. Произошло это из-за переопределения таблицы монтирования после команды map -r.
Загрузим теперь драйвер ext2_x64.efi, с последующим переопределением смонтированных дисков.
На этот раз, диск BLK5 получил префикс FS3. А флешка теперь находится под меткой FS6. Посмотрим содержимое диска FS3.
Его содержимое говорит о том, что это раздел операционной системы Ubuntu Linux. Что же тогда с разделом BLK3. Он, в данном случае, принадлежит Linux, это SWAP-раздел (раздел подкачки).
На этом драйверы файловых систем загружены. Посмотреть список всех загруженных драйверов в подсистеме UEFI, можно командой drivers.
Все выполненные действия по загрузке драйверов, в предыдущем разделе, актуальны до первой перезагрузки компьютера. После перезагрузки, драйвера придется загружать снова. А что делать если загружаемый драйвер необходим при каждой загрузке? На этот случай, подсистема UEFI располагает возможностью добавлять загрузочные записи для драйверов. Добавим ранее загружаемые драйвера файловых систем в автозагрузку.
Добавляемые в автозагрузку драйвера, необходимо разместить на системном EFI-разделе в любую угодную вам директорию. В моем случае, я использовал папку /EFI/Boot. На данный момент виртуальный ПК, был перезагружен, поэтому метки дисков вернулись в свое первоначальное состояние. FS0 - системный EFI-раздел, FS3 - флешка с драйверами. Выполним копирование драйверов на системный EFI-раздел.
Драйвера скопированы. Теперь создадим загрузочные записи для скопированных драйверов.
Проверим наличие загрузочных записей после их добавления.
Данные загрузочные записи, будут храниться в подсистеме UEFI, в NVRAM. Сбросить их можно будет, лишь вытащив батарейку из материнской платы компьютера, или удалив.
Удаление загрузочных записей для драйверов, происходит следующим образом:
Номера загрузочных записей, можно посмотреть в выводе предыдущей команды. Замечу, что нумерация их начинается с нуля.
В качестве сетевого адаптера в виртуальной машине VirtualBox, выбрана сетевая карта Intel PRO/1000 MT. Подсистема UEFI, встроенная в VirtualBox, не содержит драйверов под эту сетевую карту. Это весьма странно, конкурент от VMWare этим не грешит, и возможно данные драйвера будут интегрированы в последующих версиях. Выбрана данная сетевая карта, так же из-за того, что в интернете для нее присутствуют UEFI-драйвера. Их легко найти и скачать.
Забегая вперед, скажу, что с виртуальной машиной VirtualBox возникнет проблема. Диагностировать которую, не так уж и просто. Но обо всем по порядку.
Загружаем сетевые драйвера. Так как скачанный пакет EFI-драйверов насчитывает 5 файлов,
и по именам этих файлов не понять, какой из них предназначен для сетевой карты используемой нами, самым простым действием будет загрузка всех пяти, но без подключения. То есть, драйвера загружаются в память, но не запускаются.
После загрузки драйверов в память, посмотрим список всех драйверов подсистемы UEFI.
Из представленного списка, очевидными вариантами для запуска, являются два драйвера - E3522X2.EFI и E8310X3.EFI. Но прежде чем продолжить, давайте разберем вывод команды drivers более подробно.
Вывод команды строиться в виде таблицы, состоящий из девяти столбцов.
1. Дескриптор драйвера. То есть, уникальное число в формате HEX, за которым закреплен драйвер. Это число используется другими командами для выполнения операций над конкретным драйвером.
2. Версия драйвера. Тут все просто, числовое обозначение версии драйвера.
3. Тип Драйвера. Возможные значения - B - драйвер шины, D - драйвер устройства, ? - неизвестный, или не подключенный драйвер.
4. Поддержка конфигурационного протокола. Наличие знака "X", вместо "-", говорит о том что данный драйвер поддерживает возможность конфигурирования.
5. Поддержка диагностического протокола. Наличие знака "X", вместо "-", говорит о том что данный драйвер поддерживает возможность диагностики. То есть способен выдать сведения о своем состоянии.
6. Число устройств обслуживаемых драйвером.
7. Число дочерних устройств работающих под этим драйвером.
8. Имя драйвера.
9. Путь до файла драйвера. Файл драйвера может располагаться как в оперативной памяти, так и жестком диске, или любом другом поддерживаемом накопителе.
И так, продолжим. Выбор пал на драйвера E3522X2.EFI и E8310X3.EFI. Тип данных драйверов имеет знак ?. Все из-за того, что драйвера мы загружали без подключения, и их тип системе UEFI пока неизвестен. Выполним подключение данных драйверов, то есть их запуск. Для этого понадобится использовать их дескрипторы. В моем случае, для драйвера E3522X2.EFI дескриптор равен AE, а для E8310X3.EFI B0.
Снова выведем информацию о драйверах.
По выводу видно, что из двух драйверов, заработал только AE. У него сменился тип с "?" на "B", счетчик устройств обсуживаемых драйвером стал равным 1. Кроме этого, стали активными и встроенные драйвера сетевых протоколов, появилась информация о их типе и счетчике устройств. Драйвер заработал. Проверяем доступные сетевые интерфейсы.
Пустой вывод, или отсутствие вывода, в данном случае, говорит о том, что сетевых интерфейсов нет. Следовательно драйвер не заработал как нужно, вопрос только какой именно драйвер. Как было сказано ранее, при загрузке драйвера сетевой карты, так же были активированы и драйверы протоколов. На данный момент, на отсутствие сети, могут влиять как драйвер сетевой карты так и встроенные драйвера протоколов.
Взглянем на дерево устройств, в нем так же можно найти полезную информацию.
Дерево сетевой карты начинается с дескриптора AD. Этот дескриптор можно использовать с командами connect, reconnect, disconnect. Команда devtree, позволяет выводить отдельную ветку определенного устройства, при передаче в качестве параметра его дескриптора. Выведем отдельно ветку сетевой карты, для отсечения информации о других устройствах.
По ветке сетевого адаптера, видны дескрипторы протоколов, некоторые из них, включая TCPv4, не запущены, то есть имеют маркировку Not Started. Что собственно может служить причиной отсутствия доступных сетевых интерфейсов. Но это не точно.
Попробуем проверить вывод команд drivers и devtree на другой виртуальной машине, а именно VMWare. Подсистема UEFI данной виртуальной машины содержит интегрированные драйвера для используемых ею сетевых адаптеров. То есть сеть в UEFI работает изначально без дополнительных действий.
Запускаем UEFI Shell.
Смотрим список драйверов.
Как было сказано выше, подсистема UEFI, виртуальной машины VMWare, уже содержит необходимые сетевые драйвера. Указанные на снимке сетевые драйвера, судя по их статусу, работают. Проверим наличие сетевых интерфейсов.
Вот так должен выглядеть вывод команды ifconfig, когда с сетевой подсистемой все в порядке. На снимке видно, что сетевому интерфейсу не присвоены сетевые настройки.
Просмотрим теперь дерево устройств. А именно как будет выглядеть ветка сетевого адаптера.
Сетевая карта, в моем случае, имеет дескриптор CD. Выведем отдельно ветку сетевой карты.
Сравните вывод на машине VMWare, с аналогичным в VirtualBox. Основное различие, не запущенный протокол TCP, при использовании VirtualBox.
Раз была затронута тема сравнения, то предлагаю попробовать выгрузить встроенный драйвер сетевого адаптера виртуальной машины VMWare, и загрузить те, что были скачаны нами для использования в VirtualBox.
Просмотрим еще раз список загруженных драйверов, чтобы узнать дескрипторы драйверов сетевых адаптеров.
В системе присутствует два загруженных драйвера для сетевых адаптеров, первый c дескрипторам 81, и второй с дескриптором 82. Из них, в рабочем состоянии драйвер 82. Из описания которого понятно, что это драйвер сетевого адаптера Intel PRO/1000 PCI-E. Выгрузим оба.
Проверим список драйверов системы.
Драйвера сетевых адаптеров были выгружены. Так же перестали работать драйвера сетевых протоколов. Выполним вывод сетевых интерфейсов.
Вывод ожидаемо отсутствует, доступных сетевых интерфейсов нет. Значит сетевая подсистема на данный момент не работает. Теперь выполним загрузку драйверов сетевых адаптеров, скачанных нами ранее.
Проверим список драйверов системы.
Из загруженных, заработал драйвер E8310X3.EFI. Так же заработали встроенные драйвера сетевых протоколов. Попробуем вывести список сетевых интерфейсов системы.
В системе появился сетевой интерфейс. Это значит что загруженный драйвер успешно заработал.
Проверим работу сети. Выполним пинг IP-адреса 8.8.8.8.
Какой вывод можно сделать после проверки скачанных драйверов в виртуальной машине VMWare. Самый главное, это то, что скачанные драйвера все же исправно работают. Тот факт, что виртуальная машина VirtualBox, не отображала сетевых интерфейсов, после загрузки драйверов, указывает на то, что проблема все же, в встроенных драйвера сетевых протоколов данной виртуальной машины. Но это лишь мои предположения. Если у вас есть информация по этому поводу, то напишите о ней в комментариях.
В этом материале, я постарался вкратце рассмотреть работу с драйверами в оболочке UEFI Shell. Конкретно были затронуты следующие темы (возможно и косвенно): Как загрузить драйвера в UEFI Shell? Как выгрузить драйвера в UEFI Shell? Как добавить UEFI-драйвер в автозагрузку? Как убрать UEFI-драйвер из автозагрузки? Как выполнить установку драйверов в UEFI Shell?
Это не первое описание практического применения оболочки UEFI. В предыдущей статье были рассмотрены варианты решения проблем загрузки операционной системы. Рекомендую ознакомиться с ним. В следующем, поговорим о скриптах командной оболочки, в частности скрипте автозапуска startup.nsh.
Содержание
Зачем Это Нужно
Загрузка внешних драйверов позволяет расширить поддержку тех, или иных функций в подсистеме UEFI. К примеру, по умолчанию, UEFI понимает лишь файловую систему FAT. С помощью драйверов, можно добавить поддержку других файловых систем. Что позволит выполнять с них загрузку *.efi программ.
Еще пример, загрузка драйверов сетевых адаптеров. Загрузка подобных драйверов позволит активировать сетевые функции в подсистеме UEFI. Что подразумевает использование протокола TCP/IP встроенными или внешними EFI-приложениями.
Можно задаться вопросом - Если все и так работает, зачем расширять возможности UEFI путем загрузки внешних драйверов? Так как сама оболочка UEFI Shell, это инструмент, в большей степени, для управления загрузкой, данные дополнительные функции можно реализовать используя скрипты автозагрузки. Например, для осуществления загрузки из файловой системы ext или ntfs. Или даже пойти более сложным путем, осуществлять загрузку при наличии сети или ее отсутствии.
Тестовая Машина
Все дальнейшие действия будут проводиться в виртуальной машине VirutualBox, на которой установлены операционные системы Windows 10 и Ubuntu Linux 18.10. То есть фактически жесткий диск данной виртуалки содержит файловые системы FAT32, EXT4 и NTFS. Последние две, не поддерживаются UEFI.
В качестве сетевой карты выбран адаптер Intel.
Что Будем Делать
Сперва, загрузим драйвера для файловых систем NTFS и EXT тестовой виртуальной машины. Продемонстрируем полученный результат. Попробуем выполнить установку данных драйверов.
Вторым действием, попробуем загрузить драйвера для виртуального сетевого адаптера Intel PRO/1000 MT Desktop. С последующей проверкой сети командой ping.
Скачиваем Драйвера
Достать актуальные драйвера, для популярных файловых систем можно по этой следующим ссылкам: x64, ia32, arm, aa64. Выбираем нужную платформу и качаем соответствующие драйвера.
Драйвера для сетевых карт Realtek можно загрузить по ссылке https://yadi.sk/d/OELUb2AGd-SJWQ.
Или же по ссылке https://realtek-drivers.ru/realtek-pcie-gbe-family-controller/.
Или же по ссылке https://realtek-drivers.ru/realtek-pcie-gbe-family-controller/.
Драйвера для сетевых карт Intel загружаем по этой ссылке https://yadi.sk/d/VSUP8l2KPqAaAA.
Оригинальный архив доступен по ссылке https://downloadcenter.intel.com/ru/download/19186/Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers.
Скачанные драйвера копируем на флеш-накопитель, отформатированный в файловую систему FAT32. Необходимо это для того, чтобы при подключении данного накопителя, в загруженной оболочке UEFI Shell, к нему можно было получить доступ.
Загрузка Драйверов Файловых Систем
Ранее говорилось, что тестовая система содержит две файловые системы, которые будут недоступны в подсистеме UEFI, это NTFS и EXT4. Попробуем загрузить драйвера для данных файловых систем.
Итак, UEFI Shell загружен, подключаем флешку с скачанными драйверами и выполняем команду переопределения подключенных дисков.
# переопределение таблицы монтирования
map -r
В выводе команды ищем точку подключения флешки, в дальнейшем будем называть ее диском. В моем случае это диск FS3. Определить флешку можно по типу устройства, он будет USB. Переходим на данный диск и выводим его содержимое.
# переход на диск FS3
FS3:
# вывод содержимого текущего каталога
ls
В корне диска располагается папка Drivers, созданная нами на этапе скачивания драйверов. Переходим в по пути Drivers\FS и смотрим что в нем находится.
cd Drivers\FS
ls
В полученном списке файлов, присутствуют следующие, ntfs_x64.efi и ext2_x64.efi. Их мы будем загружать.
Перед загрузкой драйверов файловых систем, просмотрим на разделы которые на данный момент недоступны.
# вывод точек монтирования всех блочных устройств
map
В полученном списке, не составит труда определить необходимые разделы. Это BLK1, BLK3, BLK4, BLK5. На данный момент они не доступны. Доступные для просмотра, то есть понятные системе UEFI, диски имеют префикс FSx.
Первым, загрузим драйвер ntfs_x64.efi. После чего выполним переинициализацию смонтированных дисков.
# загрузка драйвера ntfs_x64.efi
load ntfs_x64.efi
# переинициализация дисков
map -r
Разберем, что произошло после выполнения команд указанных выше. Первое, что бросается в глаза, это то, что диски BLK1 и BLK4 получили новые метки FS0 и FS2 соответственно. Это значит, что данные разделы имеют файловую систему NTFS. Проверим содержимое данных дисков.
ls FS0:
ls FS2:
По содержимому дисков можно соделать вывод, что FS0 это раздел восстановления Windows, а FS2 это раздел с установленной операционной системой Windows.
Еще одним замечанием, является то, что диск FS3 указывающий на флешку, и начал указывать на CD-привод. Флеш накопитель теперь смонтирован под меткой FS5. Произошло это из-за переопределения таблицы монтирования после команды map -r.
Загрузим теперь драйвер ext2_x64.efi, с последующим переопределением смонтированных дисков.
# переходим на флешку
FS5:
# переходим в каталог с драйверами
cd Drivers\FS
# загружаем драйвер файловой системы EXT
load ext2_x64.efi
# переопределяем таблицу монтирования
map -r
На этот раз, диск BLK5 получил префикс FS3. А флешка теперь находится под меткой FS6. Посмотрим содержимое диска FS3.
ls FS3:
Его содержимое говорит о том, что это раздел операционной системы Ubuntu Linux. Что же тогда с разделом BLK3. Он, в данном случае, принадлежит Linux, это SWAP-раздел (раздел подкачки).
На этом драйверы файловых систем загружены. Посмотреть список всех загруженных драйверов в подсистеме UEFI, можно командой drivers.
Автозагрузка UEFI-драйверов
Все выполненные действия по загрузке драйверов, в предыдущем разделе, актуальны до первой перезагрузки компьютера. После перезагрузки, драйвера придется загружать снова. А что делать если загружаемый драйвер необходим при каждой загрузке? На этот случай, подсистема UEFI располагает возможностью добавлять загрузочные записи для драйверов. Добавим ранее загружаемые драйвера файловых систем в автозагрузку.
Добавляемые в автозагрузку драйвера, необходимо разместить на системном EFI-разделе в любую угодную вам директорию. В моем случае, я использовал папку /EFI/Boot. На данный момент виртуальный ПК, был перезагружен, поэтому метки дисков вернулись в свое первоначальное состояние. FS0 - системный EFI-раздел, FS3 - флешка с драйверами. Выполним копирование драйверов на системный EFI-раздел.
# копируем драйвер ntfs_x64.efi в системный EFI-раздел
cp FS3:\Drivers\FS\ntfs_x64.efi FS0:\EFI\Boot
# копируем драйвер ext2_x64.efi в системный EFI-раздел
cp FS3:\Drivers\FS\ext2_x64.efi FS0:\EFI\Boot
Драйвера скопированы. Теперь создадим загрузочные записи для скопированных драйверов.
# добавление загрузочной записи для драйвера ntfs_x64.efi
bcfg driver add 0 FS0:\EFI\Boot\ntfs_x64.efi "NTFS Driver"
# добавление загрузочной записи для драйвера ext2_x64.efi
bcfg driver add 1 FS0:\EFI\Boot\ext2_x64.efi "EXT Driver"
Проверим наличие загрузочных записей после их добавления.
# вывод информации о загрузочных записях для драйверов
bcfg driver dump
Данные загрузочные записи, будут храниться в подсистеме UEFI, в NVRAM. Сбросить их можно будет, лишь вытащив батарейку из материнской платы компьютера, или удалив.
Удаление загрузочных записей для драйверов, происходит следующим образом:
# удаление загрузочной записи драйвера под номером 0
bcfg driver rm 0Номера загрузочных записей, можно посмотреть в выводе предыдущей команды. Замечу, что нумерация их начинается с нуля.
Загрузка Сетевых Драйверов
В качестве сетевого адаптера в виртуальной машине VirtualBox, выбрана сетевая карта Intel PRO/1000 MT. Подсистема UEFI, встроенная в VirtualBox, не содержит драйверов под эту сетевую карту. Это весьма странно, конкурент от VMWare этим не грешит, и возможно данные драйвера будут интегрированы в последующих версиях. Выбрана данная сетевая карта, так же из-за того, что в интернете для нее присутствуют UEFI-драйвера. Их легко найти и скачать.
Забегая вперед, скажу, что с виртуальной машиной VirtualBox возникнет проблема. Диагностировать которую, не так уж и просто. Но обо всем по порядку.
Загружаем сетевые драйвера. Так как скачанный пакет EFI-драйверов насчитывает 5 файлов,
# переходим на флешку
FS3:
# переходим в каталог с EFI-драйверами
cd Drivers\Lan\Intel
# смотрим содержимое папки
ls
и по именам этих файлов не понять, какой из них предназначен для сетевой карты используемой нами, самым простым действием будет загрузка всех пяти, но без подключения. То есть, драйвера загружаются в память, но не запускаются.
# выполнить загрузку без подключения всех драйверов в текущем каталоге
load -nc *
После загрузки драйверов в память, посмотрим список всех драйверов подсистемы UEFI.
# вывод списка всех UEFI драйверов
drivers
Из представленного списка, очевидными вариантами для запуска, являются два драйвера - E3522X2.EFI и E8310X3.EFI. Но прежде чем продолжить, давайте разберем вывод команды drivers более подробно.
Вывод команды строиться в виде таблицы, состоящий из девяти столбцов.
1. Дескриптор драйвера. То есть, уникальное число в формате HEX, за которым закреплен драйвер. Это число используется другими командами для выполнения операций над конкретным драйвером.
2. Версия драйвера. Тут все просто, числовое обозначение версии драйвера.
3. Тип Драйвера. Возможные значения - B - драйвер шины, D - драйвер устройства, ? - неизвестный, или не подключенный драйвер.
4. Поддержка конфигурационного протокола. Наличие знака "X", вместо "-", говорит о том что данный драйвер поддерживает возможность конфигурирования.
5. Поддержка диагностического протокола. Наличие знака "X", вместо "-", говорит о том что данный драйвер поддерживает возможность диагностики. То есть способен выдать сведения о своем состоянии.
6. Число устройств обслуживаемых драйвером.
7. Число дочерних устройств работающих под этим драйвером.
8. Имя драйвера.
9. Путь до файла драйвера. Файл драйвера может располагаться как в оперативной памяти, так и жестком диске, или любом другом поддерживаемом накопителе.
И так, продолжим. Выбор пал на драйвера E3522X2.EFI и E8310X3.EFI. Тип данных драйверов имеет знак ?. Все из-за того, что драйвера мы загружали без подключения, и их тип системе UEFI пока неизвестен. Выполним подключение данных драйверов, то есть их запуск. Для этого понадобится использовать их дескрипторы. В моем случае, для драйвера E3522X2.EFI дескриптор равен AE, а для E8310X3.EFI B0.
# переподключение драйвера AE и B0
reconnect AE
reconnect B0
Снова выведем информацию о драйверах.
drivers
По выводу видно, что из двух драйверов, заработал только AE. У него сменился тип с "?" на "B", счетчик устройств обсуживаемых драйвером стал равным 1. Кроме этого, стали активными и встроенные драйвера сетевых протоколов, появилась информация о их типе и счетчике устройств. Драйвер заработал. Проверяем доступные сетевые интерфейсы.
# вывод списка сетевых интерфейсов
ifconfig -l
Пустой вывод, или отсутствие вывода, в данном случае, говорит о том, что сетевых интерфейсов нет. Следовательно драйвер не заработал как нужно, вопрос только какой именно драйвер. Как было сказано ранее, при загрузке драйвера сетевой карты, так же были активированы и драйверы протоколов. На данный момент, на отсутствие сети, могут влиять как драйвер сетевой карты так и встроенные драйвера протоколов.
Взглянем на дерево устройств, в нем так же можно найти полезную информацию.
# вывод дерево устройств постранично
devtree -b
Дерево сетевой карты начинается с дескриптора AD. Этот дескриптор можно использовать с командами connect, reconnect, disconnect. Команда devtree, позволяет выводить отдельную ветку определенного устройства, при передаче в качестве параметра его дескриптора. Выведем отдельно ветку сетевой карты, для отсечения информации о других устройствах.
# вывод ветки устройства AD
devtree AD -b
По ветке сетевого адаптера, видны дескрипторы протоколов, некоторые из них, включая TCPv4, не запущены, то есть имеют маркировку Not Started. Что собственно может служить причиной отсутствия доступных сетевых интерфейсов. Но это не точно.
Попробуем проверить вывод команд drivers и devtree на другой виртуальной машине, а именно VMWare. Подсистема UEFI данной виртуальной машины содержит интегрированные драйвера для используемых ею сетевых адаптеров. То есть сеть в UEFI работает изначально без дополнительных действий.
Запускаем UEFI Shell.
Смотрим список драйверов.
drivers
Как было сказано выше, подсистема UEFI, виртуальной машины VMWare, уже содержит необходимые сетевые драйвера. Указанные на снимке сетевые драйвера, судя по их статусу, работают. Проверим наличие сетевых интерфейсов.
ifconfig -l
Вот так должен выглядеть вывод команды ifconfig, когда с сетевой подсистемой все в порядке. На снимке видно, что сетевому интерфейсу не присвоены сетевые настройки.
Просмотрим теперь дерево устройств. А именно как будет выглядеть ветка сетевого адаптера.
devtree -b
Сетевая карта, в моем случае, имеет дескриптор CD. Выведем отдельно ветку сетевой карты.
# вывод ветки сетевой карты
devtree CD -b
Сравните вывод на машине VMWare, с аналогичным в VirtualBox. Основное различие, не запущенный протокол TCP, при использовании VirtualBox.
Раз была затронута тема сравнения, то предлагаю попробовать выгрузить встроенный драйвер сетевого адаптера виртуальной машины VMWare, и загрузить те, что были скачаны нами для использования в VirtualBox.
Просмотрим еще раз список загруженных драйверов, чтобы узнать дескрипторы драйверов сетевых адаптеров.
drivers
В системе присутствует два загруженных драйвера для сетевых адаптеров, первый c дескрипторам 81, и второй с дескриптором 82. Из них, в рабочем состоянии драйвер 82. Из описания которого понятно, что это драйвер сетевого адаптера Intel PRO/1000 PCI-E. Выгрузим оба.
# выгружаем указанные драйвера с подробным выводом информации
unload 81 -v
unload 82 -v
Проверим список драйверов системы.
drivers
Драйвера сетевых адаптеров были выгружены. Так же перестали работать драйвера сетевых протоколов. Выполним вывод сетевых интерфейсов.
ifconfig -l
Вывод ожидаемо отсутствует, доступных сетевых интерфейсов нет. Значит сетевая подсистема на данный момент не работает. Теперь выполним загрузку драйверов сетевых адаптеров, скачанных нами ранее.
# загрузка драйверов с флешки
load FS0:\Drivers\Lan\Intel\E3522X2.EFI
load FS0:\Drivers\Lan\Intel\E8310X3.EFI
Проверим список драйверов системы.
drivers
ifconfig -l
В системе появился сетевой интерфейс. Это значит что загруженный драйвер успешно заработал.
Проверим работу сети. Выполним пинг IP-адреса 8.8.8.8.
# обновить конфигурацию сетевого интерфейса по dhcp
ifconfig -r
# вывод информации о сетевых интерфейсах
ifconfig -l
# пинг IP-адреса двумя пакетами
ping 8.8.8.8 -n 2
Какой вывод можно сделать после проверки скачанных драйверов в виртуальной машине VMWare. Самый главное, это то, что скачанные драйвера все же исправно работают. Тот факт, что виртуальная машина VirtualBox, не отображала сетевых интерфейсов, после загрузки драйверов, указывает на то, что проблема все же, в встроенных драйвера сетевых протоколов данной виртуальной машины. Но это лишь мои предположения. Если у вас есть информация по этому поводу, то напишите о ней в комментариях.
Итог
В этом материале, я постарался вкратце рассмотреть работу с драйверами в оболочке UEFI Shell. Конкретно были затронуты следующие темы (возможно и косвенно): Как загрузить драйвера в UEFI Shell? Как выгрузить драйвера в UEFI Shell? Как добавить UEFI-драйвер в автозагрузку? Как убрать UEFI-драйвер из автозагрузки? Как выполнить установку драйверов в UEFI Shell?
Это не первое описание практического применения оболочки UEFI. В предыдущей статье были рассмотрены варианты решения проблем загрузки операционной системы. Рекомендую ознакомиться с ним. В следующем, поговорим о скриптах командной оболочки, в частности скрипте автозапуска startup.nsh.
Комментариев нет :
Отправить комментарий