Os boot: Немного про UEFI и Secure Boot / Хабр

Немного про UEFI и Secure Boot / Хабр

UEFI

UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.

Основные отличия UEFI от BIOS:

• Поддержка GPT (GUID Partition Table)

GPT — новый способ разметки, замена MBR. В отличие от MBR, GPT поддерживает диски размером более 2ТБ и неограниченное количество разделов, в то время как MBR поддерживает без костылей только 4. UEFI по умолчанию поддерживает FAT32 с GPT-разделов. MBR сам UEFI не поддерживает, поддержка и загрузка с MBR осуществляется расширением CSM (Compatibility Support Module).

• Поддержка сервисов

В UEFI есть два типа сервисов: boot services и runtime services. Первые работают только до загрузки ОС и обеспечивают взаимодействие с графическими и текстовыми терминалами, шинами, блочными устройствами и т.д., а runtime services может использовать ОС. Один из примеров runtime services — variable service, который хранит значения в NVRAM. ОС Linux использует variable service для хранения креш дампов, которые можно вытащить после перезагрузки компьютера.

• Модульная архитектура

Вы можете использовать свои приложения в UEFI. Вы можете загружать свои драйверы в UEFI. Нет, правда! Есть такая штука, как UEFI Shell. Некоторые производители включают его в свой UEFI, но на моем лаптопе (Lenovo Thinkpad X220) его нет. Но можно его просто скачать из интернета и поставить на флешку или жесткий диск. Также существуют драйверы для ReiserFS, ext2/3/4 и, возможно, еще какие-то, я слишком не углублялся. Их можно загрузить из UEFI Shell и гулять по просторам своей файловой системы прямо из UEFI.
Еще UEFI поддерживает сеть, так что если найдете UEFI-драйвер к своей сетевой карте, или если он включен производителем материнской платы, то можете попинговать 8. 8.8.8 из Shell.
Вообще, спецификация UEFI предусматривает взаимодействия драйверов UEFI из ОС, т.е. если у вас в ОС нет драйвера на сетевую карту, а в UEFI он загружен, то ОС сможет использовать сетевую карту через UEFI, однако таких реализаций я не встречал.

• Встроенный менеджер загрузки

В общем случае, для UEFI не требуется ставить загрузчик, если вы хотите мультизагрузку. Можно добавлять свои пункты меню, и они появятся в загрузочном меню UEFI, прямо рядом с дисками и флешками. Это очень удобно и позволяет грузить Linux вообще без загрузчика, а сразу ядро. Таким образом, можно установить Windows и Linux без сторонних загрузчиков.

Как происходит загрузка в UEFI?

С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.

Secure Boot

Я видел много вопросов в интернете, вроде:

«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»

Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!

Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.

В Secure Boot есть 2 режима: Setup и User. Первый режим служит для настройки, из него вы можете заменить PK (Platform Key, по умолчанию стоит от OEM), KEK (Key Exchange Keys), db (база разрешенных ключей) и dbx (база отозванных ключей). KEK может и не быть, и все может быть подписано PK, но так никто не делает, вроде как. PK — это главный ключ, которым подписан KEK, в свою очередь ключами из KEK (их может быть несколько) подписываются db и dbx. Чтобы можно было запустить какой-то подписанный .efi-файл из-под User-режима, он должен быть подписан ключом, который в db, и не в dbx.

Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.

В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.

Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.

Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.

Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.

Спасибо за внимание!

Boot List Option — выбор варианта загрузки UEFI — Legacy (с фото)

Опция  Boot List Option — Выбор варианта загрузки определяем режим загрузки и меет два значения «Legacy» — (наследуемый вариант загрузки — режим совместимости) BIOS или «UEFI» (Unified Extensible Firmware Interface — интерфейс между операционной системой и микропрограммами) режим загрузки. 

UEFI BIOS поддерживает два режима загрузки: режим загрузки Legacy («Наследие») BIOS и режим загрузки UEFI.

Некоторые устройства и операционные системы пока не поддерживают UEFI на основе BIOS и могут загружаться только с режиме загрузки — Legacy BIOS.

В зависимости от вашей ситуации, вы выбираете какой режим загрузки из UEFI BIOS вы хотите использовать: режим загрузки Наследия — Legacy BIOS или режим UEFI загрузки.

Значения опции:

1. Legacy  ( CMS OS или  CSM Boot,  UEFI and Legacy OS, Legacy OpROM) – выберите режим загрузки Legacy BIOS, чтобы HBAs-адаптеры и некоторые экспресс — модули могли использовать опции  ROMs — ПЗУ.   При выборе режима загрузки Legacy BIOS, только загрузочные кандидаты поддерживающие режим загрузки Legacy  BIOS будут перечислены в списке «Приоритет  — Параметры загрузки».  НЕ забываем при выборе данной опции
   1) отключить очень капризную опцию Secure Boot —  защищенной загрузки. А так же включить модуль
   2) Load Legacy Option Rom — CSM — загрузку модуля совместимости старых ОС.
2. UEFI (UEFI OS) – выберите режим загрузки UEFI что бы использовать драйверы UEFI.  Только устройства, поддерживающие выбранный режим загрузки перечислены на экране выбора источника загрузки BIOS  — экране в списке Приоритетов Параметры загрузки.

Более подробно о недостатках и достоинствах «нового БИОСА — UEFI —  интерфейс прошивки» написано здесь (uefi bios настройка).

Опция также может иметь другие названия:

1. Boot List Option
2. Launch CSM (Compatibility Support Module)
3. CMS Boot
4. UEFI and Legacy OS
5. CMS OS
6. Boot Mode
7. OS Mode Selection

Примечание 1. Если режим загрузки  (Boot List Option) изменяется, то выставленная последовательность опроса носителей — дисков — кандидатов от предыдущего режима загрузки  не сохраняется..

Примечание 2. Загрузчик операционной системы – это системная программа, которая подготовляет компьютер для загрузки операционной системы (загружает ядро операционной системы в оперативную память, формирует параметры работы ОС…). Запуск загрузчика выполняет BIOS.

Программа Aptio Setup Utility — BIOS фирмы American Megatrends Inc на системных платах Dell Inc.

Название данной опции у данного производителя в данной версии BIOS:

Boot List Option значение по умолчанию  [Legacy]

Возможное значение:

Еще по настройке БИОС (БИОЗ) плат:

Как выключить функцию Intel® Boot Agent или предотвратить ее запуск

Что такое функция Intel® Boot Agent?

Intel® Boot Agent — это микропрограммное обеспечение сетевой интерфейсной платы. Функция Intel® Boot Agent позволяет подключенному к сети клиентскому компьютеру загружаться с помощью образа на удаленном сервере. Поставщики ПК могут активировать функцию Intel® Boot Agent для использования различных сред и протоколов. BIOS добавляет функцию Intel® Boot Agent в список загрузочных устройств. Если функция Intel® Boot Agent находится в списке выше любого другого загрузочного устройства, она будет запущена и попытается выполнить загрузку компьютера через сеть.

Функцию Intel® Boot Agent отключают при использовании дополнительных адаптеров, установленных в разъемы PCI, PCI-X или PCI Express*.

Если вы используете встроенный сетевой адаптер, см. документацию к своему компьютеру. Обычно настройки, используемые для выключения или включения функции Boot Agent, находятся в системной BIOS.

Имейте в виду, что эта информация не относится к ноутбукам. Чтобы отключить функцию Intel® Boot Agent, откройте настройки BIOS вашего компьютера.

Как остановить работу функции Intel® Boot Agent?

Вы можете:

• Предотвратить выполнение функции Intel® Boot Agent.
• Отключить функцию Intel® Boot Agent или предотвратить ее запуск с помощью служебной программы.

Для предотвращения запуска функции Intel® Boot Agent:

1. Перейдите в BIOS и найдите настройки последовательности загрузочных устройств.
2. Переместите функцию Boot Agent вниз списка после жесткого диска или устройства, с которого вы предпочитаете выполнять загрузку.

Для предотвращения инициализации функции Intel® Boot Agent используйте служебную программу Intel® Ethernet Flash Firmware Utility (BootUtil.exe). Приложение Intel Ethernet Flash Firmware Utility является программой, которая:

• Изменяет настройки по умолчанию вашего сетевого Ethernet-адаптера Intel®.
• Включает или отключает функцию Wake-on-LAN.
• Включает или отключает возможности и настройки функции Intel® Boot Agent.
• Может использоваться для обновления образа, находящегося во флэш-компоненте сетевой платы.

Пакет загрузки программы содержит версии для сред DOS, Windows*, Linux* и UEFI. В него также входит руководство по использованию функции Intel® Boot Agent. Запустите файл index.htm, чтобы открыть руководство с подробными указаниями по выключению функции Intel® Boot Agent.

Инструкции по использованию программы Intel® Ethernet Flash Firmware Utility.

Загрузка программы Intel® Ethernet Flash Firmware Utility (BootUtil.exe).

Как установить приложение Intel® Ethernet Flash Firmware Utility?

В среде DOS или UEFI программу можно запустить из папки, содержащей ОС. Произойдет ошибка, если вы попытаетесь запустить версию программы для DOS в окне командной строки Windows*. Версия для DOS работает только в ОС DOS.

