Особенности установки Linux с использованием UEFI

[ivm]

Когда оно появилось, сразу же возникли опасения создания аппаратного бэкдора при помощи этой прослойки. Многочисленные сообщения об уязвимости в процессорах Intel... Intel эту гадость и замутил... подсказали, что интуиция меня не обманула. Стационарный компьютер у меня на AMD-шном процессоре изначально. И вот теперь логическое начало отказа от UEFI - Linux Foundation представил проект LinuxBoot для замены UEFI-прошивок.

[yx]

линукс гораздо шире убунты... Это Торвальдсу надо предлагать
Бук у меня на А10, что не помешало гринго из НР поставить на него уефи. Ну и дурак же я, что с грингопроектом связался...

[vita]

линукс гораздо шире убунты... Это Торвальдсу надо предлагать

Наш проект построен на базовой основе Ubuntu. Ваше сообщение к сабжу не имеет отношения.

[ivm]

Приобрёл "мамку" с неотключаемым UEFI.
Система на SSD с MBR не стала загружаться. Удалил все разделы с SSD и выбрал таблицу разделов GPT (GUID). Поскольку Matuntu не рассчитана на установку с UEFI, скачал образ официальной Xubuntu 18.04.1, которая нормально установилась с виртуального привода Zalman-V300.
Из особенностей установки стало создание загрузочного раздела /boot/efi с флагом boot,esp в файловой системе FAT32 размером 367 МБ. В процессе установки указал его загрузочным, но место установки Grub - на указанный SSD.
Впечатления от работы системы на UEFI пока положительные. Задержек в загрузке нет даже после обновления.

Вывод inxi

Kernel: 4.15.0-44-generic x86_64 bits: 64 Desktop: MATE 1.20.1
           Distro: Ubuntu 18.04.1 LTS (Bionic Beaver)
Machine:   Type: Desktop Mobo: ASRock model: J3455M serial: <root required> UEFI: American Megatrends v: P1.80
           date: 05/21/2018
CPU:       Topology: Quad Core model: Intel Celeron J3455 bits: 64 type: MCP L2 cache: 1024 KiB
           Speed: 999 MHz min/max: 800/2300 MHz Core speeds (MHz): 1: 998 2: 896 3: 998 4: 1003
Graphics:  Device-1: Intel driver: i915 v: kernel
           Device-2: NVIDIA GK208 [GeForce GT 730] driver: nvidia v: 415.27
           Display: x11 server: X.Org 1.19.6 driver: modesetting,nvidia unloaded: fbdev,nouveau,vesa
           resolution: 1680x1050~60Hz
           OpenGL: renderer: GeForce GT 730/PCIe/SSE2 v: 4.6.0 NVIDIA 415.27
Audio:     Device-1: Intel Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster driver: snd_hda_intel
           Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel
           Sound Server: ALSA v: k4.15.0-44-generic
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
                 Device-2: Huawei E353/E3131 type: USB driver: cdc_ether,usb-storage
Sensors:   System Temperatures: cpu: 42.0 C mobo: N/A gpu: nvidia temp: 58 C
           Fan Speeds (RPM): N/A gpu: nvidia fan: 40%
Info:      Processes: 177 Uptime: 6m Memory: 15.33 GiB used: 545.4 MiB (3.5%) Shell: bash inxi: 3.0.30

[S.A.]

ivm
Для раздела EFI размер 100 МБ было бы "за глаза".
Matuntu в UEFI тоже устанавливается.

[ivm]

В моём случае (ASRock model: J3455M: UEFI: American Megatrends v: P1.80 date: 05/21/2018 ) не все образы запускаются. Не сразу попался подходящий 

[ivm]

У меня на машине

inxi -MCS

System:    Host: Matuntu Kernel: 4.15.0-45-generic x86_64 bits: 64
           Desktop: MATE 1.20.1  Distro: Ubuntu 18.04.2 LTS
Machine:   Device: desktop Mobo: ASRock model: J3455M serial: N/A
           UEFI: American Megatrends v: P1.80 date: 05/21/2018
CPU:       Quad core Intel Celeron J3455 (-MCP-) cache: 1024 KB
           clock speeds: max: 2300 MHz 1: 1565 MHz 2: 1519 MHz 3: 1201 MHz
           4: 1067 MHz

