Курс по Линукс Минт
Добавлено: 29 ноя 2018, 10:43
Пытаюсь связать воедино.. Если отсутствует модуль CSM, то..
LinuxMint.com.ru
Курс по Линукс Минт
Страница 14 из 15
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 10:57
Позвонил товарищу. DVD у него нет. Ключ покупает и в стиме устанавливает. MBR железо видит, но Винду установить можно только на GPT . С линуксом он ( товарищ) не дружит, поэтому возможность установки его на своё железо не проверял. Железо такое: мать asus tuf z390m-pro gaming. Проц i5-9600k/ Ну и память соответственно DDR4
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 11:32
Как-то расплывчато. Не видит где? Не видит как?
UEFI-BIOS не видит MBR диски совсем?
Или не видит MBR диски как загрузочный носитель в UEFI режиме (в Boot Menu). Если как загрузочный носитель, то с вероятностью 99%, MBR диски Вашего товарища небыли UEFI загрузочными, возможно поэтому UEFI-BIOS не видел их как загрузочные носители. В подтверждение этого предположения, говорит то, что Ваш товарищ преобразовал диски в GPT, а мог бы просто включить Legacy/CSM (если такой имеется).
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 11:40
Сейчас уже трудно что-либо сказать. Было бы это у меня, я бы протестил во всех режимах, а он не стал заморачиваться, а тупо, как просила система, преобразовал диск в GPT и установил Винду. Всё работает, играет дальше. Я бы и установкой Linux Mint проверил (чтобы совсем уж не оффтопить).
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 13:39
Для тех кто читает по-английски
стандарт UEFI
https://www.uefi.org/specifications
http://www.uefi.org/sites/default/files ... ec_2_7.pdf
В стандарте около 3000 страниц. Не знаю кто это осилит (-ил). Тем кто все-таки решится, подскажу: вплоть до 72 страницы вода... (гуглоперевод)
По теме загрузки может быть интересен пункт 1.6. - овервью.
Если кто-то еще что по теме из этого документа вытянет-переведет - милости прошу кидайте под спойлеры.
стандарт UEFI
https://www.uefi.org/specifications
http://www.uefi.org/sites/default/files ... ec_2_7.pdf
В стандарте около 3000 страниц. Не знаю кто это осилит (-ил). Тем кто все-таки решится, подскажу: вплоть до 72 страницы вода... (гуглоперевод)
1. Введение
Этот интерфейс Unified Extensible Firmware Interface (далее называемый UEFI) описывает интерфейс между операционной системой (ОС) и прошивкой платформы.
UEFI предшествовала спецификация интерфейса расширенного встроенного программного обеспечения 1.10 (EFI). В результате некоторые коды и определенные имена протоколов сохраняют обозначение EFI. Если не указано иное, обозначения EFI в этой спецификации могут считаться частью UEFI.
Интерфейс представлен в виде таблиц данных, содержащих информацию, связанную с платформой, а также вызовы службы загрузки и времени выполнения, доступные для загрузчика ОС и ОС. Вместе они обеспечивают стандартную среду для загрузки ОС. Эта спецификация спроектирована как чистая спецификация интерфейса. Таким образом, спецификация определяет набор интерфейсов и структур, которые должна внедрить прошивка платформы. Аналогично, спецификация определяет набор интерфейсов и структур, которые ОС может использовать при загрузке. Как разработчик прошивки хочет реализовать требуемые элементы, либо разработчик ОС решит использовать эти интерфейсы и структуры, это решение для реализации, оставленное разработчику.
Цель этой спецификации - определить способ прошивки операционной системы и платформы для передачи только информации, необходимой для поддержки процесса загрузки ОС. Это достигается посредством формальной и полной абстрактной спецификации программного обеспечения,
видимый интерфейс, представленный ОС платформой и прошивкой.
Используя это формальное определение, операционная система с термоусадочной оболочкой, предназначенная для работы на платформах, совместимых с поддерживаемыми спецификациями процессоров, сможет загружаться на различных конструкциях системы без дальнейшей настройки платформы или ОС. Это определение также позволит инновациям платформы внедрять новые функции и функциональные возможности, которые повышают возможности платформы, не требуя ввода нового кода в последовательность загрузки ОС.
Кроме того, абстрактная спецификация открывает маршрут для замены устаревших устройств и кода прошивки с течением времени. Новые типы устройств и связанный с ними код могут обеспечивать эквивалентную функциональность с помощью того же определенного абстрактного интерфейса, что опять же не влияет на код поддержки загрузки ОС.
Спецификация применима к полному набору аппаратных платформ от мобильных систем к серверам. Спецификация предоставляет основной набор сервисов наряду с выбором интерфейсов протокола. Выбор протокольных интерфейсов может со временем эволюционировать для оптимизации для различных сегментов рынка платформы. В то же время спецификация позволяет максимально расширять возможности и возможности настройки для OEM-производителей, чтобы они могли дифференцироваться. В этом цель UEFI заключается в том, чтобы определить эволюционный путь от традиционного «загрузочного мира» ПК-AT в среду, свободную от устаревших API.
1.1 Расширения модели драйверов UEFI Доступ к загрузочным устройствам обеспечивается через набор интерфейсов протокола. Одна из целей модели драйверов UEFI заключается в том, чтобы предоставить замену для ПЗУ типа «PC-AT». Важно отметить, что драйверы, написанные в модели драйверов UEFI, предназначены для введения спецификации UEFI версии 2 мая 2017 года версии 2.7 в загрузочные устройства в среде предварительной загрузки. Они не предназначены для замены высокопроизводительных драйверов, специфичных для ОС.
Модель драйвера UEFI предназначена для поддержки выполнения модульных частей кода, также известных как драйверы, которые запускаются в среде предварительной загрузки. Эти драйверы могут управлять или управлять аппаратными шинами и устройствами на платформе, или они могут предоставлять некоторую определенную программным обеспечением, специфичную для платформы.
Модель драйвера UEFI также содержит информацию, необходимую разработчикам драйверов UEFI для разработки и внедрения любой комбинации драйверов шин и драйверов устройств, которые могут потребоваться платформе для загрузки UEFI-совместимой ОС.
Модель драйвера UEFI разработана как универсальная и может быть адаптирована к любому типу шины или устройства. Спецификация UEFI описывает, как писать драйверы шины PCI, драйверы устройств PCI, драйверы шины USB, драйверы USB-устройств и драйверы SCSI. Предоставляются дополнительные сведения, которые позволяют хранить UEFI-драйверы в ПЗУ с дополнительными ПЗУ, сохраняя при этом совместимость с устаревшими изображениями ПЗУ.
Одна из целей дизайна в спецификации UEFI заключается в том, чтобы изображения драйвера были как можно меньше. Однако, если для поддержки нескольких процессорных архитектур требуется драйвер, для каждой поддерживаемой архитектуры процессора также должен быть отправлен объектный файл драйвера. Чтобы решить эту проблему, эта спецификация также определяет виртуальную машину байтового кода EFI. Драйвер UEFI может быть скомпилирован в один объектный файл байтового кода EFI.
Спецификация спецификации UEFI-жалобы должна содержать интерпретатор байтового кода EFI. Это позволяет использовать один объектный файл байтового кода EFI, который поддерживает отправку нескольких процессорных архитектур. Другой способ экономии пространства - это использование сжатия.
Этот интерфейс Unified Extensible Firmware Interface (далее называемый UEFI) описывает интерфейс между операционной системой (ОС) и прошивкой платформы.
UEFI предшествовала спецификация интерфейса расширенного встроенного программного обеспечения 1.10 (EFI). В результате некоторые коды и определенные имена протоколов сохраняют обозначение EFI. Если не указано иное, обозначения EFI в этой спецификации могут считаться частью UEFI.
Интерфейс представлен в виде таблиц данных, содержащих информацию, связанную с платформой, а также вызовы службы загрузки и времени выполнения, доступные для загрузчика ОС и ОС. Вместе они обеспечивают стандартную среду для загрузки ОС. Эта спецификация спроектирована как чистая спецификация интерфейса. Таким образом, спецификация определяет набор интерфейсов и структур, которые должна внедрить прошивка платформы. Аналогично, спецификация определяет набор интерфейсов и структур, которые ОС может использовать при загрузке. Как разработчик прошивки хочет реализовать требуемые элементы, либо разработчик ОС решит использовать эти интерфейсы и структуры, это решение для реализации, оставленное разработчику.
Цель этой спецификации - определить способ прошивки операционной системы и платформы для передачи только информации, необходимой для поддержки процесса загрузки ОС. Это достигается посредством формальной и полной абстрактной спецификации программного обеспечения,
видимый интерфейс, представленный ОС платформой и прошивкой.
Используя это формальное определение, операционная система с термоусадочной оболочкой, предназначенная для работы на платформах, совместимых с поддерживаемыми спецификациями процессоров, сможет загружаться на различных конструкциях системы без дальнейшей настройки платформы или ОС. Это определение также позволит инновациям платформы внедрять новые функции и функциональные возможности, которые повышают возможности платформы, не требуя ввода нового кода в последовательность загрузки ОС.
Кроме того, абстрактная спецификация открывает маршрут для замены устаревших устройств и кода прошивки с течением времени. Новые типы устройств и связанный с ними код могут обеспечивать эквивалентную функциональность с помощью того же определенного абстрактного интерфейса, что опять же не влияет на код поддержки загрузки ОС.
Спецификация применима к полному набору аппаратных платформ от мобильных систем к серверам. Спецификация предоставляет основной набор сервисов наряду с выбором интерфейсов протокола. Выбор протокольных интерфейсов может со временем эволюционировать для оптимизации для различных сегментов рынка платформы. В то же время спецификация позволяет максимально расширять возможности и возможности настройки для OEM-производителей, чтобы они могли дифференцироваться. В этом цель UEFI заключается в том, чтобы определить эволюционный путь от традиционного «загрузочного мира» ПК-AT в среду, свободную от устаревших API.
1.1 Расширения модели драйверов UEFI Доступ к загрузочным устройствам обеспечивается через набор интерфейсов протокола. Одна из целей модели драйверов UEFI заключается в том, чтобы предоставить замену для ПЗУ типа «PC-AT». Важно отметить, что драйверы, написанные в модели драйверов UEFI, предназначены для введения спецификации UEFI версии 2 мая 2017 года версии 2.7 в загрузочные устройства в среде предварительной загрузки. Они не предназначены для замены высокопроизводительных драйверов, специфичных для ОС.
Модель драйвера UEFI предназначена для поддержки выполнения модульных частей кода, также известных как драйверы, которые запускаются в среде предварительной загрузки. Эти драйверы могут управлять или управлять аппаратными шинами и устройствами на платформе, или они могут предоставлять некоторую определенную программным обеспечением, специфичную для платформы.
Модель драйвера UEFI также содержит информацию, необходимую разработчикам драйверов UEFI для разработки и внедрения любой комбинации драйверов шин и драйверов устройств, которые могут потребоваться платформе для загрузки UEFI-совместимой ОС.
Модель драйвера UEFI разработана как универсальная и может быть адаптирована к любому типу шины или устройства. Спецификация UEFI описывает, как писать драйверы шины PCI, драйверы устройств PCI, драйверы шины USB, драйверы USB-устройств и драйверы SCSI. Предоставляются дополнительные сведения, которые позволяют хранить UEFI-драйверы в ПЗУ с дополнительными ПЗУ, сохраняя при этом совместимость с устаревшими изображениями ПЗУ.
Одна из целей дизайна в спецификации UEFI заключается в том, чтобы изображения драйвера были как можно меньше. Однако, если для поддержки нескольких процессорных архитектур требуется драйвер, для каждой поддерживаемой архитектуры процессора также должен быть отправлен объектный файл драйвера. Чтобы решить эту проблему, эта спецификация также определяет виртуальную машину байтового кода EFI. Драйвер UEFI может быть скомпилирован в один объектный файл байтового кода EFI.
Спецификация спецификации UEFI-жалобы должна содержать интерпретатор байтового кода EFI. Это позволяет использовать один объектный файл байтового кода EFI, который поддерживает отправку нескольких процессорных архитектур. Другой способ экономии пространства - это использование сжатия.
1.6 Обзор дизайна UEFI
Конструкция UEFI основана на следующих фундаментальных элементах:
• Повторное использование существующих табличных интерфейсов.
Чтобы сохранить инвестиции в существующий код поддержки инфраструктуры, как в ОС, так и в прошивке, ряд существующих спецификаций, которые обычно реализуются на платформах, совместимых с поддерживаемыми спецификациями процессора, должны быть реализованы на платформах, желающих соответствовать спецификации UEFI.
(Дополнительную информацию см. В Приложении Q: Ссылки.)
• Системный раздел.
Раздел System определяет раздел и файловую систему, которые предназначены для безопасного обмена между несколькими поставщиками и для разных целей.
Возможность включения отдельного разделяемого системного раздела дает возможность увеличить добавление стоимости платформы без существенного увеличения потребности в энергонезависимой памяти платформы.
• Службы загрузки.
Службы загрузки предоставляют интерфейсы для устройств и системных функций, которые могут использоваться во время загрузки. Доступ к устройствам абстрагируется с помощью «ручек» и «протоколов». Это облегчает повторное использование инвестиций в существующий код BIOS, сохраняя требования базовой реализации из спецификации без ущерба для доступа потребителя к устройству.
• Службы времени выполнения.
Представлен минимальный набор служб времени выполнения, чтобы обеспечить соответствующую абстракцию аппаратных ресурсов базовой платформы, которые могут потребоваться ОС во время ее обычных операций.
На рисунке 1 показаны основные компоненты UEFI и их связь с оборудованием платформы и программным обеспечением ОС.
Введение Спецификация UEFI 12 мая 2017 г. Версия 2.7
Рисунок 1. Концептуальный обзор UEFI Рисунок 1
иллюстрирует взаимодействия различных компонентов совместимой с UEFI системы, которые используются для загрузки платформы и ОС.
Прошивка платформы может извлекать изображение загрузчика ОС из системного раздела.
В спецификации предусмотрены различные типы устройств хранения, включая диск, CD-ROM и DVD, а также удаленную загрузку через сеть. С помощью расширяемых интерфейсов протокола можно добавлять другие типы загрузочных носителей, хотя для них могут потребоваться модификации загрузчика ОС, если они требуют использования протоколов, отличных от тех, которые определены в этом документе.
После запуска загрузчик ОС продолжает загружать полную операционную систему. Для этого он может использовать сервисы загрузки EFI и интерфейсы, определенные этими или другими требуемыми спецификациями, для обследования, понимания и инициализации различных компонентов платформы и программного обеспечения ОС, которое их управляет. Службы среды EFI также доступны загрузчику ОС во время фазы загрузки.
Конструкция UEFI основана на следующих фундаментальных элементах:
• Повторное использование существующих табличных интерфейсов.
Чтобы сохранить инвестиции в существующий код поддержки инфраструктуры, как в ОС, так и в прошивке, ряд существующих спецификаций, которые обычно реализуются на платформах, совместимых с поддерживаемыми спецификациями процессора, должны быть реализованы на платформах, желающих соответствовать спецификации UEFI.
(Дополнительную информацию см. В Приложении Q: Ссылки.)
• Системный раздел.
Раздел System определяет раздел и файловую систему, которые предназначены для безопасного обмена между несколькими поставщиками и для разных целей.
Возможность включения отдельного разделяемого системного раздела дает возможность увеличить добавление стоимости платформы без существенного увеличения потребности в энергонезависимой памяти платформы.
• Службы загрузки.
Службы загрузки предоставляют интерфейсы для устройств и системных функций, которые могут использоваться во время загрузки. Доступ к устройствам абстрагируется с помощью «ручек» и «протоколов». Это облегчает повторное использование инвестиций в существующий код BIOS, сохраняя требования базовой реализации из спецификации без ущерба для доступа потребителя к устройству.
• Службы времени выполнения.
Представлен минимальный набор служб времени выполнения, чтобы обеспечить соответствующую абстракцию аппаратных ресурсов базовой платформы, которые могут потребоваться ОС во время ее обычных операций.
На рисунке 1 показаны основные компоненты UEFI и их связь с оборудованием платформы и программным обеспечением ОС.
Введение Спецификация UEFI 12 мая 2017 г. Версия 2.7
Рисунок 1. Концептуальный обзор UEFI Рисунок 1
иллюстрирует взаимодействия различных компонентов совместимой с UEFI системы, которые используются для загрузки платформы и ОС.
Прошивка платформы может извлекать изображение загрузчика ОС из системного раздела.
В спецификации предусмотрены различные типы устройств хранения, включая диск, CD-ROM и DVD, а также удаленную загрузку через сеть. С помощью расширяемых интерфейсов протокола можно добавлять другие типы загрузочных носителей, хотя для них могут потребоваться модификации загрузчика ОС, если они требуют использования протоколов, отличных от тех, которые определены в этом документе.
После запуска загрузчик ОС продолжает загружать полную операционную систему. Для этого он может использовать сервисы загрузки EFI и интерфейсы, определенные этими или другими требуемыми спецификациями, для обследования, понимания и инициализации различных компонентов платформы и программного обеспечения ОС, которое их управляет. Службы среды EFI также доступны загрузчику ОС во время фазы загрузки.
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 15:17
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 16:12
Со слов, которые система напечатала на экране монитора, когда товарищ попытался на новом железе запустить свой старый диск с установленной десяткой. И следуя этому виртуальному руководству он преобразовал диск в GPT. Больше я ничего не могу сказать. У меня нет такого современного железа, чтобы продолжить испытания.
Ну и товарищу ещё раз позвонил - он сказал, что на новой материнке пытался запуститься по дефолтным настройкам (так же как и на старой материнской плате). Обе материнские платы Asus и BIOS-UEFI выглядел внешне абсолютно одинаково. Как то так. Возможно стандарты настроек обеих материнских плат разные.Курс по Линукс Минт
Добавлено: 29 ноя 2018, 16:25
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 16:47
емнип хрюшу после смены материнки запускал состарого винта
гемора столько же как и с 9* . Тут имело значение каким образом с какого носителя ставилась ось и наличие установочных файлов
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 16:55
colonel, да ну... хрюша уже жёстко привязывалась к контроллеру жёсткого и если не совпадало, то привет страчено... если удалить из системы ещё рабочей этот контроллер и установить универсальный и сунуть на другую плату, то можно было запуститься...
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 17:02
50 на 50. Если железо родственное или как то близкое по характеристикам (intel и intel), например
, то запускается. Активация, конечно при этом терялась - потому как она вроде привязана к серийному номеру материнской платы. Можно менять все компоненты железа кроме мамки. Активация сохраняется. Если же железо абсолютно разное (типа intel - AMD), то система может вообще не запуститься. Ну это всё относится к винде, в основном к десятой. В Linux вроде всё по другому. Привязки к железу точно нет.
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 20:04
WWolf, > "... хрюша уже жёстко привязывалась..."
hellonet, >"Если железо родственное ...Активация, конечно при этом терялась -.. .. Если же железо абсолютно разное (типа intel - AMD), то система может вообще не запуститься .... "
вопрос же не о сохранении активации ... и речь не о том что переставил винт на другой комп и всё сразу заработало .
что восстановление , что и повторная установка поверх ранее установленного от гемора не освобождают и не просто так было сказано "... имело значение каким образом с какого носителя ставилась ось и наличие установочных файлов"
hellonet, >"Если железо родственное ...Активация, конечно при этом терялась -.. .. Если же железо абсолютно разное (типа intel - AMD), то система может вообще не запуститься .... "
вопрос же не о сохранении активации ... и речь не о том что переставил винт на другой комп и всё сразу заработало .
что восстановление , что и повторная установка поверх ранее установленного от гемора не освобождают и не просто так было сказано "... имело значение каким образом с какого носителя ставилась ось и наличие установочных файлов"
Курс по Линукс Минт
Добавлено: 29 ноя 2018, 20:10
Курс по Линукс Минт
Добавлено: 30 ноя 2018, 04:07
5 Таблица разделов разделов GUID (GPT)
5.1 Сравнение размещения дисков GPT и MBR
Эта спецификация определяет макет диска таблицы GUID (GPT) (т. Е. Схему разбиения). В следующем списке перечислены преимущества использования макета диска GPT по сравнению с устаревшим расположением диска главной загрузочной записи (MBR):
•
Адреса логических блоков (LBA) - это 64 бита (а не 32 бита).
•
Поддерживает множество разделов (а не только четыре первичных раздела).
•
Предоставляет как основную, так и резервную таблицу разделов для резервирования.
•
Использует поля версии и размеры для будущего расширения.
•
Использует поля CRC32 для улучшения целостности данных.
•
Определяет идентификатор GUID для однозначной идентификации каждого раздела.
•
Использует GUID и атрибуты для определения типа содержимого раздела.
•
Каждый раздел содержит 36 символов для чтения человеком.
5.2 LBA 0 Формат LBA 0 (т. Е. Первый логический блок) на жестком диске содержит либо
•
базовую загрузочную запись (MBR) (см. раздел 5.2.1)
•
или защитный MBR (см. раздел 5.2.3).
5.2.1 Начальная загрузочная запись (MBR)
Унаследованный MBR может быть расположен на LBA 0 (то есть на первом логическом блоке) диска, если он не использует макет диска GPT (то есть, если он использует макет MBR-диска). Загрузочный код на MBR не выполняется с помощью прошивки UEFI.
5.1 Сравнение размещения дисков GPT и MBR
Эта спецификация определяет макет диска таблицы GUID (GPT) (т. Е. Схему разбиения). В следующем списке перечислены преимущества использования макета диска GPT по сравнению с устаревшим расположением диска главной загрузочной записи (MBR):
•
Адреса логических блоков (LBA) - это 64 бита (а не 32 бита).
•
Поддерживает множество разделов (а не только четыре первичных раздела).
•
Предоставляет как основную, так и резервную таблицу разделов для резервирования.
•
Использует поля версии и размеры для будущего расширения.
•
Использует поля CRC32 для улучшения целостности данных.
•
Определяет идентификатор GUID для однозначной идентификации каждого раздела.
•
Использует GUID и атрибуты для определения типа содержимого раздела.
•
Каждый раздел содержит 36 символов для чтения человеком.
5.2 LBA 0 Формат LBA 0 (т. Е. Первый логический блок) на жестком диске содержит либо
•
базовую загрузочную запись (MBR) (см. раздел 5.2.1)
•
или защитный MBR (см. раздел 5.2.3).
5.2.1 Начальная загрузочная запись (MBR)
Унаследованный MBR может быть расположен на LBA 0 (то есть на первом логическом блоке) диска, если он не использует макет диска GPT (то есть, если он использует макет MBR-диска). Загрузочный код на MBR не выполняется с помощью прошивки UEFI.
Ну и еще (не)много информации из того что перевелось гуглом, пока искал ответ на основной вопрос (выполняется ли загрузчик MBR в UEFI?) в спецификации UEFI.Загрузочный код на MBR не выполняется с помощью прошивки UEFI.
(не выбрасывать же - мало ли кому пригодиться).
(на качество перевода не пеняйте - переводил гуглом, искал конкретные ключевые слова/фразы, поэтому остальное особо не вычитывал... так... что бы общий смысл был понятен, а если нужно более точно - то ссылка на первоисточник есть в начале комментария).
2 Обзор
UEFI позволяет расширять прошивку платформы, загружая драйвер UEFI и изображения приложений UEFI. Когда загружаются UEFI-драйверы и приложения UEFI, они имеют доступ ко всем UEFI-определенным средам выполнения и загрузкам. См. Рисунок 2.
UEFI позволяет консолидировать загрузочные меню из загрузчика ОС и прошивки платформы в однопрограммное меню одной платформы. Эти программные меню платформы позволят выбрать любой загрузчик ОС UEFI из любого раздела на любом загрузочном носителе, который поддерживается службами загрузки UEFI. Загрузчик ОС UEFI может поддерживать несколько параметров, которые могут отображаться в пользовательском интерфейсе. Также возможно включить устаревшие параметры загрузки, такие как загрузка с диска A: или C: в меню загрузки прошивки платформы.
UEFI поддерживает загрузку с носителей, содержащих загрузчик ОС UEFI или системный раздел, определенный UEFI. UEFI-определенный системный раздел требуется UEFI для загрузки с блочного устройства. UEFI не требует каких-либо изменений в первом секторе раздела, поэтому можно создавать носители, которые будут загружаться как на старых архитектурах, так и на платформах UEFI.
2.1 Менеджер загрузки
UEFI содержит диспетчер загрузки, который позволяет загружать приложения, записанные в эту спецификацию (включая загрузчик 1-го этапа ОС) или драйверы UEFI из любого файла в файловой системе, определенной UEFI, или с помощью службы загрузки изображений, определенной UEFI. UEFI определяет переменные NVRAM, которые используются для указания на загружаемый файл. Эти переменные также содержат данные, специфичные для приложения, которые передаются непосредственно в приложение UEFI. Переменные также содержат читаемую пользователем строку, которая может отображаться в меню пользователю.
Переменные, определенные UEFI, позволяют прошивке системы содержать меню загрузки, которое может указывать на все операционные системы и даже на несколько версий одних и тех же операционных систем. Цель проекта UEFI состояла в том, чтобы иметь один набор загрузочных меню, которые могли бы работать в прошивке платформы. UEFI указывает только переменные NVRAM, используемые при выборе параметров загрузки. UEFI оставляет реализацию системы меню как пространство реализации добавленной стоимости.
UEFI значительно расширяет загрузочную гибкость системы по сравнению с существующим уровнем техники в системе класса PC-AT. Системы класса PC-AT в день ограничены загрузкой с первой дискеты, жесткого диска, CD-ROM, USB-ключей или сетевой карты, подключенной к системе. Загрузка с общего жесткого диска может вызвать множество проблем, связанных с операционными возможностями, между операционными системами и различными версиями операционных систем от одного и того же поставщика.
2.1.1 Изображения UEFI
UEFI Images - это класс файлов, определенных UEFI, которые содержат исполняемый код. Наиболее отличительной особенностью UEFI Images является то, что первый набор байтов в файле изображения UEFI содержит заголовок изображения, который определяет кодировку исполняемого изображения.
UEFI использует подмножество формы изображения PE32 + с измененной подписью заголовка. Изменение значения подписи в изображении PE32 + выполняется для различения изображений UEFI из обычных исполняемых файлов PE32. Добавление «+» к PE32 предоставляет 64-битные исправления для расширения в стандартном формате PE32.
Для изображений с сигнатурой изображения UEFI значения подсистемы в заголовке изображения PE определены ниже. Основные различия между типами изображений - это тип памяти, в которую встроенное ПО загружает изображение, и действие, выполняемое при выходе или возврате точки входа изображения. Образ приложения UEFI всегда выгружается, когда элемент управления возвращается из точки входа изображения. Образ драйвера UEFI выгружается только тогда, когда управление передается с кодом ошибки UEFI.
UEFI позволяет расширять прошивку платформы, загружая драйвер UEFI и изображения приложений UEFI. Когда загружаются UEFI-драйверы и приложения UEFI, они имеют доступ ко всем UEFI-определенным средам выполнения и загрузкам. См. Рисунок 2.
UEFI позволяет консолидировать загрузочные меню из загрузчика ОС и прошивки платформы в однопрограммное меню одной платформы. Эти программные меню платформы позволят выбрать любой загрузчик ОС UEFI из любого раздела на любом загрузочном носителе, который поддерживается службами загрузки UEFI. Загрузчик ОС UEFI может поддерживать несколько параметров, которые могут отображаться в пользовательском интерфейсе. Также возможно включить устаревшие параметры загрузки, такие как загрузка с диска A: или C: в меню загрузки прошивки платформы.
UEFI поддерживает загрузку с носителей, содержащих загрузчик ОС UEFI или системный раздел, определенный UEFI. UEFI-определенный системный раздел требуется UEFI для загрузки с блочного устройства. UEFI не требует каких-либо изменений в первом секторе раздела, поэтому можно создавать носители, которые будут загружаться как на старых архитектурах, так и на платформах UEFI.
2.1 Менеджер загрузки
UEFI содержит диспетчер загрузки, который позволяет загружать приложения, записанные в эту спецификацию (включая загрузчик 1-го этапа ОС) или драйверы UEFI из любого файла в файловой системе, определенной UEFI, или с помощью службы загрузки изображений, определенной UEFI. UEFI определяет переменные NVRAM, которые используются для указания на загружаемый файл. Эти переменные также содержат данные, специфичные для приложения, которые передаются непосредственно в приложение UEFI. Переменные также содержат читаемую пользователем строку, которая может отображаться в меню пользователю.
Переменные, определенные UEFI, позволяют прошивке системы содержать меню загрузки, которое может указывать на все операционные системы и даже на несколько версий одних и тех же операционных систем. Цель проекта UEFI состояла в том, чтобы иметь один набор загрузочных меню, которые могли бы работать в прошивке платформы. UEFI указывает только переменные NVRAM, используемые при выборе параметров загрузки. UEFI оставляет реализацию системы меню как пространство реализации добавленной стоимости.
UEFI значительно расширяет загрузочную гибкость системы по сравнению с существующим уровнем техники в системе класса PC-AT. Системы класса PC-AT в день ограничены загрузкой с первой дискеты, жесткого диска, CD-ROM, USB-ключей или сетевой карты, подключенной к системе. Загрузка с общего жесткого диска может вызвать множество проблем, связанных с операционными возможностями, между операционными системами и различными версиями операционных систем от одного и того же поставщика.
2.1.1 Изображения UEFI
UEFI Images - это класс файлов, определенных UEFI, которые содержат исполняемый код. Наиболее отличительной особенностью UEFI Images является то, что первый набор байтов в файле изображения UEFI содержит заголовок изображения, который определяет кодировку исполняемого изображения.
UEFI использует подмножество формы изображения PE32 + с измененной подписью заголовка. Изменение значения подписи в изображении PE32 + выполняется для различения изображений UEFI из обычных исполняемых файлов PE32. Добавление «+» к PE32 предоставляет 64-битные исправления для расширения в стандартном формате PE32.
Для изображений с сигнатурой изображения UEFI значения подсистемы в заголовке изображения PE определены ниже. Основные различия между типами изображений - это тип памяти, в которую встроенное ПО загружает изображение, и действие, выполняемое при выходе или возврате точки входа изображения. Образ приложения UEFI всегда выгружается, когда элемент управления возвращается из точки входа изображения. Образ драйвера UEFI выгружается только тогда, когда управление передается с кодом ошибки UEFI.
Код: Выделить всё
// PE32+ Subsystem type for EFI images
#define EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION 10
#define EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER 11
#define EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12
// PE32+ Machine type for EFI images
#define EFI_IMAGE_MACHINE_IA32 0x014c
#define EFI_IMAGE_MACHINE_IA64 0x0200
#define EFI_IMAGE_MACHINE_EBC 0x0EBC
#define EFI_IMAGE_MACHINE_x64 0x8664
#define EFI_IMAGE_MACHINE_ARMTHUMB_MIXED 0x01C2
#define EFI_IMAGE_MACHINE_AARCH64 0xAA64
#define EFI_IMAGE_MACHINE_RISCV32 0x5032
#define EFI_IMAGE_MACHINE_RISCV64 0x5064
#define EFI_IMAGE_MACHINE_RISCV128 0x5128Замечания:
Этот тип изображения выбирается так, чтобы изображения UEFI содержали инструкции Thumb и Thumb2, определяя сами интерфейсы EFI в режиме ARM.
Таблица 3. Типы памяти изображений UEFI
...
Значение Machine, найденное в заголовке файла изображения PE, используется для указания типа машинного кода изображения. Типы машинного кода для изображений с сигнатурой изображения UEFI определены ниже. Данная платформа должна реализовать тип изображения, свойственный этой платформе, и тип изображения для байтового кода EFI (EBC). Поддержка других типов машинных кодов является необязательной для платформы.
Изображение UEFI загружается в память через загрузочную службу EFI_BOOT_SERVICES.LoadImage (). Эта служба загружает изображение с форматом PE32 + в память. Этот загрузчик PE32 + необходим для загрузки всех разделов изображения PE32 + в память. Когда изображение загружается в память и выполняются соответствующие исправления, управление передается загруженному изображению на ссылку AddressOfEntryPoint в соответствии с обычными соглашениями о непрямых вызовах приложений на основе поддерживаемых 32-разрядных, 64-разрядных или 128-битные процессоры. Все другие связи с изображением UEFI и из него выполняются программно.
2.1.2 Приложения UEFI
Приложения, написанные в этой спецификации, загружаются диспетчером загрузки или другими приложениями UEFI. Чтобы загрузить приложение UEFI, прошивка выделяет достаточно памяти для хранения изображения, копирует разделы в образе приложения UEFI в выделенную память и применяет необходимые исправления для перемещения. После этого выделенная память настроена на правильный тип кода и данных для изображения. Затем управление передается в точку входа приложения UEFI. Когда приложение возвращается из своей точки входа или когда оно вызывает службу загрузки EFI_BOOT_SERVICES.Exit (), приложение UEFI выгружается из памяти, и управление возвращается компоненту UEFI, который загружает приложение UEFI.
Когда Boot Manager загружает приложение UEFI, дескриптор изображения может использоваться для поиска «параметров загрузки» для приложения UEFI.
Параметры загрузки сохраняются в энергонезависимом хранилище и связаны с приложением UEFI, которое загружается и выполняется диспетчером загрузки.
2.1.3 Погрузчики ОС UEFI
Загрузчик ОС UEFI - это специальный тип UEFI-приложения, который обычно берет на себя управление системой из прошивки, соответствующей этой спецификации. При загрузке загрузчик ОС UEFI ведет себя, как и любое другое приложение UEFI, в том, что он должен использовать только память, которую он выделил из прошивки, и может использовать только сервисы и протоколы UEFI для доступа к устройствам, которые предоставляет прошивка. Если загрузчик ОС UEFI включает в себя любые функции драйвера стиля загрузки, он должен использовать соответствующие интерфейсы UEFI для получения доступа к конкретным ресурсам шины. То есть должны быть доступны регистры устройств ввода-вывода и памяти.
через соответствующие вызовы ввода-вывода на шине, подобные тем, которые будет выполнять драйвер UEFI.
Если загрузчик ОС UEFI испытывает проблемы и не может правильно загрузить свою операционную систему, он может освободить все выделенные ресурсы и вернуть управление обратно в прошивку через вызов Boot Service Exit (). Вызов Exit () позволяет возвращать код ошибки и ExitData. ExitData содержит как возвращаемые данные, относящиеся к загрузчику строки, так и ОС.
Если загрузчик ОС UEFI успешно загружает свою операционную систему, он может получить контроль над системой с помощью службы загрузки EFI_BOOT_SERVICES.ExitBootServices (). После успешного вызова ExitBootServices () все загрузочные службы в системе завершаются, включая управление памятью, а загрузчик ОС UEFI отвечает за продолжение работы системы.
Этот тип изображения выбирается так, чтобы изображения UEFI содержали инструкции Thumb и Thumb2, определяя сами интерфейсы EFI в режиме ARM.
Таблица 3. Типы памяти изображений UEFI
...
Значение Machine, найденное в заголовке файла изображения PE, используется для указания типа машинного кода изображения. Типы машинного кода для изображений с сигнатурой изображения UEFI определены ниже. Данная платформа должна реализовать тип изображения, свойственный этой платформе, и тип изображения для байтового кода EFI (EBC). Поддержка других типов машинных кодов является необязательной для платформы.
Изображение UEFI загружается в память через загрузочную службу EFI_BOOT_SERVICES.LoadImage (). Эта служба загружает изображение с форматом PE32 + в память. Этот загрузчик PE32 + необходим для загрузки всех разделов изображения PE32 + в память. Когда изображение загружается в память и выполняются соответствующие исправления, управление передается загруженному изображению на ссылку AddressOfEntryPoint в соответствии с обычными соглашениями о непрямых вызовах приложений на основе поддерживаемых 32-разрядных, 64-разрядных или 128-битные процессоры. Все другие связи с изображением UEFI и из него выполняются программно.
2.1.2 Приложения UEFI
Приложения, написанные в этой спецификации, загружаются диспетчером загрузки или другими приложениями UEFI. Чтобы загрузить приложение UEFI, прошивка выделяет достаточно памяти для хранения изображения, копирует разделы в образе приложения UEFI в выделенную память и применяет необходимые исправления для перемещения. После этого выделенная память настроена на правильный тип кода и данных для изображения. Затем управление передается в точку входа приложения UEFI. Когда приложение возвращается из своей точки входа или когда оно вызывает службу загрузки EFI_BOOT_SERVICES.Exit (), приложение UEFI выгружается из памяти, и управление возвращается компоненту UEFI, который загружает приложение UEFI.
Когда Boot Manager загружает приложение UEFI, дескриптор изображения может использоваться для поиска «параметров загрузки» для приложения UEFI.
Параметры загрузки сохраняются в энергонезависимом хранилище и связаны с приложением UEFI, которое загружается и выполняется диспетчером загрузки.
2.1.3 Погрузчики ОС UEFI
Загрузчик ОС UEFI - это специальный тип UEFI-приложения, который обычно берет на себя управление системой из прошивки, соответствующей этой спецификации. При загрузке загрузчик ОС UEFI ведет себя, как и любое другое приложение UEFI, в том, что он должен использовать только память, которую он выделил из прошивки, и может использовать только сервисы и протоколы UEFI для доступа к устройствам, которые предоставляет прошивка. Если загрузчик ОС UEFI включает в себя любые функции драйвера стиля загрузки, он должен использовать соответствующие интерфейсы UEFI для получения доступа к конкретным ресурсам шины. То есть должны быть доступны регистры устройств ввода-вывода и памяти.
через соответствующие вызовы ввода-вывода на шине, подобные тем, которые будет выполнять драйвер UEFI.
Если загрузчик ОС UEFI испытывает проблемы и не может правильно загрузить свою операционную систему, он может освободить все выделенные ресурсы и вернуть управление обратно в прошивку через вызов Boot Service Exit (). Вызов Exit () позволяет возвращать код ошибки и ExitData. ExitData содержит как возвращаемые данные, относящиеся к загрузчику строки, так и ОС.
Если загрузчик ОС UEFI успешно загружает свою операционную систему, он может получить контроль над системой с помощью службы загрузки EFI_BOOT_SERVICES.ExitBootServices (). После успешного вызова ExitBootServices () все загрузочные службы в системе завершаются, включая управление памятью, а загрузчик ОС UEFI отвечает за продолжение работы системы.
2.1.4 Драйверы UEFI
Драйверы UEFI загружаются загрузочным менеджером, прошивкой, соответствующей этой спецификации, или другими приложениями UEFI. Чтобы загрузить драйвер UEFI, прошивка выделяет достаточное количество памяти для хранения изображения, копирует разделы в изображении драйвера UEFI в выделенную память и применяет необходимые исправления перемещения. После этого выделенная память настроена на правильный тип кода и данных для изображения. Затем управление передается во входную точку драйвера UEFI.
Когда драйвер UEFI возвращается из своей точки входа или когда он вызывает службу загрузки EFI_BOOT_SERVICES.Exit (), драйвер UEFI необязательно выгружается из памяти, и управление возвращается компоненту, загружающему драйвер UEFI. Драйвер UEFI не выгружается из памяти, если он возвращает код состояния
EFI_SUCCESS. Если код возврата драйвера UEFI является кодом состояния ошибки, тогда драйвер выгружается из памяти.
Существует два типа драйверов UEFI: драйверы загрузки и драйверы времени исполнения. Единственное различие между этими двумя типами драйверов заключается в том, что драйверы времени исполнения UEFI доступны после того, как загрузчик ОС UEFI взял управление платформой с помощью службы загрузки
EFI_BOOT_SERVICES.ExitBootServices ().
Драйверы службы загрузки UEFI прекращаются при вызове ExitBootServices (), и все ресурсы памяти, потребляемые драйверами службы загрузки UEFI, выпускаются для использования в среде операционной системы.
Драйвер времени выполнения типа EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER фиксируется с виртуальными сопоставлениями, когда ОС вызывает SetVirtualAddressMap ().
2.2 Прошивка
В этом разделе представлен обзор услуг, определенных UEFI. К ним относятся службы загрузки и службы времени выполнения.
2.2.1 Услуги UEFI
Цель интерфейсов UEFI - определить общую абстракцию загрузочной среды для использования загруженными изображениями UEFI, которые включают UEFI-драйверы, UEFI-приложения и загрузчики ОС UEFI. Вызовы определяются с полным 64-битным интерфейсом, так что есть запас для будущего роста. Цель этого набора абстрактных вызовов платформы - позволить платформе и ОС развиваться и внедряться независимо друг от друга. Кроме того, в операционных системах может использоваться стандартный набор примитивных служб времени выполнения.
Платформенные интерфейсы, определенные в этом разделе, позволяют использовать стандартные модули Plug and Play Option в качестве базовой методологии внедрения для сервисов загрузки. Интерфейсы были разработаны таким образом, чтобы отображать обратно в устаревшие интерфейсы. Эти интерфейсы никоим образом не обременены никакими ограничениями, присущими устаревшему варианту
Ромы.
Интерфейсы платформы UEFI предназначены для обеспечения абстракции между платформой и ОС, которая должна загружаться на платформе. Спецификация UEFI также обеспечивает абстрагирование между диагностическими или служебными программами и платформой; однако он не пытается реализовать полную диагностическую ОС
среда. Предполагается, что небольшую диагностическую ОС-подобную среду можно легко построить поверх системы UEFI. Такая диагностическая среда не описывается этой спецификацией.
Интерфейсы, добавленные этой спецификацией, делятся на следующие категории и подробно описаны далее в этом документе:
• Службы времени выполнения
• Интерфейсы загрузочных сервисов со следующими подкатегориями:
- Глобальные интерфейсы обслуживания загрузки
- Интерфейсы загрузки на основе дескриптора устройства
- Протоколы устройств
- Услуги протокола
2.2.2 Службы времени выполнения
В этом разделе описываются функции службы времени выполнения UEFI. Основной целью служб времени выполнения является абстрагирование второстепенных частей аппаратной реализации платформы от ОС. Служебные функции выполнения доступны во время процесса загрузки, а также во время выполнения, когда ОС переключается в режим плоской физической адресации, чтобы выполнить вызов во время выполнения. Однако, если загрузчик ОС или ОС использует службу Runtime Service SetVirtualAddressMap (), ОС сможет только вызывать службы времени выполнения в режиме виртуальной адресации. Все интерфейсы времени исполнения являются неблокирующими интерфейсами и могут быть вызваны с отключенными прерываниями, если это необходимо. Чтобы обеспечить максимальную совместимость с существующими платформами, рекомендуется, чтобы все модули UEFI, которые включают службы Runtime, были представлены в MemoryMap как один EFI_MEMORY_DESCRIPTOR типа
EfiRuntimeServicesCode.
Во всех случаях память, используемая службами времени выполнения, должна быть зарезервирована и не использоваться ОС. операционная память всегда доступна для функции UEFI и никогда не будет напрямую управляться ОС или ее компонентами. UEFI отвечает за определение аппаратных ресурсов, используемых службами времени выполнения, поэтому ОС может синхронизироваться с этими ресурсами при выполнении вызовов службы времени выполнения или гарантировать, что ОС никогда не использует эти ресурсы.
Таблица 4
перечислены функции Runtime Services.
Драйверы UEFI загружаются загрузочным менеджером, прошивкой, соответствующей этой спецификации, или другими приложениями UEFI. Чтобы загрузить драйвер UEFI, прошивка выделяет достаточное количество памяти для хранения изображения, копирует разделы в изображении драйвера UEFI в выделенную память и применяет необходимые исправления перемещения. После этого выделенная память настроена на правильный тип кода и данных для изображения. Затем управление передается во входную точку драйвера UEFI.
Когда драйвер UEFI возвращается из своей точки входа или когда он вызывает службу загрузки EFI_BOOT_SERVICES.Exit (), драйвер UEFI необязательно выгружается из памяти, и управление возвращается компоненту, загружающему драйвер UEFI. Драйвер UEFI не выгружается из памяти, если он возвращает код состояния
EFI_SUCCESS. Если код возврата драйвера UEFI является кодом состояния ошибки, тогда драйвер выгружается из памяти.
Существует два типа драйверов UEFI: драйверы загрузки и драйверы времени исполнения. Единственное различие между этими двумя типами драйверов заключается в том, что драйверы времени исполнения UEFI доступны после того, как загрузчик ОС UEFI взял управление платформой с помощью службы загрузки
EFI_BOOT_SERVICES.ExitBootServices ().
Драйверы службы загрузки UEFI прекращаются при вызове ExitBootServices (), и все ресурсы памяти, потребляемые драйверами службы загрузки UEFI, выпускаются для использования в среде операционной системы.
Драйвер времени выполнения типа EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER фиксируется с виртуальными сопоставлениями, когда ОС вызывает SetVirtualAddressMap ().
2.2 Прошивка
В этом разделе представлен обзор услуг, определенных UEFI. К ним относятся службы загрузки и службы времени выполнения.
2.2.1 Услуги UEFI
Цель интерфейсов UEFI - определить общую абстракцию загрузочной среды для использования загруженными изображениями UEFI, которые включают UEFI-драйверы, UEFI-приложения и загрузчики ОС UEFI. Вызовы определяются с полным 64-битным интерфейсом, так что есть запас для будущего роста. Цель этого набора абстрактных вызовов платформы - позволить платформе и ОС развиваться и внедряться независимо друг от друга. Кроме того, в операционных системах может использоваться стандартный набор примитивных служб времени выполнения.
Платформенные интерфейсы, определенные в этом разделе, позволяют использовать стандартные модули Plug and Play Option в качестве базовой методологии внедрения для сервисов загрузки. Интерфейсы были разработаны таким образом, чтобы отображать обратно в устаревшие интерфейсы. Эти интерфейсы никоим образом не обременены никакими ограничениями, присущими устаревшему варианту
Ромы.
Интерфейсы платформы UEFI предназначены для обеспечения абстракции между платформой и ОС, которая должна загружаться на платформе. Спецификация UEFI также обеспечивает абстрагирование между диагностическими или служебными программами и платформой; однако он не пытается реализовать полную диагностическую ОС
среда. Предполагается, что небольшую диагностическую ОС-подобную среду можно легко построить поверх системы UEFI. Такая диагностическая среда не описывается этой спецификацией.
Интерфейсы, добавленные этой спецификацией, делятся на следующие категории и подробно описаны далее в этом документе:
• Службы времени выполнения
• Интерфейсы загрузочных сервисов со следующими подкатегориями:
- Глобальные интерфейсы обслуживания загрузки
- Интерфейсы загрузки на основе дескриптора устройства
- Протоколы устройств
- Услуги протокола
2.2.2 Службы времени выполнения
В этом разделе описываются функции службы времени выполнения UEFI. Основной целью служб времени выполнения является абстрагирование второстепенных частей аппаратной реализации платформы от ОС. Служебные функции выполнения доступны во время процесса загрузки, а также во время выполнения, когда ОС переключается в режим плоской физической адресации, чтобы выполнить вызов во время выполнения. Однако, если загрузчик ОС или ОС использует службу Runtime Service SetVirtualAddressMap (), ОС сможет только вызывать службы времени выполнения в режиме виртуальной адресации. Все интерфейсы времени исполнения являются неблокирующими интерфейсами и могут быть вызваны с отключенными прерываниями, если это необходимо. Чтобы обеспечить максимальную совместимость с существующими платформами, рекомендуется, чтобы все модули UEFI, которые включают службы Runtime, были представлены в MemoryMap как один EFI_MEMORY_DESCRIPTOR типа
EfiRuntimeServicesCode.
Во всех случаях память, используемая службами времени выполнения, должна быть зарезервирована и не использоваться ОС. операционная память всегда доступна для функции UEFI и никогда не будет напрямую управляться ОС или ее компонентами. UEFI отвечает за определение аппаратных ресурсов, используемых службами времени выполнения, поэтому ОС может синхронизироваться с этими ресурсами при выполнении вызовов службы времени выполнения или гарантировать, что ОС никогда не использует эти ресурсы.
Таблица 4
перечислены функции Runtime Services.
3 Менеджер загрузки
Диспетчер загрузки UEFI - это механизм политики прошивки, который можно настроить путем изменения архитектурно определенных глобальных переменных NVRAM. Менеджер загрузки попытается загрузить UEFI-драйверы и UEFI-приложения (включая загрузчики ОС UEFI) в порядке, определяемом глобальными переменными NVRAM.
Прошивка платформы должна использовать порядок загрузки, указанный в глобальных переменных NVRAM, для нормальной загрузки. Прошивка платформы может добавить дополнительные параметры загрузки или удалить недопустимые параметры загрузки из списка заказов на загрузку.
Прошивка платформы также может реализовывать функции добавленной стоимости в диспетчере загрузки, если в процессе загрузки прошивки обнаружено исключительное условие. Одним из примеров добавленной стоимости является не загрузка драйвера UEFI, если загрузка при первом загрузке драйвера не была выполнена. Другим примером может быть загрузка в диагностическую среду, определенную OEM, если в процессе загрузки была обнаружена критическая ошибка.
Последовательность загрузки для UEFI состоит из следующего:
• Список порядка загрузки считывается из глобальной переменной NVRAM. Изменения этой переменной гарантируются только после следующего сброса платформы. Список заказов на загрузку определяет список переменных NVRAM, которые содержат информацию о том, что нужно загрузить. Каждая переменная NVRAM определяет
имя для параметра загрузки, которое может быть отображено пользователю.
• Переменная также содержит указатель на аппаратное устройство и файл на этом аппаратном устройстве, который содержит загружаемое изображение UEFI.
• Переменная может также содержать пути к разделу ОС и каталогу вместе с другими каталогами, специфичными для конфигурации.
NVRAM также может содержать параметры загрузки, которые передаются непосредственно на изображение UEFI. Прошивка платформы не знает, что содержится в параметрах загрузки. Параметры загрузки устанавливаются программным обеспечением более высокого уровня при записи в глобальную переменную NVRAM для установки политики загрузки прошивки платформы. Эта информация может использоваться для определения местоположения ядра ОС, если она отличается от местоположения загрузчика ОС UEFI.
3.1 Менеджер загрузки прошивки
Менеджер загрузки является компонентом прошивки, соответствующей этой спецификации, которая определяет, какие драйверы и приложения должны быть явно загружены и когда. После инициализации совместимой прошивки она передает управление диспетчеру загрузки. Затем диспетчер загрузки отвечает за определение загрузки и любых взаимодействий с пользователем, которые могут потребоваться для принятия такого решения.
Действия, выполняемые диспетчером загрузки, зависят от типа системы и политик, заданных разработчиком системы. Для систем, которые позволяют устанавливать новые загрузочные переменные (раздел 3.4), диспетчер загрузки должен автоматически или по запросу загруженного элемента инициализировать хотя бы одну системную консоль, а также выполнить всю требуемую инициализацию устройства, указанного в первичной загрузочной цели. Для таких систем диспетчер загрузки также должен соблюдать приоритеты, установленные в переменной BootOrder.
В частности, вероятные варианты реализации могут включать любой консольный интерфейс, касающийся загрузки, интегрированного управления платформой для выбора загрузки и возможного знания других внутренних приложений или драйверов восстановления, которые могут быть интегрированы в систему через диспетчер загрузки.
Диспетчер загрузки UEFI - это механизм политики прошивки, который можно настроить путем изменения архитектурно определенных глобальных переменных NVRAM. Менеджер загрузки попытается загрузить UEFI-драйверы и UEFI-приложения (включая загрузчики ОС UEFI) в порядке, определяемом глобальными переменными NVRAM.
Прошивка платформы должна использовать порядок загрузки, указанный в глобальных переменных NVRAM, для нормальной загрузки. Прошивка платформы может добавить дополнительные параметры загрузки или удалить недопустимые параметры загрузки из списка заказов на загрузку.
Прошивка платформы также может реализовывать функции добавленной стоимости в диспетчере загрузки, если в процессе загрузки прошивки обнаружено исключительное условие. Одним из примеров добавленной стоимости является не загрузка драйвера UEFI, если загрузка при первом загрузке драйвера не была выполнена. Другим примером может быть загрузка в диагностическую среду, определенную OEM, если в процессе загрузки была обнаружена критическая ошибка.
Последовательность загрузки для UEFI состоит из следующего:
• Список порядка загрузки считывается из глобальной переменной NVRAM. Изменения этой переменной гарантируются только после следующего сброса платформы. Список заказов на загрузку определяет список переменных NVRAM, которые содержат информацию о том, что нужно загрузить. Каждая переменная NVRAM определяет
имя для параметра загрузки, которое может быть отображено пользователю.
• Переменная также содержит указатель на аппаратное устройство и файл на этом аппаратном устройстве, который содержит загружаемое изображение UEFI.
• Переменная может также содержать пути к разделу ОС и каталогу вместе с другими каталогами, специфичными для конфигурации.
NVRAM также может содержать параметры загрузки, которые передаются непосредственно на изображение UEFI. Прошивка платформы не знает, что содержится в параметрах загрузки. Параметры загрузки устанавливаются программным обеспечением более высокого уровня при записи в глобальную переменную NVRAM для установки политики загрузки прошивки платформы. Эта информация может использоваться для определения местоположения ядра ОС, если она отличается от местоположения загрузчика ОС UEFI.
3.1 Менеджер загрузки прошивки
Менеджер загрузки является компонентом прошивки, соответствующей этой спецификации, которая определяет, какие драйверы и приложения должны быть явно загружены и когда. После инициализации совместимой прошивки она передает управление диспетчеру загрузки. Затем диспетчер загрузки отвечает за определение загрузки и любых взаимодействий с пользователем, которые могут потребоваться для принятия такого решения.
Действия, выполняемые диспетчером загрузки, зависят от типа системы и политик, заданных разработчиком системы. Для систем, которые позволяют устанавливать новые загрузочные переменные (раздел 3.4), диспетчер загрузки должен автоматически или по запросу загруженного элемента инициализировать хотя бы одну системную консоль, а также выполнить всю требуемую инициализацию устройства, указанного в первичной загрузочной цели. Для таких систем диспетчер загрузки также должен соблюдать приоритеты, установленные в переменной BootOrder.
В частности, вероятные варианты реализации могут включать любой консольный интерфейс, касающийся загрузки, интегрированного управления платформой для выбора загрузки и возможного знания других внутренних приложений или драйверов восстановления, которые могут быть интегрированы в систему через диспетчер загрузки.
3.1.1 Программирование диспетчера загрузки
Программное взаимодействие с менеджером загрузки выполняется через глобально определенные переменные. При инициализации диспетчер загрузки считывает значения, которые содержат все опубликованные параметры загрузки среди переменных среды UEFI. С помощью функции SetVariable () данные, содержащие эти переменные среды, могут быть изменены. Такие модификации гарантированно вступят в силу после начала следующей загрузки системы. Тем не менее, реализации диспетчера загрузки могут выбрать улучшение этой гарантии и изменения немедленно вступят в силу для всех последующих обращений к переменным, которые влияют на поведение диспетчера загрузки, не требуя каких-либо системных сбросов. Каждая запись параметра загрузки находится в Boot ####, Driver ####, SysPrep ####, OsRecovery #### или PlatformRecovery ####, где #### заменяется уникальным номером опции в шестнадцатеричном представлении с печатью с цифрами 0-9, а верхний в случае версий символов A-F (0000-FFFF).
#### всегда должно быть четыре цифры, поэтому маленькие числа должны использовать начальные нули. Параметры загрузки затем логически orde red массивом номеров опций, перечисленных в желаемом порядке. При загрузке обычно есть два таких списка заказов. Первым является DriverOrder, который заказывает переменные параметра загрузки драйвера #### в свой порядок загрузки. Второй - BootOrder, который заказывает параметры загрузки Boot #### в свой порядок загрузки.
Например, чтобы добавить новый параметр загрузки, будет добавлена новая переменная Boot ####. Затем номер опциона новой переменной Boot #### будет добавлен в список заказов BootOrder, и переменная BootOrder будет перезаписана.
Чтобы изменить параметр загрузки в существующем Boot ####, необходимо перезаписать только переменную Boot ####. Аналогичная операция будет выполнена для добавления, удаления или изменения списка загрузки драйверов.
Если загрузка через Boot #### возвращается со статусом EFI_SUCCESS, прошивка платформы поддерживает меню диспетчера загрузки, и если встроенное ПО настроено на загрузку в интерактивном режиме, диспетчер загрузки прекратит обработку переменной BootOrder и представит меню диспетчера загрузки для пользователя. Если какое-либо из вышеупомянутых условий не выполняется, следующая загрузка #### в переменной BootOrder будет проверяться до тех пор, пока все возможности не будут исчерпаны.
В этом случае необходимо выполнить восстановление загрузки (см. Раздел 3.4).
Менеджер загрузки может выполнять автоматическое ведение переменных базы данных. Например, он может удалять переменные необязательной загрузки или любые переменные параметра загрузки, которые не могут быть проанализированы, и он может переписать любой упорядоченный список, чтобы удалить любые параметры загрузки, у которых нет соответствующих переменных переменной загрузки. Менеджер загрузки также может по своему усмотрению предоставить администратору возможность запускать ручное обслуживание
также. Примеры включают в себя выбор порядка любых или всех параметров загрузки, активацию или деактивацию параметров загрузки, инициирование ОС или определение на платформе и т. Д. Кроме того, если платформа намеревается создать PlatformRecovery ####, перед попыткой загрузить и выполнить любые записи DriverOrder или BootOrder, прошивка должна создать любые переменные PlatformRecovery #### (см. раздел 3.4.2). При нормальной работе прошивка не должна автоматически удалять любую правильно сформированную переменную Boot ####, на которую ссылаются в настоящее время переменные BootOrder или BootNext. Такое удаление должно быть ограничено сценариями, в которых встроенное ПО руководствуется прямым взаимодействием с пользователем.
Содержимое PlatformRecovery #### представляет окончательные варианты восстановления, которые прошивка попыталась бы, если бы восстановление было начато во время текущей загрузки, и не обязательно включать записи, чтобы отражать непредвиденные обстоятельства, такие как значительная аппаратная реконфигурация, или записи, соответствующие конкретному оборудованию, которое прошивка пока не осознает.
На поведение диспетчера загрузки UEFI влияет, когда включена безопасная загрузка, см. Раздел 31.4.
Программное взаимодействие с менеджером загрузки выполняется через глобально определенные переменные. При инициализации диспетчер загрузки считывает значения, которые содержат все опубликованные параметры загрузки среди переменных среды UEFI. С помощью функции SetVariable () данные, содержащие эти переменные среды, могут быть изменены. Такие модификации гарантированно вступят в силу после начала следующей загрузки системы. Тем не менее, реализации диспетчера загрузки могут выбрать улучшение этой гарантии и изменения немедленно вступят в силу для всех последующих обращений к переменным, которые влияют на поведение диспетчера загрузки, не требуя каких-либо системных сбросов. Каждая запись параметра загрузки находится в Boot ####, Driver ####, SysPrep ####, OsRecovery #### или PlatformRecovery ####, где #### заменяется уникальным номером опции в шестнадцатеричном представлении с печатью с цифрами 0-9, а верхний в случае версий символов A-F (0000-FFFF).
#### всегда должно быть четыре цифры, поэтому маленькие числа должны использовать начальные нули. Параметры загрузки затем логически orde red массивом номеров опций, перечисленных в желаемом порядке. При загрузке обычно есть два таких списка заказов. Первым является DriverOrder, который заказывает переменные параметра загрузки драйвера #### в свой порядок загрузки. Второй - BootOrder, который заказывает параметры загрузки Boot #### в свой порядок загрузки.
Например, чтобы добавить новый параметр загрузки, будет добавлена новая переменная Boot ####. Затем номер опциона новой переменной Boot #### будет добавлен в список заказов BootOrder, и переменная BootOrder будет перезаписана.
Чтобы изменить параметр загрузки в существующем Boot ####, необходимо перезаписать только переменную Boot ####. Аналогичная операция будет выполнена для добавления, удаления или изменения списка загрузки драйверов.
Если загрузка через Boot #### возвращается со статусом EFI_SUCCESS, прошивка платформы поддерживает меню диспетчера загрузки, и если встроенное ПО настроено на загрузку в интерактивном режиме, диспетчер загрузки прекратит обработку переменной BootOrder и представит меню диспетчера загрузки для пользователя. Если какое-либо из вышеупомянутых условий не выполняется, следующая загрузка #### в переменной BootOrder будет проверяться до тех пор, пока все возможности не будут исчерпаны.
В этом случае необходимо выполнить восстановление загрузки (см. Раздел 3.4).
Менеджер загрузки может выполнять автоматическое ведение переменных базы данных. Например, он может удалять переменные необязательной загрузки или любые переменные параметра загрузки, которые не могут быть проанализированы, и он может переписать любой упорядоченный список, чтобы удалить любые параметры загрузки, у которых нет соответствующих переменных переменной загрузки. Менеджер загрузки также может по своему усмотрению предоставить администратору возможность запускать ручное обслуживание
также. Примеры включают в себя выбор порядка любых или всех параметров загрузки, активацию или деактивацию параметров загрузки, инициирование ОС или определение на платформе и т. Д. Кроме того, если платформа намеревается создать PlatformRecovery ####, перед попыткой загрузить и выполнить любые записи DriverOrder или BootOrder, прошивка должна создать любые переменные PlatformRecovery #### (см. раздел 3.4.2). При нормальной работе прошивка не должна автоматически удалять любую правильно сформированную переменную Boot ####, на которую ссылаются в настоящее время переменные BootOrder или BootNext. Такое удаление должно быть ограничено сценариями, в которых встроенное ПО руководствуется прямым взаимодействием с пользователем.
Содержимое PlatformRecovery #### представляет окончательные варианты восстановления, которые прошивка попыталась бы, если бы восстановление было начато во время текущей загрузки, и не обязательно включать записи, чтобы отражать непредвиденные обстоятельства, такие как значительная аппаратная реконфигурация, или записи, соответствующие конкретному оборудованию, которое прошивка пока не осознает.
На поведение диспетчера загрузки UEFI влияет, когда включена безопасная загрузка, см. Раздел 31.4.
3.1.2 Обработка опций загрузки
Менеджер загрузки должен обрабатывать записи параметров загрузки драйвера перед вводом параметров загрузки загрузки. Если бит EFI_OS_INDICATIONS_START_OS_RECOVERY установлен в OsIndications, прошивка должна попытаться восстановить ОС (см. Раздел 3.4.1), а не обычную загрузку. Если бит бит EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY установлен в OsIndications, микропрограммное обеспечение должно попытаться восстановить платформу (см. Раздел 3.4.2), а не обычную загрузку или обработку бита EFI_OS_INDICATIONS_START_OS_RECOVERY. В любом случае оба бита должны быть очищены.
В противном случае менеджер загрузки также должен инициировать загрузку параметра загрузки, указанного в переменной BootNext, в качестве первой опции загрузки при следующей загрузке и только при следующей загрузке. Менеджер загрузки удаляет переменную BootNext перед передачей элемента управления Bootnext. После попытки загрузки BootNext используется обычный список BootOrder. Чтобы предотвратить цикл, диспетчер загрузки удаляет BootNext перед передачей элемента управления предварительно выбранному параметру загрузки.
Если все записи BootNext и BootOrder были исчерпаны без успеха или если микропрограмме было поручено выполнить восстановление заказа на загрузку, прошивка должна попытаться восстановить параметры загрузки (см. Раздел 3.4).
Менеджер загрузки должен вызвать EFI_BOOT_SERVICES.LoadImage (), который поддерживает по меньшей мере EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
и EFI_LOAD_FILE_PROTOCOL для разрешения параметров загрузки. Если LoadImage () успешно завершен, менеджер загрузки должен включить сторожевой таймер в течение 5 минут, используя службу загрузки EFI_BOOT_SERVICES.SetWatchdogTimer ()
перед вызовом EFI_BOOT_SERVICES.StartImage (). Если параметр загрузки возвращает управление диспетчеру загрузки, диспетчер загрузки должен отключить сторожевой таймер с дополнительным вызовом службы загрузки SetWatchdogTimer ().
Если загрузочный образ не загружается через EFI_BOOT_SERVICES.LoadImage (), менеджер загрузки должен проверить загрузку приложения по умолчанию. Поиск загружаемого приложения по умолчанию происходит как на съемных, так и на фиксированных типах носителей. Этот поиск происходит, когда путь устройства к загрузочному изображению, указанному в любом параметре загрузки, указывает прямо на устройство EFI_SIMPLE_FILE_SYSTEM_PROTOCOL и не указывает точный файл для загрузки. Метод обнаружения файлов объясняется в разделе 3.4. По умолчанию загрузочный файл по умолчанию для протокола, отличного от EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, обрабатывается EFI_LOAD_FILE_PROTOCOL для целевого пути устройства и не требует обработки диспетчера загрузки.
Менеджер загрузки UEFI должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первый элемент является WWID WWW (см. Таблицу 61) или интерфейсом USB класса (см. Таблицу 63). Для USB WWID менеджер загрузки должен использовать идентификатор поставщика устройства, идентификатор продукта устройства и серийный номер и должен соответствовать любому USB-устройству в системе, которая содержит эту информацию. Если более одного устройства соответствуют пути устройства USB WWID, менеджер загрузки выбирает один произвольно. Для USB-класса диспетчер загрузки должен использовать идентификатор поставщика, идентификатор продукта, класс устройства, подкласс устройства и протокол устройства и должен соответствовать любому USB-устройству в системе, которая содержит эту информацию. Если какой-либо идентификатор, идентификатор продукта, класс устройства, подкласс устройства или протокол устройства содержат все F (0xFFFF или 0xFF), этот элемент пропускается с целью сопоставления. Если более одного устройства соответствуют пути устройства USB-класса, менеджер загрузки выбирает один произвольно.
Менеджер загрузки также должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первый элемент является каналом носителя жесткого диска (см. Таблицу 86). Менеджер загрузки должен использовать идентификатор GUID или номер подписи и раздела на пути устройства жесткого диска, чтобы он соответствовал устройству в системе. Если привод поддерживает схему разбиения на GPT, GUID на пути устройства носителя жесткого диска сравнивается с полем UniquePartitionGuid в записи раздела GUID (см. Таблицу 18). Если привод поддерживает схему MBR PC-AT, сигнатура на пути носителя носителя жесткого диска сравнивается с уникальной меткойMBRSignature в базовой загрузочной записи Legacy (см. Таблицу 13). Если выполняется соответствие подписи, то номер раздела также должен быть сопоставлен. Путь устройства жесткого диска может быть добавлен к соответствующему пути аппаратного устройства, и тогда можно будет использовать обычное поведение загрузки. Если более одного устройства соответствует пути устройства жесткого диска, менеджер загрузки выбирает один произвольно. Таким образом, операционная система должна гарантировать уникальность воспламенения на жестких дисках, чтобы гарантировать детерминированное поведение загрузки.
Менеджер загрузки также должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первым элементом является путь пути к файлу пути (см. Таблицу 89). Когда диспетчер загрузок попытается загрузить путь с пустым файловым путём, он перечислит все съемные мультимедийные устройства, а затем все фиксированные мультимедийные устройства, создав параметры загрузки для каждого устройства.
Менеджер загрузки должен обрабатывать записи параметров загрузки драйвера перед вводом параметров загрузки загрузки. Если бит EFI_OS_INDICATIONS_START_OS_RECOVERY установлен в OsIndications, прошивка должна попытаться восстановить ОС (см. Раздел 3.4.1), а не обычную загрузку. Если бит бит EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY установлен в OsIndications, микропрограммное обеспечение должно попытаться восстановить платформу (см. Раздел 3.4.2), а не обычную загрузку или обработку бита EFI_OS_INDICATIONS_START_OS_RECOVERY. В любом случае оба бита должны быть очищены.
В противном случае менеджер загрузки также должен инициировать загрузку параметра загрузки, указанного в переменной BootNext, в качестве первой опции загрузки при следующей загрузке и только при следующей загрузке. Менеджер загрузки удаляет переменную BootNext перед передачей элемента управления Bootnext. После попытки загрузки BootNext используется обычный список BootOrder. Чтобы предотвратить цикл, диспетчер загрузки удаляет BootNext перед передачей элемента управления предварительно выбранному параметру загрузки.
Если все записи BootNext и BootOrder были исчерпаны без успеха или если микропрограмме было поручено выполнить восстановление заказа на загрузку, прошивка должна попытаться восстановить параметры загрузки (см. Раздел 3.4).
Менеджер загрузки должен вызвать EFI_BOOT_SERVICES.LoadImage (), который поддерживает по меньшей мере EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
и EFI_LOAD_FILE_PROTOCOL для разрешения параметров загрузки. Если LoadImage () успешно завершен, менеджер загрузки должен включить сторожевой таймер в течение 5 минут, используя службу загрузки EFI_BOOT_SERVICES.SetWatchdogTimer ()
перед вызовом EFI_BOOT_SERVICES.StartImage (). Если параметр загрузки возвращает управление диспетчеру загрузки, диспетчер загрузки должен отключить сторожевой таймер с дополнительным вызовом службы загрузки SetWatchdogTimer ().
Если загрузочный образ не загружается через EFI_BOOT_SERVICES.LoadImage (), менеджер загрузки должен проверить загрузку приложения по умолчанию. Поиск загружаемого приложения по умолчанию происходит как на съемных, так и на фиксированных типах носителей. Этот поиск происходит, когда путь устройства к загрузочному изображению, указанному в любом параметре загрузки, указывает прямо на устройство EFI_SIMPLE_FILE_SYSTEM_PROTOCOL и не указывает точный файл для загрузки. Метод обнаружения файлов объясняется в разделе 3.4. По умолчанию загрузочный файл по умолчанию для протокола, отличного от EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, обрабатывается EFI_LOAD_FILE_PROTOCOL для целевого пути устройства и не требует обработки диспетчера загрузки.
Менеджер загрузки UEFI должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первый элемент является WWID WWW (см. Таблицу 61) или интерфейсом USB класса (см. Таблицу 63). Для USB WWID менеджер загрузки должен использовать идентификатор поставщика устройства, идентификатор продукта устройства и серийный номер и должен соответствовать любому USB-устройству в системе, которая содержит эту информацию. Если более одного устройства соответствуют пути устройства USB WWID, менеджер загрузки выбирает один произвольно. Для USB-класса диспетчер загрузки должен использовать идентификатор поставщика, идентификатор продукта, класс устройства, подкласс устройства и протокол устройства и должен соответствовать любому USB-устройству в системе, которая содержит эту информацию. Если какой-либо идентификатор, идентификатор продукта, класс устройства, подкласс устройства или протокол устройства содержат все F (0xFFFF или 0xFF), этот элемент пропускается с целью сопоставления. Если более одного устройства соответствуют пути устройства USB-класса, менеджер загрузки выбирает один произвольно.
Менеджер загрузки также должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первый элемент является каналом носителя жесткого диска (см. Таблицу 86). Менеджер загрузки должен использовать идентификатор GUID или номер подписи и раздела на пути устройства жесткого диска, чтобы он соответствовал устройству в системе. Если привод поддерживает схему разбиения на GPT, GUID на пути устройства носителя жесткого диска сравнивается с полем UniquePartitionGuid в записи раздела GUID (см. Таблицу 18). Если привод поддерживает схему MBR PC-AT, сигнатура на пути носителя носителя жесткого диска сравнивается с уникальной меткойMBRSignature в базовой загрузочной записи Legacy (см. Таблицу 13). Если выполняется соответствие подписи, то номер раздела также должен быть сопоставлен. Путь устройства жесткого диска может быть добавлен к соответствующему пути аппаратного устройства, и тогда можно будет использовать обычное поведение загрузки. Если более одного устройства соответствует пути устройства жесткого диска, менеджер загрузки выбирает один произвольно. Таким образом, операционная система должна гарантировать уникальность воспламенения на жестких дисках, чтобы гарантировать детерминированное поведение загрузки.
Менеджер загрузки также должен поддерживать загрузку с короткого пути устройства, который начинается с того, что первым элементом является путь пути к файлу пути (см. Таблицу 89). Когда диспетчер загрузок попытается загрузить путь с пустым файловым путём, он перечислит все съемные мультимедийные устройства, а затем все фиксированные мультимедийные устройства, создав параметры загрузки для каждого устройства.
Курс по Линукс Минт
Добавлено: 30 ноя 2018, 09:42
Правильно, потому, что он (код) не нужен для загрузки в режиме UEFI (UEFI загружает образ загрузчика из файла, а не через код в MBR).Загрузочный код на MBR не выполняется с помощью прошивки UEFI.
Курс по Линукс Минт
Добавлено: 02 дек 2018, 00:35
Жизни не хватит..
И всё это блекнет, если вендор по-своему реализовал. С практической точки зрения важнее знать как этот UEFI реализован в определенных марках-моделях таких-то годов..
Хватит одного вечера чтобы выяснить все 4 ситуации (в Курс по Линукс Минт (Пост AlexZ #69987))
С этого и начали..StarMAUGLI писал(а): ↑30 ноя 2018, 04:07Т.е. что бы подвести итог дискуссии
Загрузочный код на MBR не выполняется с помощью прошивки UEFI.
В ходе дискуссии решили рассматривать UEFI в целом, а этот тип относится к эмуляции BIOS - Legacy (модуль CSM и т.п.), т.е. UEFI-Legacy / MBR. Вот на этом желательно сделать акцент, потому как очень мало кто это понимает до конца и в итоге.. "километры постов"..
И я бы ещё выделил убунтовый установщик, который умеет "на лету" переключаться с UEFI / MBR на Legacy / MBR, что конечно облегчает (новичкам) установку на ноуты Acer как минимум (сюда же как понимаю относятся eMachines и Packard Bell)
Курс по Линукс Минт
Добавлено: 02 дек 2018, 01:12
Курс по Линукс Минт
Добавлено: 02 дек 2018, 08:54
А по мне проще переустановить, чем корячиться с восстановлением. Заметил, что даже при клонировании диска (например при переходе с HDD на SSD) система (Windows) на том же железе в общем начинает работать хуже, число глюков увеличивается. А Linux Mint вообще почему то отказался запускаться, вернее запускался, но после появления экрана с ярлычками работал несколько секунд и перезагружался. Пытался запускать с другим ядром - работал только до перезагрузки да и работал с глюками, тормозами, зависаниями. Плюнул - переустановил. Ну а LM 19 даже на SSD установить не смог. Видимо мой старенький Vertex4 ему не понравился (На SSD a-Data установился нормально). Но я для LM предназначил именно Vertex4 - поставил туда LM 18.3 и LMDE 3 Cindy Mate, поделив диск 128 пополам. Сделал общий EFI раздел на 100МБ но отдельные / и /home, хотя обе оси друг друга видят(и свои и чужие разделы). GRUB на свой EFI раздел установить не удалось. Установился только на диск SSD A-Data, на котором винда. В общем устраивает. Всё равно эти 2 SSD диска будут работать в паре на одном компе. Как то так. Вот ещё отсюда попробую
https://wiki.debian.org/GrubEFIReinstall
(Спасибо darkfenix, )
Курс по Линукс Минт
Добавлено: 08 дек 2018, 23:23
Так-то конечно лучше с нуля поставить, но случаи всякие бывают (слишком много своих настроек, софта и т.д.)
А при клонировании-восстановлении да, бывают всякие нюансы, в каждом индивидуальном случае..
Курс по Линукс Минт
Добавлено: 08 дек 2018, 23:36
Переставил глючный Vertex4 на ноутбук склонировав на него стоящие на ноуте инсайдерскую 10 винду (активация не пропала) и LMDE 3 Cindy Mate. На ноуте всё нормально работает. С ноута же поставил на основной десктоп диск Vertex3 (который у меня никогда не глючил). На него с нуля поставил Тессу бетку и тот же LMDE by Chocobo. И тоже всё нормально работает. А говорят, что от перемены слагаемых сумма не меняется. Сейчас восстанавливаю все пакеты и настройки. Скорость запуска на SSD офигенная - буквально несколько секунд и можно работать.