В ОС Linux* и Windows* вы должны сначала запустить программу установки.

Программы установки и загрузки находятся в каталоге вашей ОС во вложенной папке \APPS\BootUtil. Если в папке для вашей ОС содержится программа установки, запустите ее перед использованием функции Intel Boot Utility.

Установка загрузочной программы в ОС Windows* перезапишет файлы, необходимые для ПО Intel® PROSet для Диспетчера устройств Windows. После ее установки могут начаться проверки системных ошибок или потеря функциональности ПО Intel® PROSet, или других программ, работающих с этим же драйвером. Удалите ПО Intel® PROSet перед установкой программы. После использования программы вновь установите ПО Intel® PROSet. Повторная установка ПО Intel® PROSet перезапишет файлы, которые использовались программой.

Настройки функции Intel® Boot Agent

Функция Intel® Boot Agent активируется во время запуска системы, даже если она не является первым загрузочным устройством. Чтобы изменить настройки функции Intel® Boot Agent, нажмите клавиши Ctrl+S после отображения экрана инициализации.

• На адаптерах для настольных ПК: функция Intel® Boot Agent включена по умолчанию.
• На серверных адаптерах: функция Intel® Boot Agent выключена по умолчанию.

Boot to OS/2, OS Select For DRAM > 64M

Другие идентичные по назначению опции: OS Select For DRAM > 64M.

Функция BIOS Boot to OS/2 предлагает пользователю выбрать режим загрузки компьютера, совместимый со старыми версиями операционной системы OS/2. Пользователю доступны два варианта – Yes, No (Да, Нет).

Содержание статьи

Принцип работы

Для начала разберемся с тем, что вообще представляет собой OS/2 и для чего понадобилась подобный параметр. OS/2 является операционной системой, разработанной IBM для ряда своих компьютеров в конце 1980-x гг., и разрабатывавшейся вплоть до середины 1990-х. В настоящее время операционная система OS/2 используется лишь в некоторых компьютерных сетях, а поддержка ее со стороны IBM была прекращена в середине 2000-х гг.

Поскольку в настоящее время ОС OS/2, а тем более,  ее старые версии, для которых и предназначена опция, используются довольно редко, то она не может считаться актуальной для большинства пользователей современных компьютеров и представляет большей частью лишь исторический интерес. Тем не менее, мы все же приведем краткую информацию о ней.

На момент своей разработки ОС OS/2 считалась передовой и по многим параметрам превосходила Microsoft Windows. Тем не менее, работа этой операционной системы отличалась рядом технических особенностей. В частности, в старых версиях этой операционной системы применялся метод работы с памятью, несовместимый с методами, которые используются в других операционных системах, например, в системах семейства Microsoft Windows, что приводило к неправильному определению объема оперативной памяти. Причем эта особенность обычно проявляется лишь в том случае, если в персональном компьютере установлено более 64 МБ памяти.

Таким образом, опция BIOS Boot to OS/2 предназначена для того, чтобы устранить недостаток при определении объема оперативной памяти, и операционная система OS/2 старых версий могла бы функционировать на компьютере без проблем.

Следует отметить, что начиная с версии OS/2 Warp v3.0, управление памятью в операционной системе OS/2 было приведено в соответствие с общепринятыми стандартами, и поэтому надобность в этой опции отпала. Кроме того, даже в версиях  OS/2, более старых, чем Warp v3.0, может быть установлен специальный пакет обновлений FixPacks, который также исправляет тот метод, при помощи которого операционная система работала  с оперативной  памятью.

Стоит ли включать опцию?

Ответ на этот вопрос зависит от того, какая ОС установлена на персональном компьютере. Если в этом качестве используется какая-либо операционная система семейства Microsoft Windows, то необходимо  указать значение опции No. То же самое относится и к тому случаю, если на персональном компьютере установлена ОС семейства IBM OS/2 версии Warp v3.0 или более новая, а также к тому случаю, если используется операционная система OS/2 старой версии, но при этом установлен пакет обновлений от IBM FixPacks.

Если же на персональном компьютере используется операционная система OS/2 версии более старой, чем Warp v3. 0, и не установлен пакет FixPacks, то должен быть выбран вариант Yes.

Что произойдет в том случае, если все же включить данную опцию на компьютере с операционной системой Microsoft Windows или операционной системой OS/2 Warp v3.0? В случае операционной системы OS/2 новых версий, а также исправленных при помощи пакета обновлений FixPacks, компьютер неправильно определит количество доступной оперативной памяти. В том случае, если в системе будет присутствовать 64 МБ ОЗУ или менее, то компьютеру будет доступно всего лишь 16 МБ ОЗУ. При условии наличия в компьютере памяти большего объема, чем 64 МБ, системе будет доступно всего лишь 64 МБ.

В случае включения опции в компьютере с операционной системой Microsoft Windows, помимо проблем с определением памяти в операционной системе, после загрузки операционная система будет работать с ошибками.

Порекомендуйте Друзьям статью:

В анонимной ОС Tails 4.5 на базе Debian реализована поддержка Secure Boot

Выпущена новая версия операционной системы Tails (The Amnesic Incognito Live System, Анонимная Операционная Система) – специализированного дистрибутива Linux на Debian, обеспечивающего пользователю конфиденциальность и анонимность в Интернете. Отныне ОС Tails 4.5 поддерживает долгожданную функцию безопасной загрузки «Secure Boot», и кроме того получила обновления для функций безопасности и прикладного программного обеспечения.

Ранее, в выпущенной месяц  назад версии Tails 4.4, не было поддержки компьютеров с включенной в UEFI функции безопасной загрузки. По словам команды разработчиков Tails, данное обновление ОС позволяет загружать дистрибутив на компьютерах с функцией Secure Boot, включая Mac. Но если выдается сообщение об ошибке «Настройки безопасности не позволяют этому компьютеру Mac использовать внешний загрузочный диск», необходимо изменить настройки утилиты безопасности при загрузке Mac, чтобы запустить Tails.

«В течение многих лет отсутствие поддержки Secure Boot было одним из основных источников проблем с продуктом, на которое больше всего жаловались в техподдержку, и которое мешало менее опытным пользователям переходить на Tails», – сообщили в команде Tails.

Также в обновление Tails 4. 5 входит последняя версия анонимного браузера Tor Browser 9.0.9, основанная на Mozilla Firefox 68.7 ESR, которая включает несколько исправлений известных уязвимостей.

В Tails 4.5 также исправлены проблемы с безопасностью, которые были в предыдущем выпуске Tails 4.4.1, включая недостатки, обнаруженные в пакетах BlueZ и GnuTLS. И ещё получены все последние обновления из репозиториев Debian GNU / Linux 10 «Buster».

Скачать дистрибутив анонимной операционной системы можно по ссылке. Запускать ОС Tails можно и с USB-накопителя, предварительно записав туда загруженный образ ISO.

Выход следующего обновления дистрибутива (Tails 4.6) в настоящее время запланирован на 5 мая 2020 года.

Если вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER.

Super UEFIinSecureBoot Disk — запуск любых ОС и .efi-файлов с флешки без отключения UEFI Secure Boot — Open Source — Новости

Super UEFIinSecureBoot Disk — образ диска с загрузчиком GRUB2, предназначенным для удобного запуска неподписанных efi-программ и операционных систем в режиме UEFI Secure Boot.

Диск можно использовать в качестве основы для создания USB-накопителя с утилитами восстановления компьютера, для запуска различных Live-дистрибутивов Linux и среды WinPE, загрузки по сети, без отключения Secure Boot в настройках материнской платы, что может быть удобно при обслуживании чужих компьютеров или корпоративных ноутбуков, например, при установленном пароле на изменение настроек UEFI.

Образ состоит из трех компонентов: предзагрузчика shim из Fedora (подписан ключом Microsoft, предустановленным в подавляющее большинство материнских плат и ноутбуков), модифицированного предзагрузчика PreLoader от Linux Foundation (для отключения проверки подписи при загрузке .efi-файлов), и модифицированного загрузчика GRUB2, который загружает EFI-файлы самостоятельно, не используя функции UEFI.

Во время первой загрузки диска на компьютере с Secure Boot необходимо выбрать сертификат через меню MokManager (запускается автоматически), после чего загрузчик будет работать так, словно Secure Boot выключен: GRUB загружает любой неподписанный . efi-файл или Linux-ядро, загруженные EFI-программы могут запускать другие программы и драйверы с отсутствующей или недоверенной подписью.

Для демонстрации работоспособности, в образе присутствует Super Grub Disk (скрипты для поиска и загрузки установленных операционных систем, даже если их загрузчик поврежден), GRUB Live ISO Multiboot (скрипты для удобной загрузки Linux LiveCD прямо из ISO, без предварительной распаковки и обработки), One File Linux (ядро и initrd в одном файле, для восстановления системы), и несколько UEFI-утилит.

Диск совместим с UEFI без Secure Boot, а также со старыми компьютерами с BIOS.

>>> Репозиторий диска

Устранение неполадок при загрузке ОС windows VM — Virtual Machines

• 
  12/07/2020