UEFI не отключается. Восприняв его как непреодолимую объективную реальность, решил начать освоение UEFI.
Танино сообщение о том, что можно загрузиться в UEFI с флешки GPT, созданной юнетбутином, подтолкнуло к экспериментам. До этого у меня на машине у меня стоял установленный с виртуального привода бокса Zalman официальный дистрибутив Ubuntu, доведённый до того, что и называется Matuntu. Процесс этот интересный, но длительный.
Если рядом с виндой можно что-то поставить, то уж установить два линукса на машине с UEFI в теории должно работать.
Записав Matuntu-B64-osen18 на флешку в GPT юнетбутином, легко загрузил образ в режиме UEFI. Живая сессия не отличается от привычной. Выбрал место для установки граба раздел с уже существующим  boot-efi. В самом конце установки появилось сообщение об ошибке:

Такая ситуация уже описывалась S.A. на форуме.
В соответствии с рекомендациями не закрывая установщик, открыл терминал и выполнил:

Код: [Выделить]

sudo chroot /target

Код: [Выделить]

apt update

Код: [Выделить]

apt install grub-efi-amd64-signedУстановка ефишного граба завершилась тем, что я не увидел раздела, на который нужно установить GRUB-EFI, поэтому не выбрал место его установки

Просто закрыл терминал и перезагрузил систему. Ни одна из двух установленных систем не загрузилась.
Снова вошёл в живую сессию Matuntu и восстановил загрузку указав раздел с boot-efi

Теперь появился Grub-EFI. Первый пункт с ранее установленной Ubuntu выпал в busybox, а вновь установленная Matuntu чувствовала себя как рыба в воде 
Busybox вызван обычно ошибками в файловой системе. А ведь я ж её уменьшил для установки Matuntu. Вот она и взбрыкнулась. Из-под Matuntu проверил на ошибки в Gparted раздел с /dev/sda2. По окончании перезагрузил систему. Обе ОС теперь в рабочем состоянии.
Исходя из этого опыта, резюмирую, что UEFI и Matuntu могут жить дружно!

[ivm]

Ранее на этой материнской плате пробовал собрать рабочую систему и сделал её бекап систембеком.  Сейчас этот образ, записанный юнетбутином... Короче я из него и пишу сейчас. Драйвер NVIDIA 415-й работает и в живой сессии. После сегодняшних опытов нет ни малейшего сомнения, что и из него можно поставить систему на UEFI. По крайней мере без установки граба с последующим его восстановлением.

[vita]

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

[ivm]

Совместимость UEFI с BIOS и возможность загружать его сохраняется в ПК до настоящего момента на случай, если пользователям потребуется использовать устаревшее "железо" или ПО, не совместимое с UEFI. Реализовано это через элемент UEFI — "модуль обеспечения совместимости", CSM. Однако в 2020 году такой совместимости настанет конец — об этом заявил представитель Intel Брайан Ричардсон в презентации.

Выдержки из доклада в переводе

Intel осуждает устаревшую поддержку Intel удаляет устаревшую поддержку BIOS из платформы клиентов и центров обработки данных к 2020 году:
• Платформы будут строго UEFI Class 3
• Нет 16-битного OpROM (VGA, LAN, хранилище)
Это сломает любой процесс клиента, который зависит от «отключения UEFI» («CSM ON»).

Главные задачи:
• Улучшить взаимодействие с пользователем с UEFI Secure: Загрузка (установка ОС, инструменты, восстановление)
• Устранить компоненты без поддержки UEFI
• Удалить зависимости DOS / BIOS от инструментов для производства / обслуживания
• Обучение клиентов по миграции сети, загрузка в UEFI (PXE & HTTPS)

Призыв к действию:
• Многие платформы UEFI все еще поддерживают устаревшую BIOS совместимость с использованием CSM
• CSM выявляет проблемы безопасности и задерживает 100% миграцию в UEFI
• Многие современные функции не имеют аналога функциональности и требует загрузки в «режиме UEFI»
• Intel планирует отказаться от устаревшей совместимости к 2020 году, и работает с партнерами для гладкого перехода отрасли