• Чтение занимает 4 мин

В этой статье

В этой статье объясняется, почему не удается загрузить ВМ Windows и как решить проблему.

Симптомы

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

Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device

Причины

Существует несколько причин этой ошибки:

• Операционная система (ОС) не может загрузиться из-за того, что раздел, включив в себя хранилище данных конфигурации загрузки (BCD), неактивен.
• Ос не может загрузиться из-за повреждения BCD.
• Ос не удается загрузиться из-за того, что не найден загрузочный сектор.

Решение

Совет

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

Обзор процесса

1. Создание и доступ к восстановленной ВМ.
2. Убедитесь, что раздел ОС активен.
3. Исправьте отсутствующие ссылки в хранилище BCD.
4. Перестроение ВМ.

Примечание

При этой ошибке гостевая ОС не работает. Устранение этой проблемы в автономном режиме для устранения этой проблемы.

Создание и доступ к восстановленной ВМ

1. Для подготовки восстановления ВМ используйте шаги 1–3 команд восстановления.
2. С помощью подключения к удаленному рабочему столу подключите к восстановленной ВМ.

Убедитесь, что раздел ОС активен

Примечание

Это меры применяются только к ВМ поколения 1. В поколениях 2 (с использованием UEFI) не используется активный раздел.

Убедитесь, что раздел ОС, в который входит хранилище BCD для диска, помечен как активный.

1. Откройте командную подсказку с повышенными повышенными уровнями и откройте средство DISKPART.

   diskpart

2. Соберем диски в системе и наберем добавленные диски и переберем новый диск. В этом примере новый диск — Disk 1.

   list disk
   sel disk 1
   

3. Перечислить все разделы на диске и выбрать раздел, который нужно проверить. Обычно системные управляемые разделы имеют меньший размер и около 350 МБ. На рисунке ниже этот раздел является разделом 1.

   list partition
   sel partition 1
   

4. Проверьте состояние раздела. В нашем примере раздел 1 не активен.

   detail partition

   1. Если раздел не активен:

      1. Установите флаг «Активный», а затем повторно установите флажок о том, что изменение было сделано правильно.

         active
         detail partition
         

5. Теперь выйдите из средства DISKPART.

   exit

Устранение отсутствующих ссылок в хранилище BCD

1. Откройте CMD с повышенными уровнями и запустите CHKDSK на диске.

   chkdsk <DRIVE LETTER>: /f

2. Соберйте текущие сведения о настройке загрузки и за документировать их, заметьте идентификатор в активном разделе.

   1. Для поколения 1 ВМ:

      bcdedit /store <drive letter>:\boot\bcd /enum

      1. Если эта команда не найдена, перейдите к следующей \boot\bcd меры.

      2. Запишите идентификатор загрузщика Windows. Это идентификатор с \windows\system32\winload.efi путем.

   2. Для поколения 2 ВМ:

      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /enum

      1. Если эта ошибка не найдена, перейдите к \boot\bcd следующей меры.

      2. Запишите идентификатор загрузщика Windows. Это путь. \windows\system32\winload.efi

3. Выполните следующие команды:

   1. Для поколения 1 ВМ:

      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {bootmgr} device partition=<BCD FOLDER - DRIVE LETTER>:
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {bootmgr} integrityservices enable
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} device partition=<WINDOWS FOLDER - DRIVE LETTER>:
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} integrityservices enable
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} recoveryenabled Off
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} osdevice partition=<WINDOWS FOLDER - DRIVE LETTER>:
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} bootstatuspolicy IgnoreAllFailures
      

      Примечание

      Если vHD имеет один раздел, а папка BCD и папка Windows находятся в одном томе, и если вышеперечисленная настройка не совместим, попробуйте заменить значения раздела *boot _.

      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {bootmgr} device boot
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {bootmgr} integrityservices enable
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} device boot
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} integrityservices enable
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} recoveryenabled Off
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} osdevice boot
      bcdedit /store <BCD FOLDER - DRIVE LETTER>:\boot\bcd /set {<IDENTIFIER>} bootstatuspolicy IgnoreAllFailures
      

   2. Для _ Поколения 2* VM:

      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {bootmgr} device partition=<Volume Letter of EFI System Partition>:
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {bootmgr} integrityservices enable
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {<IDENTIFIER>} device partition=<WINDOWS FOLDER - DRIVE LETTER>:
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {<IDENTIFIER>} integrityservices enable
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {<IDENTIFIER>} recoveryenabled Off
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {<IDENTIFIER>} osdevice partition=<WINDOWS FOLDER - DRIVE LETTER>:
      bcdedit /store <Volume Letter of EFI System Partition>:EFI\Microsoft\boot\bcd /set {<IDENTIFIER>} bootstatuspolicy IgnoreAllFailures
      

Перестроение ВМ

Используйте шаг 5 команд восстановления ВМ для перестроения ВМ.

Дальнейшие действия

Если вы по-прежнему не можете определить причину проблемы и вам нужна дополнительные помощь, вы можете открыть вопрос в службу поддержки клиентов Майкрософт.

Если вам нужна дополнительные помощь в любой момент этой статьи, вы можете обратиться к экспертам Azure на форумах MSDN Azure и Stack Overflow. Кроме того, вы можете подать в службу поддержки Azure инцидент. Перейдите на сайт поддержки Azureи выберите «Получить поддержку». Сведения об использовании службы поддержки Azure можно узнать в службах поддержки Microsoft Azure.

Загрузка компьютера — Введение в информационные и коммуникационные технологии

Введение

Загрузка — это последовательность загрузки, при которой запускается операционная система компьютера.
когда он включен. Последовательность загрузки — это начальный набор операций, которые
компьютер работает, когда он включен. На каждом компьютере есть последовательность загрузки.
Обычный компьютер не понимает последовательность загрузки, но это важно для
знать для настройки и устранения неполадок вашего компьютера.

Загрузчик

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

Программа, запускающая «цепную реакцию», завершающуюся всем
загружаемая операционная система известна как загрузчик (или bootstrap).
загрузчик).Термин «творчески» пришел от первых дизайнеров, которые предполагали, что раньше
компьютер «работает», он должен быть «привязан к ботинкам». Только загрузчик
задача — загрузить другое программное обеспечение для запуска операционной системы. Часто,
используются многоэтапные загрузчики, в которых несколько небольших программ
увеличивая сложность последовательно вызывать один за другим, до последнего
из них загружает операционную систему.

Загрузочные устройства

Загрузочное устройство — это устройство, с которого загружается операционная система.А
современный компьютер BIOS (базовая система ввода / вывода) поддерживает загрузку с различных
устройств. К ним относятся локальный жесткий диск, оптический дисковод, дисковод гибких дисков,
сетевую карту и USB-устройство. Обычно BIOS позволяет
пользователь, чтобы настроить порядок загрузки. Если установлен порядок загрузки:

1. Привод компакт-дисков
2. Жесткий диск
3. Сеть

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

Последовательность загрузки

Существует стандартная последовательность загрузки, которую используют все персональные компьютеры. Во-первых,
ЦП выполняет инструкцию в памяти для BIOS. Эта инструкция содержит
инструкция перехода, которая передается в программу запуска BIOS. Эта программа работает
самотестирование при включении (POST) для проверки того, что устройства, на которые будет опираться компьютер,
функционирует нормально. Затем BIOS выполняет настроенную последовательность загрузки.
пока он не найдет загрузочное устройство. Как только BIOS обнаружит загрузочную
устройства, BIOS загружает загрузочный сектор и передает выполнение в загрузочный сектор.Если загрузочным устройством является жесткий диск, это будет основная загрузочная запись (MBR). В
Код MBR проверяет таблицу разделов на наличие активного раздела. Если найдется,
код MBR загружает загрузочный сектор этого раздела и выполняет его. Ботинок
сектор часто зависит от операционной системы, однако в большинстве операционных систем
его основная функция — загрузка и выполнение ядра операционной системы, которое
продолжает запуск. Если нет активного раздела или активного раздела
загрузочный сектор недействителен, MBR может загрузить вторичный загрузчик, который
выберите раздел и загрузите его boot boot secotr, который обычно загружает
соответствующее ядро ​​операционной системы.

Проект документации Linux

Pop OS: systemd-boot не может обнаружить Windows

Я выполнил классическую процедуру установки Windows и Linux в режиме двойной загрузки. Сначала я установил Windows в режиме UEFI, затем с помощью загрузочного ключа PopOS изменил размер основного раздела Windows; Я создал раздел Linux, а также раздел / boot / efi объемом 500 МБ в оставшемся пространстве.

Моя проблема в том, что systemd-boot не может обнаружить загрузчик Windows.

Когда я показываю меню systemd-boot, в качестве возможного варианта загрузки указывается только PopOS, хотя я могу без проблем запустить Windows из меню BIOS.

Когда я запускаю bootctl , я получаю следующий результат:

  Система:
     Прошивка: UEFI 2.70 (American Megatrends 5.14)
  Безопасная загрузка: отключена
   Режим настройки: настройка

Текущий загрузчик:
      Продукт: systemd-boot 245. 4-4ubuntu3.1pop0 ~ 15674 ~ 20.04 ~ eaac747
     Особенности: ✓ Подсчет загрузки
               ✓ Контроль времени ожидания меню
               ✓ Контроль тайм-аута одноразового меню
               ✓ Контроль входа по умолчанию
               ✓ Одноразовый входной контроль
               ✓ Поддержка раздела XBOOTLDR
               ✓ Поддержка передачи случайного числа в ОС
               ✓ Загрузчик устанавливает информацию о разделах ESP
          ESP: / dev / disk / by-partuuid / 585919b8-7f1b-4f94-a0b1-6ff195d07515
         Файл: └─ / EFI / SYSTEMD / SYSTEMD-BOOTX64.EFI

Случайное семя:
 Передано в ОС: да
 Системный токен: установить
       Существует: да

Доступные загрузчики на ESP:
          ESP: / boot / efi (/ dev / disk / by-partuuid / 585919b8-7f1b-4f94-a0b1-6ff195d07515)
         Файл: └─ / EFI / systemd / systemd-bootx64.efi (systemd-boot 245.4-4ubuntu3.1pop0 ~ 15>
         Файл: └─ / EFI / BOOT / BOOTX64.EFI (systemd-boot 245.4-4ubuntu3.1pop0 ~ 15674 ~ 20.04 ~ e>

Загрузчики, перечисленные в переменных EFI:
        Название: Linux Boot Manager
           ID: 0x0003
       Статус: активен, порядок загрузки
    Раздел: / dev / disk / by-partuuid / 585919b8-7f1b-4f94-a0b1-6ff195d07515
         Файл: └─ / EFI / SYSTEMD / SYSTEMD-BOOTX64. EFI

        Название: Диспетчер загрузки Windows
           ID: 0x0000
       Статус: активен, порядок загрузки
    Раздел: / dev / disk / by-partuuid / 42f0d8f0-13e0-41cf-bc36-ac80dccc54fd
         Файл: └─ / EFI / MICROSOFT / BOOT / BOOTMGFW.EFI

        Название: UEFI OS
           ID: 0x0009
       Статус: активен, порядок загрузки
    Раздел: / dev / disk / by-partuuid / 585919b8-7f1b-4f94-a0b1-6ff195d07515
         Файл: └─ / EFI / BOOT / BOOTX64.EFI

Записи загрузчика:
        $ BOOT: / boot / efi (/ dev / disk / by-partuuid / 585919b8-7f1b-4f94-a0b1-6ff195d07515)

Запись загрузчика по умолчанию:
        title: Pop! _OS
           id: Pop_OS-текущий.conf
       источник: /boot/efi/loader/entries/Pop_OS-current.conf
        Linux: /EFI/Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56/vmlinuz.efi
       initrd: /EFI/Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56/initrd.img
      параметры: root = UUID = 3ce60b75-530a-4cad-9e80-5156a8e6bb56 ro quiet loglevel = 0 systemd.sh>
  

Обратите внимание на запись диспетчера загрузки Windows в разделе Загрузчики , перечисленные в переменных EFI . Кажется, что systemd-boot отчасти знает, что мой раздел Windows существует, он просто не обнаруживает его как то, с чего можно загрузить.

(запуск bootctl install ничего не меняет)

Мои каталоги / boot / efi / выглядят так:

  / загрузочный / efi / EFI
├── САПОГ
│ └── BOOTX64.EFI
├── Linux
├── Pop_OS-3ce60b75-530a-4cad-9e80-5156a8e6bb56
│ ├── cmdline
│ ├── initrd.img
│ └── vmlinuz.efi
└── systemd
    └── systemd-bootx64.efi
  

  / загрузка / efi / загрузчик / записи /
└── Pop_OS-current.conf
  

Значит, каталоги, которые должны были быть заполнены загрузчиком Windows, почему-то нет.

Как я могу диагностировать эту проблему и добавить Windows в качестве параметра запуска в systemd-boot?

Дизайн пользовательской загрузки Chrome OS

В этом документе дается обзор организации процессов загрузки на уровне пользователя для систем на базе Chrome OS. Он описывает, что происходит после того, как / sbin / init впервые запускает выполнение, пока не будут готовы все службы в системе.

Chrome OS Core использует Upstart для своего пакета / sbin / init. Читатели этого документа должны иметь некоторые базовые знания о концепциях Upstart, таких как синтаксис файлов конфигурации заданий, и событиях Upstart, например о запуске и запуске.Читатели также должны иметь некоторое представление о концепциях управления файловой системой Linux, таких как монтирование и создание файловых систем.

Если вы хотите углубиться и прочитать исходный код, вам потребуется некоторое понимание программирования оболочки. Если вы хотите понять, как инициализируется отдельный пакет, вам необходимо знать основные операции с этим пакетом. Ни одна из этих тем не рассматривается в этом документе.

Сводка процесса загрузки

Фазы загрузки

Boot est omnis divisa in partes tres.

На схеме выше показана схема загрузки ядра Chrome OS. Загрузка делится на три последовательные фазы с четырьмя публично определенными событиями Upstart:

Запуск основных служб

«Базовые услуги» — это незаменимые услуги, необходимые системному приложению и остальной части системы. Большинство служб не могут работать, пока эти базовые службы не начнут нормально работать.

В конце запуска основных служб (то есть, когда Upstart выдает запущенные службы загрузки), следующие службы гарантированно доступны:

• Файловая система, в целом соответствующая Linux FHS.
• Служба ведения журнала, совместимая с rsyslogd.
• Обнаружение горячего подключения устройства. Устройства пользовательского ввода или другие устройства, необходимые для системного приложения, будут обнаружены с загруженными модулями. Обнаружение устройств, считающихся некритичными, может быть отложено до запуска системного приложения.
• dbus-демон.

Обратите внимание, что задания, выполняемые на этом этапе, по своей природе должны работать в среде, где указанные выше службы могут быть недоступны. В начале этого этапа нет гарантии записываемого хранилища; задания не могут регистрировать сообщения, записывать какие-либо файлы или читать файлы вне корневой файловой системы.Кроме того, доступность устройства не гарантируется во всех случаях; устройства могут не инициализироваться, а их драйверы могут даже не загружаться.

Запуск системного приложения

Chrome OS Core основывается на существовании одного выделенного приложения, которое играет центральную роль в запуске системы. Для Chrome OS этим приложением является браузер Chrome. Исходники Chrome OS структурированы, чтобы позволить платформе выбрать использование другого системного приложения.

Системное приложение запускается параллельно с различными критическими службами.Как правило, «критический» означает, что системное приложение ожидает наличия службы или что без нее пользователь будет воспринимать систему как неработающую. Например, в Chrome OS к этим службам относятся:

• Сеть.
• Демон криптодома.
• Система управления питанием.

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

• Отсрочка некритических услуг позволяет системному приложению запускаться быстрее.
• Если приложение дает сбой во время запуска, отсутствие запущенных системных служб может быть использовано для обнаружения сбоя.

Для Chrome OS завершение загрузки начинается, когда браузер Chrome отображает начальный экран входа в систему.

Запуск системных служб

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

После запуска события системных служб, службы могут полагаться на следующее:

• Все службы, необходимые после запуска boot-services, доступны.
• События udev для всех устройств, которые присутствовали при загрузке, были обработаны.
• Системное приложение доступно.

По умолчанию системные службы запускаются только в том случае, если системное приложение объявляет об успешной инициализации.Для большинства служб этого достаточно: без системного приложения система находится в неисправном состоянии, и многие службы не имеют полезного назначения. Однако для некоторых служб может потребоваться их запуск, даже если система в целом вышла из строя. Для поддержки этого требования служба может зависеть от запущенного отказоустойчивого события. После запуска boot-services задание отказоустойчивой задержки запускает 30-секундный таймер. Событие запущенного отказоустойчивого режима происходит раньше из запущенных системных служб или по истечении таймера.

Отказоустойчивые задания обычно используются в тестовых образах и образах разработки для служб, необходимых для отладки или восстановления после сбоев. Некоторые примеры:

• Задание openssh-server, которое позволяет входить через ssh.
• Задание udev-trigger, которое иногда может потребоваться для обнаружения и настройки сетевого устройства.

Инициализация и компоновка файловой системы

Создание файловой системы с отслеживанием состояния (сценарий chromeos_startup)

При запуске недоступно доступное для записи хранилище файловой системы.Во время запуска основных служб сценарий chromeos_startup отвечает за монтирование файловых систем и создание базовой иерархии каталогов. Сценарий вызывается из задания запуска, которое начинается с события запуска, генерируемого / sbin / init в начале процесса загрузки пользовательской среды.

Сценарий при необходимости создает недостающие каталоги и точки монтирования. Это сделано для поддержки воссоздания файловой системы после очистки с отслеживанием состояния, а также для защиты файловой системы от непреднамеренного повреждения.Ниже приведен список основных каталогов, перечисленных в порядке их обработки.

• / tmp — смонтирована как файловая система tmpfs
• / sys / kernel / debug — смонтирована как файловая система debugfs.
• / mnt / stateful_partition — монтируется как файловая система ext4 из раздела №1 GPT (но для заводских образов вместо этого используется файловая система tmpfs).
• / home и его подкаталоги — создаются по мере необходимости; / home сам по себе является привязкой к / mnt / stateful_partition / home
• / var и / home / chronos — смонтированы, как описано ниже в разделе «Зашифрованное с отслеживанием состояния».
• Подкаталоги в / var — созданы в соответствии с требованиями Linux FHS.
• / usr / local — этот каталог монтируется только для систем разработки и тестирования. Каталог представляет собой привязку к / mnt / stateful_partition / dev_image.

Зашифрованное с сохранением состояния

В качестве меры безопасности для защиты личных данных части раздела с отслеживанием состояния в / var и / home / chronos монтируются из зашифрованного большого двоичного объекта, хранящегося в разделе с отслеживанием состояния. Зашифрованное хранилище хранится в / mnt / stateful_partition / encrypted.Монтирование и размонтирование зашифрованных данных выполняется командой mount-encrypted.

Не все платформы Chrome OS Core используют эту функцию: для работы этой функции требуется TPM. Более того, эта функция предполагает определенные требования к конфиденциальности. Для Chrome OS действуют эти требования; они могут быть применимы не на всех платформах. Когда функция не используется, / var и / home / chronos являются простыми привязками.

Особые потоки загрузки

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

Предупреждения при загрузке

Некоторые специальные потоки включают представление простых сообщений пользователю до запуска основных служб. Все такие потоки обнаруживаются и обрабатываются из chromeos_startup. Потоки включают один из двух вариантов использования:

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

Поскольку эти сообщения появляются во время запуска базовых служб, для работы в ограниченной операционной среде используется специальный сценарий под названием chromeos-boot-alert:

• X-сервер не запущен. Сценарий использует ply-image для записи непосредственно в буфер кадра.
• Сценарий chromeos-boot-alert должен дождаться завершения анимации загрузочного экрана-заставки, чтобы гарантировать монопольный доступ к буферу кадров.
• Сценарий должен выбрать локализованный текст сообщения на основе локали пользователя по умолчанию.

Stateful Wipe (также известный как Powerwash)

В некоторых случаях загрузки chromeos_startup должен стереть и заново создать раздел с отслеживанием состояния. Скрипт запускает очистку с отслеживанием состояния при одном из трех условий:

• Не удалось смонтировать раздел с отслеживанием состояния или выполнить монтирование с привязкой к разделу с отслеживанием состояния.
• Wipe запрошено при предыдущем выключении. Сценарий очистит раздел с отслеживанием состояния, если файл с именем factory_install_reset присутствует в корне файловой системы с отслеживанием состояния во время загрузки.Этот метод используется в двух случаях:
• Заводская очистка. В конце производственного процесса устройство протирает перегородку с отслеживанием состояния при подготовке к упаковке и отправке.
• Мощная стирка. Пользователь может запросить очистку с целью восстановления его до чистого состояния.
• Wipe после перехода из режима разработчика в режим проверки или наоборот. Файл с именем .developer_mode в корне раздела с отслеживанием состояния указывает, была ли система ранее в режиме разработки:
• Если файл отсутствует, и мы в настоящее время находимся в режиме разработки, мы запускаем очистку для проверенного для разработчиков. переключатель режима.
• Если файл присутствует, и мы в настоящее время находимся в режиме проверки, мы запускаем очистку для переключения режима с разработчика на проверенный.

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

Если процедура очистки выполняется в режиме разработки, файл .developer_mode будет создан после очистки.Это означает, что система успешно очистила состояние после преобразования в режим разработки.

После завершения процедуры очистки система перезагружается; при перезагрузке система восстановит каталоги и точки монтирования в файловой системе с отслеживанием состояния.

Взаимодействие с установкой, восстановлением и обновлением

После установки нового программного обеспечения с помощью chromeos-install (включая восстановление устройства) или автоматического обновления требуется перезагрузка, чтобы новое программное обеспечение вступило в силу. Первая перезагрузка после установки нового программного обеспечения вызывает особую обработку, в зависимости от конкретного варианта использования установки.

Защита от отката после обновления

Если катастрофический сбой системы проявляется сразу после автоматического обновления, Chrome OS Core может обнаружить сбой и вернуться к ранее установленному программному обеспечению. Механизм основан на трехстороннем взаимодействии со службой update_engine, прошивкой и системным приложением.

Каждый GPT-раздел ядра на загрузочном диске содержит три специальных флага атрибутов, которые микропрограммное обеспечение использует для выбора ядра для загрузки.Флаги обозначены как «приоритет», «успешно» и «пытается». Прошивка выбирает ядро ​​на основе этих флагов; полные правила описаны в проектной документации для формата диска. Служба update_engine обновляет эти флаги определенными значениями после применения обновления и снова с другими значениями после загрузки системы без сбоев.

После того, как update_engine завершит загрузку и установит новый образ, на этапе после установки обновления помечаются флажки GPT для нового ядра, которые имеют наивысший приоритет при загрузке, с «попытками», установленными на 5, и «успешными», установленными на 0.В этом состоянии раздел будет выбран микропрограммой как первое загружаемое ядро.

При каждой загрузке микропрограмма уменьшает значение «попыток» для нового ядра в GPT. Если «пытается» уменьшается до 0, а «успешно» никогда не устанавливается на 1, микропрограммное обеспечение откатится к предыдущему рабочему программному обеспечению. Чтобы предотвратить откат, система должна пометить ядро ​​как хорошее, установив счетчик «попыток» равным 0 и флаг «успешный» равным 1 через некоторое время после загрузки.

Chrome OS Core не помечает ядро ​​как исправное сразу после загрузки.Вместо этого при запуске службы update_engine она устанавливает таймер на 45 секунд. Когда таймер истекает, update_engine вызывает скрипт под названием chromeos-setgoodkernel. Этот сценарий отмечает ядро ​​как исправное, после чего откат становится невозможным.

Служба update_engine зависит от запущенных системных служб. Следовательно, откат будет запущен, если новое обновленное изображение постоянно дает сбой любым из следующих способов:

• Паника ядра происходит перед запуском chromeos-setgoodkernel.
• Система зависает до запуска chromeos-setgoodkernel.
• Системное приложение аварийно завершает работу до завершения загрузки.

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

Следствием такой конструкции является то, что если системное приложение дает сбой при запуске, система не может получать новые обновления. Это осознанный выбор дизайна: это не ошибка. Причина в том, что если система дает сбой, откат является наиболее предпочтительным способом восстановления.Ожидание обновления вряд ли пригодится в большинстве случаев:

• Если пользователи ждут обновления, а следующее обновление содержит ту же ошибку, это новое обновление будет перезаписывать предыдущую рабочую версию. В этом случае откат (безусловно, наиболее предпочтительный вариант) будет исключен.
• Могут пройти дни, прежде чем проблему такого рода можно будет распознать, диагностировать, устранить и устранить. Многие пользователи не захотят так долго ждать.
• Даже если пользователи готовы подождать, большинству из них будет нелегко определить, когда доступно фиксированное обновление.
• Восстановление скорее всего будет быстрее, чем ожидание обновления.

Установка и восстановление

Сценарий chromeos-install можно использовать для установки образа с нуля на устройство. Процедура восстановления конечного пользователя является оболочкой этого сценария. Кроме того, разработчики могут запускать скрипт вручную при загрузке пользовательского образа с USB в режиме разработки. Хотя UX в этих двух случаях сильно различается, состояние системы после установки в любом случае неотличимо.

Процесс установки включает создание файловой системы раздела с отслеживанием состояния, аналогично процессу очистки с сохранением состояния. Как и в случае очистки с отслеживанием состояния, установка отвечает за создание файла .developer_mode при установке в режиме разработки. Также, как и при очистке с отслеживанием состояния, после перезагрузки система восстановит каталоги и точки монтирования в файловой системе с отслеживанием состояния.

Обновление с отслеживанием состояния и установка

Для разработчиков и тестовых сборок Chrome OS значительная часть программного обеспечения устанавливается в / usr / local, привязка монтируется через / mnt / stateful_partition / dev_image. Этот контент не доставляется через механизм автообновления. Вместо этого для его отдельного обновления используется скрипт с именем stateful_update.

Процедура обновления с отслеживанием состояния выполняется в два этапа:

• Сценарий загружает файл tar и извлекает новое содержимое для / usr / local и / var во временные местоположения в разделе с отслеживанием состояния.
• После перезагрузки chromeos_startup заменяет старые каталоги новыми до монтирования / usr / local.

Chrome OS — запуск Chrome (задание «ui»)

Браузер Chrome — системное приложение для Chrome OS.Задание ui отвечает за запуск, управление и перезапуск процесса session_manager Chrome OS. Процесс session_manager, в свою очередь, отвечает за управление процессом браузера Chrome.

Процесс запуска задания

Задание ui отвечает за запуск session_manager. Эта программа отвечает за следующее:

• Запуск процесса X-сервера в фоновом режиме.
• Определение параметров командной строки Chrome.
• Инициализация переменных среды для процесса браузера Chrome.
• Инициализация системных ресурсов (например, каталогов, файлов, групп), необходимых для браузера Chrome.
• Запуск браузера Chrome.

После успешного отображения начального экрана запуска Chrome запускает следующую последовательность событий:

• Chrome вызывает интерфейс EmitLoginPromptVisible session_manager через D-шину.
• session_manager генерирует событие Upstart, видимое в подсказке для входа.

• Событие, видимое при входе в систему, запускает задание завершения загрузки.

Обработка завершения работы, сбоев и перезапусков Chrome

Когда пользователь выходит из Chrome, процесс браузера завершается нормально. В свою очередь, session_manager завершает работу, что завершает работу пользовательского интерфейса. При нормальной работе в этом случае задание пользовательского интерфейса должно возродиться. Однако в случае сбоя Chrome логика автоматического возрождения более сложна, чем стандартное поведение Upstart. Вместо этого, всякий раз, когда задание ui останавливается, отдельное задание ui-respawn определяет, что делать в соответствии со следующими правилами:

• Если прерывание было вызвано выключением или перезагрузкой системы, не возрождается и позволяет завершить завершение работы.
• Если завершение было выполнено для простого выхода из системы, безоговорочно повторно запустить браузер.
• В большинстве случаев ненормального завершения попробуйте повторно запустить браузер.
• Если аварийное завершение работы произошло из-за того, что session_manager слишком много раз пытался перезапустить Chrome, попробуйте перезагрузить систему.

Специальная обработка аварийного завершения зависит от скорости передачи:

• Возрождение ограничено не более 6 раз за одну минуту.
• Перезагрузка выполняется только в том случае, если конкретное завершение ошибки происходит чаще, чем один раз в 3 минуты; в противном случае он просто возрождается.
• Перезагрузка ограничена не чаще одного раза в 9 минут.

Если сбой не удалось устранить путем повторного появления или перезагрузки, задание пользовательского интерфейса останавливается, но система остается в рабочем состоянии. При желании пользователь может вручную выключить питание.

События Upstart при запуске Chrome

Ниже приведен список различных событий Upstart, запускаемых при запуске браузера Chrome, и когда они происходят:

Рекомендации по производительности

Критический путь загрузки

В каждой фазе загрузки преобладает один длительный шаг. Эти шаги должны выполняться последовательно, поэтому вместе они составляют критический путь. Для Chrome OS это самые длительные этапы критического пути:

chromeos_startup

Запуск X-сервера до тех пор, пока session_manager не выдаст событие x-start.

Запуск браузера Chrome, пока не отобразится запрос на вход

Добавление времени непосредственно к критическому пути приведет к задержке загрузки на эквивалентное время.По возможности инициализация должна выполняться параллельно с критическим путем.

вперед

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

• Платформы, которые хотят использовать эту функцию, должны зависеть от пакета sys-apps / ureadahead.
• Платформы, которые хотят использовать ureadahead, должны настроить некоторые определенные функции трассировки ядра.
• Программа ureadahead начинает выполнение, когда завершается chromeos_startup, и завершается, когда начинается завершение загрузки. Таким образом, ureadahead не дает никаких улучшений после завершения запуска системного приложения.
• Автообновление удаляет файл пакета ureadahead на этапе после установки. Это означает, что первая загрузка после обновления будет медленнее, потому что ureadahead должен повторно создать файл пакета.

Влияние кэшированных данных

Во время загрузки различные процессы могут кэшировать данные в / var, чтобы ускорить следующий запуск. Однако время от времени эти кэшированные данные, возможно, потребуется сделать недействительными (т. е. удалить), что приведет к однократной более медленной загрузке. Ниже приведен список известных кешей, влияющих на время загрузки, и краткое изложение того, почему они становятся недействительными.

• Файлы пакета ureadahead — они находятся в / var / lib / ureadahead. Фаза автоматического обновления после установки делает данные недействительными всякий раз, когда готово новое обновление.
• Файлы кэша xkb — они находятся в / var / lib / xkb. Они создаются по мере необходимости во время запуска X-сервера. Они удаляются при первой загрузке после любого обновления; это происходит в src / install-completed.conf в src / platform / installer.
• Кэш VPD — эта коллекция файлов создается dump_vpd_logs при запуске основных служб; см. источники в src / platform / vpd для более подробной информации. Кэшированные данные поступают из встроенного ПО, предназначенного только для чтения, и их никогда не нужно аннулировать. Однако после Powerwash микропрограмму только для чтения необходимо перечитать, а это может быть дорогостоящим на некоторых платформах.

Измерение производительности

Для этого есть веб-сайт.

Производительность загрузки измеряется путем фиксации временных меток в определенные моменты во время загрузки. Вот некоторые из ключевых событий, о которых сообщают инструменты:

Все эти события являются частью критического пути.

Аномалии учета производительности ядра

Для запуска ядра получение метки времени в точный момент некоторых ключевых переходов неудобно. В результате определенные события, которые следует отнести к одной фазе (например, запуск ядра), приписываются смежной фазе:

• Запуск ядра начинается с распаковки ядра и запуска учета времени ядра. Эта работа занимает несколько сотен миллисекунд, большая часть которых уходит на декомпрессию.Это время не регистрируется как часть показателя seconds_kernel_to_login; чтобы наблюдать это время, вы должны посмотреть на показатели производительности прошивки.
• Инициализация ядра завершена, когда управление передается / sbin / init. Однако поток загрузки пользовательского пространства не может отмечать время начала, пока chromeos_startup не смонтирует / tmp и / sys / kernel / debug. Эта работа требует нескольких десятков миллисекунд и относится ко времени запуска ядра.

Что важно, что неважно

Не каждое изменение процесса загрузки имеет значение для производительности загрузки. Изменения могут произойти с потоками, которые работают параллельно с критическим путем, не замедляя его. Даже если изменение существенно влияет на время загрузки, соображения разработки программного обеспечения, такие как ремонтопригодность или удобочитаемость, могут иметь большее значение, чем производительность. Ниже приведены рекомендации по оценке того, может ли изменение повлиять на время загрузки и действительно ли это влияние будет значительным.

Критический путь имеет значение

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

Оценка значимости

Настройка производительности часто требует компромисса между более простой и удобной в обслуживании конструкцией и наилучшей производительностью.Более того, даже если настройка не влияет на обслуживание, затраты на внесение и тестирование изменения кода могут превысить выгоду от повышения производительности. Наконец, цифры времени загрузки имеют тенденцию быть очень шумными; небольшие изменения, вероятно, не будут статистически значимыми.

Используйте эти правила при оценке того, какие компромиссы могут потребоваться для повышения производительности:

• Если вы не вносите изменения в прошивку (или определенные изменения ядра), только изменения в файле seconds_kernel_to_login (a.k.a. загрузка завершена) время события имеет значение. Промежуточные события нужны для диагностики проблем, а не как показатели производительности.
• Изменения менее 100 мс (0,1 с) слишком малы, чтобы иметь значение для обычного человека, и слишком малы, чтобы их можно было надежно измерить. Ниже этого порога единственными соображениями являются основные соображения программной инженерии, связанные с поддерживаемым и легким для понимания исходным кодом.
• Изменения более чем на 250 мс (0,25 с) значительны. Выше этого порога оправдано стремление к повышению производительности.
• Между этими двумя пороговыми значениями проявляйте осторожность.

Обратите внимание, что эти рекомендации в равной степени применимы к улучшениям и регрессам: так же, как на 50 мс медленнее не является регрессией, на 50 мс быстрее не является улучшением.

Принципы проектирования

Принципы, изложенные в этом разделе, предназначены для повышения удобства сопровождения пакетов, которые выполняют задания Upstart.

Поместите рабочие места в правильную упаковку

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

• Не все услуги требуются для всех платформ / продуктов. Сохранение работы в службе означает, что работа не будет присутствовать в системах, которым она не принадлежит.
• Если служба устареет, задание прекратится при удалении пакета службы.
• Служба и работа часто меняются вместе. Хранение их вместе сокращает количество репозиториев, которые вам нужно изменить.
• Наличие задания рядом с запускаемой программой облегчает чтение и понимание службы в целом; вам не нужно обращаться к двум исходным репозиториям одновременно.

В зависимости от массовых мероприятий

Для Chrome OS Core существует четыре общедоступных события Upstart с четко определенной стабильной семантикой. В порядке предпочтения, от наиболее предпочтительного к наименее предпочтительному, они запускаются системные службы, запускаются без сбоев, запускаются службы загрузки и запускаются. Пакет, доставляющий задание Upstart, должен зависеть от наиболее предпочтительного общедоступного задания, которое будет соответствовать его требованиям.

Обратите внимание, что задание должно зависеть только от одного из четырех событий; в зависимости от более чем одного события является избыточным:

• запущенные системные службы подразумевают запущенный отказоустойчивый.
• created failsafe подразумевает запущенные boot-services.

За исключением четырех общедоступных событий, задания Upstart и события, генерируемые пакетом chromeos-base / chromeos-init, должны считаться частными для пакета и могут быть изменены в любое время. Если ваша работа зависит от частного события, изменения в chromeos-init могут привести к тому, что ваша работа начнется не в то время или вообще не начнется.

Если ваш пакет зависит от chromeos-base / chromeos-login, он также может зависеть от стандартных событий запуска Chrome.

Если ваш пакет выполняет несколько заданий, для некоторых заданий безопасно и разумно зависеть от других в том же пакете, а не от публичных мероприятий.

Там, где это возможно, задания не должны зависеть от заданий, выполняемых другими пакетами, потому что связывание между пакетами может создать опасность обслуживания. Однако, если два пакета уже связаны по разумным техническим причинам, разумно, чтобы один из пакетов зависел от заданий Upstart другого. Для примера посмотрите дерево заданий для запуска сети (см. Init / shill.conf в src / platform / shill) или в сервисах cryptohome (см. init / cryptohomed.conf в src / platform / cryptohome).

Зависит от работы, а не от событий

Как правило, условия запуска и остановки для заданий должны основываться на событиях задания, таких как запуск и остановка, а не запускать или останавливать задания с помощью initctl emit, start или stop. В зависимости от задания легче находить источники событий и отслеживать их поток через исходный код.

Если вам необходимо использовать initctl emit, start или stop, следуйте этим рекомендациям, чтобы улучшить читаемость:

• Комментарии в источнике, где вызывается initctl emit, должны указывать, какие задания затронуты и как.
• В заданиях, на которые влияет initctl emit, start или stop, должны быть комментарии с подробным описанием вызывающих, которые выполняют эту работу.
• В источнике вызова и / или адресате задания должны быть комментарии, объясняющие, почему проблема должна быть решена таким образом.
• И вызывающий, и затронутое задание должны находиться в одном исходном пакете.

Создайте собственное хранилище

Если вашей службе требуется доступное для записи хранилище (например, каталог в / var / lib), ваша служба отвечает за создание файлов и каталогов.Обычно это может происходить в сценарии перед запуском в задании Upstart для службы. Работа по созданию этого хранилища должна принадлежать пакету, которому принадлежит служба. Эта работа не должна выполняться в chromeos_startup или задании Upstart, не связанном с вашим пакетом. Работа должна происходить при загрузке: как правило, нет возможности инициализировать доступное для записи хранилище во время сборки.

Цель состоит в том, чтобы, если ваш пакет не является частью дистрибутива, он не должен создавать остатков в файловых системах дистрибутивов, которые в нем не нуждаются.

Обратите внимание, что пакеты могут и должны полагаться на каталоги, указанные в Linux FHS. Если место, указанное в стандарте, в стандарте отсутствует, код для его создания следует добавить в chromeos_startup.

Ограничения ресурсов времени выполнения

Каждая служба должна по возможности ограничивать использование ресурсов времени выполнения. Ограничения важны для предотвращения зависания системы из-за утечки памяти или ресурсов в службах. У Upstart есть директивы для управления этим.

Вот важные из них:

• oom score : Все сценарии инициализации должны определять оценку OOM.См. Документ CrOS OOM, чтобы выбрать счет.
• limit as : Установите абсолютные пределы памяти. Не пытайтесь установить жесткий лимит — это предназначено для отлова процессов, вышедших из-под контроля, поэтому установка лимита в 5-10 раз больше нормального — нормально.

Навигация по внедрению

Исходный код и ебилды

В таблице ниже показаны имена пакетов и пути к репозиториям исходного кода для основных поведений, описанных в этом документе.

Простые рецепты работы для выскочки

Простой одноразовый скрипт

Вам необходимо запустить короткий скрипт один раз после загрузки. Вам не нужно запускать команду, если системное приложение дает сбой при запуске.

Сформируйте свою работу после этого:

Параметры загрузки

OSC работает в системах с BIOS и UEFI.

Очень важно, чтобы ваша система поддерживала загрузку с USB-носителя или DVD. Это может быть уже включено, или вам, возможно, придется включить его самостоятельно.

IGEL OS 11 поддерживает безопасную загрузку UEFI. Обратитесь к руководству производителя вашего устройства, чтобы узнать, поддерживает ли ваше устройство безопасную загрузку и как ее включить. Включение безопасной загрузки часто состоит из двух шагов. Во-первых, в BIOS необходимо изменить режим загрузки на UEFI Boot; после этого безопасную загрузку можно активировать также в BIOS.

Если IGEL OS не загружается в режиме UEFI, попробуйте его в устаревшем режиме / режиме BIOS.После этого IGEL OS будет установлен в устаревшем режиме / режиме BIOS.

Устройства сторонних производителей

Требуемые нажатия клавиш для этого могут отличаться от поставщика к поставщику. Однако вот несколько советов:

Во время загрузки устройства попробуйте нажать [F12] (обычно), [F10] (устройства Intel) или [F9] (устройства Hewlett-Packard), чтобы получить доступ к списку загрузок. устройства и выберите UD Pocket.

Если описанное выше не работает, войдите в настройки BIOS, нажав [Del], [F1] или [F2] во время загрузки, и активируйте загрузку с USB-носителя и / или измените порядок загрузки.

См. Документацию BIOS / UEFI для вашей системы, чтобы узнать, как загрузиться с USB-носителя.

Устройства IGEL

UD6 (H830)

1. Включите устройство, быстро нажимая кнопку [Del] несколько раз.
2. Выбрать SCU .
3. Если отображается запрос пароля, введите пароль BIOS.
4. Выберите вкладку Boot .
5. Установить USB-загрузку на <ВКЛЮЧЕНО> .
6. Сохраните настройки и выйдите.
7. Подключите USB-накопитель к устройству.
8. Перезагрузите устройство, быстро нажимая кнопку [Del].
9. Выберите Boot Manager .
10. Выберите USB-накопитель в качестве загрузочного носителя и нажмите Введите .
11. Вы можете продолжить процедуру установки.

UD5 (H830)

1. Включите устройство, быстро нажимая кнопку [Del] несколько раз.
2. Если отображается запрос пароля, введите пароль BIOS.
3. Выберите вкладку Boot .
4. Выберите Приоритеты параметров загрузки .
5. Выберите запись для USB-накопителя и переместите его в первую позицию с помощью клавиши [+].
6. Сохраните настройки и выйдите.
7. Вы можете продолжить процедуру установки.

UD3 (M340)

1. Включите устройство, быстро нажимая кнопку [Del] несколько раз.
2. Если отображается запрос пароля, введите пароль BIOS.
3. Выберите вкладку Boot .
4. Установить USB-загрузку на <ВКЛЮЧЕНО> .
5. Выберите Legacy> Boot Type Order .
6. Выберите USB и переместите его в первую позицию с помощью клавиши [+].
7. Сохраните настройки и выйдите.
8. Вы можете продолжить процедуру установки.

UD2 (M250C)

1. Включите устройство, быстро нажимая кнопку [Del] несколько раз.
2. Выбрать SCU .
3. Если отображается запрос пароля, введите пароль BIOS.
4. Выберите вкладку Boot .
5. Установить USB-загрузку на <ВКЛЮЧЕНО> .
6. Сохраните настройки и выйдите.
7. Подключите USB-накопитель к устройству.
8. Перезагрузите устройство, быстро нажимая кнопку [Del].
9. Выберите Boot Manager .
10. Выберите USB-накопитель в качестве загрузочного носителя и нажмите Введите .
11. Вы можете продолжить процедуру установки.

UD2 (D220)

1. Включите устройство, быстро нажимая кнопку [F2] (старые устройства) или [Del] (новые устройства).
2. Выбрать SCU .
3. Если отображается запрос пароля, введите пароль BIOS.
4. Выберите вкладку Boot .
5. Установить USB-загрузку на <ВКЛЮЧЕНО> .
6. Сохраните настройки и выйдите.
7. Подключите USB-накопитель к устройству.
8. Перезагрузите устройство, быстро нажимая кнопку [F2] или [Del] (новые устройства).
9. Выберите Boot Manager .
10. Выберите USB-накопитель в качестве загрузочного носителя и нажмите Введите .
11. Вы можете продолжить процедуру установки.

UD9 (TC215B)

1. Включите устройство, быстро нажимая кнопку [F2] несколько раз.
2. Если отображается запрос пароля, введите пароль BIOS.
3. Выберите вкладку Boot .
4. Выберите Boot Option Priorities .
5. Выберите запись для USB-накопителя и переместите его в первую позицию с помощью клавиши [+].
6. Сохраните настройки и выйдите.
7. Вы можете продолжить процедуру установки.

Загрузочная папка — документация Raspberry Pi

При базовой установке ОС Raspberry Pi загрузочные файлы хранятся в первом разделе SD-карты, который отформатирован с файловой системой FAT.Это означает, что его можно читать на устройствах Windows, macOS и Linux.

Когда Raspberry Pi включен, он загружает различные файлы из загрузочного раздела / папки для запуска различных процессоров, а затем загружает ядро ​​Linux.

После загрузки Linux загрузочный раздел монтируется как / boot .

Содержимое загрузочной папки

bootcode.bin

Это загрузчик, который загружается SoC при загрузке, выполняет очень простую настройку, а затем загружает один из start *.elf файлов. bootcode.bin не используется на Raspberry Pi 4, потому что он был заменен загрузочным кодом во встроенной EEPROM.

start.elf, start_x.elf, start_db.elf, start_cd.elf, start4.elf, start4x.elf, start4cd.elf, start4db.elf

Это двоичные капли (прошивки), которые загружаются в VideoCore в SoC, которые затем берут на себя процесс загрузки.
start.elf — это базовая прошивка, start_x.elf включает драйверы камеры и кодек, start_db.elf — это отладочная версия микропрограммы, а start_cd.elf — это урезанная версия без поддержки аппаратных блоков, таких как кодеки и 3D, и для использования, когда gpu_mem = 16 указано в config.txt . Дополнительную информацию о том, как их использовать, можно найти в разделе config.txt .

start4.elf , start4x.elf , start4cd.elf и start4db.elf — это файлы прошивки, специфичные для Pi 4.

исправление *.dat

Это файлы компоновщика, которые соответствуют парам файлов start * .elf , перечисленных в предыдущем разделе.

cmdline.txt

Командная строка ядра передается ядру при загрузке.

config.txt

Содержит множество параметров конфигурации для настройки Pi. См. Раздел config.txt .

issue.txt

Некоторая текстовая служебная информация, содержащая дату и git-идентификатор фиксации распределения.

ssh или ssh.txt

Когда этот файл присутствует, SSH будет включен при загрузке. Содержимое не имеет значения, оно может быть пустым. В остальном SSH отключен по умолчанию.

wpa_supplicant.conf

Это файл для настройки параметров беспроводной сети (если оборудование поддерживает это). Измените код страны и сетевую часть в соответствии с вашим случаем. Более подробную информацию о том, как использовать этот файл, можно найти в разделе беспроводной / безголовый .

Файлы дерева устройств

Существуют различные BLOB-файлы дерева устройств с расширением .ДТБ . Они содержат определения оборудования различных моделей Raspberry Pi и используются при загрузке для настройки ядра, в соответствии с которым определяется модель Pi. Подробнее здесь.

Файлы ядра

Загрузочная папка будет содержать различные файлы образов ядра, используемые для различных моделей Raspberry Pi:

¹ Информацию о загрузке 64-битного ядра можно найти здесь.

Примечание. Архитектура, о которой сообщает lscpu , — это armv7l для 32-разрядных систем (т.е. все, кроме kernel8.img) и aarch64 для 64-разрядных систем. l в случае armv7l относится к архитектуре с прямым порядком байтов, а не к LPAE , как указано l в имени файла kernel7l.img .

Наложения дерева устройств

Подпапка overlays Подпапка содержит наложения дерева устройств. Они используются для настройки различных аппаратных устройств, которые могут быть подключены к системе, например, сенсорного дисплея Raspberry Pi или звуковых плат сторонних производителей. Эти наложения выбираются с помощью записей в файле config.txt — см. «Деревья устройств, наложения и параметры, часть 2» для получения дополнительной информации.

Понимание процесса загрузки — BIOS против UEFI — Linux Hint

Процесс загрузки — это вселенная.Необходимо выполнить множество шагов, прежде чем ваша операционная система возьмет верх и вы получите работающую систему . В каком-то смысле во всем этом процессе участвует крошечная встроенная ОС. Хотя процесс отличается от одной аппаратной платформы к другой и от одной ОС к другой, давайте рассмотрим некоторые общие черты, которые помогут нам получить практическое представление о процессе загрузки.

Давайте сначала поговорим о обычном процессе загрузки без UEFI. Что происходит между моментом, когда вы нажимаете кнопку включения питания, до момента, когда ваша ОС загружается и представляет вам приглашение для входа в систему.

Шаг 1: ЦП жестко запрограммирован на выполнение инструкций от физического компонента, называемого NVRAM или ROM, при запуске. Эти инструкции составляют системную прошивку . И именно в этой прошивке проводится различие между BIOS и UEFI. А пока остановимся на BIOS.

Встроенное ПО, BIOS отвечает за проверку различных компонентов, подключенных к системе, таких как контроллеры дисков, сетевые интерфейсы, аудио- и видеокарты и т. Д.Затем он пытается найти и загрузить следующий набор кода начальной загрузки.

Прошивка проходит через устройства хранения (и сетевые интерфейсы) в заранее определенном порядке и пытается найти хранящийся в них загрузчик. Пользователь обычно не занимается этим процессом. Однако есть элементарный пользовательский интерфейс, который можно использовать для настройки различных параметров, касающихся прошивки системы, включая порядок загрузки.

Вы входите в этот пользовательский интерфейс, обычно удерживая клавишу F12, F2 или DEL во время загрузки системы.Чтобы найти конкретный ключ в вашем случае, обратитесь к руководству по материнской плате.

Шаг 2: BIOS, затем предполагает, что загрузочное устройство запускается с MBR (главной загрузочной записью), которая содержит загрузчик первого уровня и таблицу разделов диска. Поскольку этот первый блок, загрузочный блок, мал, а загрузчик очень минималистичен и не может больше ничего делать, например, читать файловую систему или загружать образ ядра.

Итак, запускается загрузчик второй ступени.

Step3: Загрузчик второй ступени отвечает за обнаружение и загрузку в память правильного ядра операционной системы.Наиболее распространенным примером для пользователей Linux является загрузчик GRUB. Если вы используете двойную загрузку, он даже предоставляет вам простой пользовательский интерфейс для выбора подходящей ОС для запуска.

Даже если у вас установлена ​​одна ОС, меню GRUB позволяет загрузиться в расширенном режиме или спасти поврежденную систему, войдя в однопользовательский режим. Другие операционные системы имеют другие загрузчики. FreeBSD поставляется с одной собственной системой, как и другие системы Unix.

Step4: После загрузки соответствующего ядра остается целый список процессов пользовательского уровня, ожидающих инициализации.Сюда входит ваш SSH-сервер, ваш графический интерфейс и т. Д., Если вы работаете в многопользовательском режиме, или набор утилит для устранения неполадок в вашей системе, если вы работаете в однопользовательском режиме.

В любом случае требуется система инициализации для обработки начального создания процесса и постоянного управления критическими процессами. Здесь снова у нас есть список различных вариантов: от традиционных сценариев оболочки инициализации, которые использовали примитивные Unix, до чрезвычайно сложной реализации systemd, которая захватила мир Linux и имеет свой собственный неоднозначный статус в сообществе.BSD имеют свой собственный вариант init, который отличается от двух упомянутых выше.

Это краткий обзор процесса загрузки. Многие сложности были опущены, чтобы описание было удобным для непосвященных.

Особенности UEFI

Часть, в которой проявляется разница между UEFI и BIOS, находится в самой первой части. Если прошивка представляет собой более современный вариант, называемый UEFI или Unified Extensible Firmware Interface, он предлагает гораздо больше функций и настроек.Предполагается, что он будет гораздо более стандартизирован, чтобы производителям материнских плат не приходилось беспокоиться о каждой конкретной ОС, которая может работать на них, и наоборот.

Одно из ключевых различий между UEFI и BIOS заключается в том, что UEFI поддерживает более современную схему разбиения на разделы GPT, а микропрограмма UEFI имеет возможность читать файлы из небольшой системы FAT.

Часто это означает, что ваша конфигурация UEFI и двоичные файлы находятся в разделе GPT на жестком диске. Обычно это называется ESP (системный раздел EFI), установленный в / efi.

Наличие монтируемой файловой системы означает, что ваша работающая ОС может читать ту же файловую систему (и, что достаточно опасно, редактировать ее!). Многие вредоносные программы используют эту возможность для заражения самой прошивки вашей системы, которая сохраняется даже после переустановки ОС.

UEFI более гибкий, поэтому отпадает необходимость в загрузчике второй ступени, таком как GRUB. Часто, если вы устанавливаете одну (хорошо поддерживаемую) операционную систему, такую ​​как рабочий стол Ubuntu или Windows с включенным UEFI, вы можете отказаться от использования GRUB или любого другого промежуточного загрузчика.

Однако большинство систем UEFI по-прежнему поддерживают устаревшую опцию BIOS, вы можете вернуться к ней, если что-то пойдет не так. Точно так же, если система установлена ​​с учетом поддержки BIOS и UEFI, у нее будет блок, совместимый с MBR, в первых нескольких секторах жесткого диска. Точно так же, если вам нужно выполнить двойную загрузку компьютера или просто использовать загрузчик второй ступени по другим причинам, вы можете использовать GRUB или любой другой загрузчик, который подходит для вашего варианта использования.

Заключение

UEFI был разработан для унификации современной аппаратной платформы, чтобы поставщики операционных систем могли свободно разрабатывать на их основе.Однако он постепенно превратился в довольно спорную технологию, особенно если вы пытаетесь запустить на ней ОС с открытым исходным кодом. Тем не менее, у него есть свои достоинства, и лучше не игнорировать его существование.

С другой стороны, устаревшая версия BIOS также останется в будущем еще как минимум на несколько лет. Его понимание не менее важно в случае, если вам нужно вернуться в режим BIOS для устранения неполадок системы. Надеюсь, эта статья достаточно хорошо проинформировала вас об обеих этих технологиях, так что в следующий раз, когда вы столкнетесь с новой системой в дикой природе, вы сможете следовать инструкциям малоизвестных руководств и чувствовать себя как дома.

.