В Intel заявили, что начиная с 2020 года ко всем выпускаемым компанией клиентским и серверным платформам будет применяться стандарт UEFI Class 3, в котором интерфейс BIOS в принципе не доступен. Соответственно, если пользователю для решения каких-то задач сейчас необходимо "отключить UEFI" (на самом деле, включить в нем режим совместимости с BIOS), сделать этого он больше не сможет. Все задачи вроде параллельной установки нескольких ОС, восстановления системы, низкоуровневого обслуживания и т.п. придется решать средствами UEFI.

UEFI бывают разные: 4 класса развития

В ближайшем будущем в продаже останется только 3-й класс UEFI.

[ivm]

Сегодня после экспериментов по поиску оптимального веббраузера, способного воспроизвести непосредственно с яндексдиска тест проверки на битые пиксели в Matuntu-E64, система несколько "замусорилась". Тут недавно рассматривалась тема Timeshift, которой я не пользуюсь, потому что свежеустановленную систему проще переустановить, а появившуюся новую информацию сохраняю на съёмных накопителях.
И вот такая ситуация сложилась сегодня. Оптимальным браузером оказался Brave, который установил пакетом, взятым из кэша APT Matuntu-B64, т.к. ключ для EOAN ещё не создан.
Когда переустанавливал Matuntu-E64 на компьютер с неотключаемым UEFI, решил немного проиллюстрировать установку.
В загрузочном меню выбрал UEFI-флешку и в UEFI-меню флешки прошёл далее по дефолту.
При установке  отказался от загрузки обновлений, затем выбрал другой вариант разметки.
Поскольку на этой машине раздел EFI уже существовал с Matuntu-B64, поставил на него курсор и из контекстного меню выбрал ИЗМЕНИТЬ, пункт использовать как cистемный раздел EFI

В качестве устройства для установки системного загрузчика выбрал тот же раздел EFI, размещённый на /dev/sda1

Всё остальное устанавливал единым корневым разделом.

[S.A.]

Я в качестве установки системного загрузчика, всегда указываю жесткий диск, а не раздел EFI.
В последнее время во время установки систем, я не проверяю в свойствах EFI раздела Использовать как.... , просто смотрю тип раздела Тип ->  efi (на Вашем первом скрине). Это значит раздел EFI правильно подхватился установщиком.
Получается так:
смотрю для EFI раздела Тип ->  efi, указываю корневой раздел (если нужно другие разделы) и нажимаю Установить сейчас.

[ivm]

Я в качестве установки системного загрузчика, всегда указываю жесткий диск, а не раздел EFI.
В последнее время во время установки систем, я не проверяю в свойствах EFI раздела Использовать как.... , просто смотрю тип раздела Тип ->  efi (на Вашем первом скрине). Это значит раздел EFI правильно подхватился установщиком.
Получается так:
смотрю для EFI раздела Тип ->  efi, указываю корневой раздел (если нужно другие разделы) и нажимаю Установить сейчас.

Не подхватился, а есть от первой установленной системы UEFI. Поэтому, чтобы он подхватился для второй системы, его нужно явно указать и для неё. 
А место расположения загрузчика определено стандартом UEFI - раздел EFI, а не сам диск.
 

[S.A.]

А место расположения загрузчика определено стандартом UEFI - раздел EFI, а не сам диск.

Всё верно раздел  EFI.  И это место (место расположения загрузчика), мы указываем когда задаём для EFI раздела Использовать как: системный раздел EFI  (мы говорим установщику, что на этот раздел нужно установить загрузчик).

[vita]

Я в качестве установки системного загрузчика, всегда указываю жесткий диск, а не раздел EFI.

Всё верно раздел  EFI.  И это место (место расположения загрузчика), мы указываем когда задаём для EFI раздела Использовать как: системный раздел EFI  (мы говорим установщику, что на этот раздел нужно установить загрузчик).

Не находите противоречия в Ваших умозаключениях? В первой цитате Ваше утверждение, что Grub всегда устанавливаете на жёсткий диск, а во второй цитате полагаетесь, что система сама определит раздел EFI, на который нужно установить загрузчик. Так где же истина?