Загрузчик BIOS в режиме UEFI не видит UEFI HDD

[red-matter]

Я завязал с установкой на UEFI. Я там всё перепробовал, даже вставал на голову и стоя на голове нажимал клавиши в установщике. Даже так не помогло.
Решил юзать другую систему, чем лбом об стену.

[Антон Мидюков]

В той статье написано, что важно наличие файла /EFI/boot/bootx64.efi, так вот это сработало. Таким образом, можно сделать вывод, что для установки системы под UEFI, как и её дальнейшего запуска, определения в UEFI BIOS, недостаточно одной только разбивки, необходимо удостоверится в структуре самого EFI-раздела. Я даже подозреваю, что такая схема сделана корпорацией Микрософт для создания дополнительной проблемы при установке посторонних ОС, наряду с сертефикатами secure boot.

В стандарте UEFI (а это открытый стандарт, есть реализации с открытым исходным кодом: https://github.com/tianocore/edk2 ) определено, что загрузиться без записи в NVRAM можно по пути /EFI/boot/bootx64.efi для x86_64). Если Вам это помогло, то у Вас проблема с записью в NVRAM. В последних стартеркитах и Симпли можно выбрать вариант установки загрузчика "EFI (для съёмных устройств)". Это ровно то же самое. Но Secure Boot придётся отключить.

[Антон Мидюков]

Решил юзать другую систему, чем лбом об стену.

А не надо лбом о стену. Задавайте нормально вопросы, описывайте подробно свои действия, можно с картинками.

[red-matter]

Нету второго устройства у меня что бы копошится. Переписал команды на листочик какие то запускаю рескуе и облом. Обложили по всем фронтам баги меня. 
Вот на скрине мои настройки.
Не обращал внимание, но у Росы какой то другой менеджер загрузок. У них списком идёт, без занчков. Вот не прочитал что за менеджер вверху должно быть написано. Биос гигабит 18 года.

[red-matter]

Да мне не критично и не горит Линукс. Так ради интереса просто пишу.

[red-matter]

Не могли эти олухи сделать кнопку в биосе / Линукс UEFI, Линукс no UEFI.
Самая популярная ОС, после Винды всё таки. Себя майка прописали в биосе как подобається, а другие это так и написано другие.
Не понимаю смысл UEFI no CSM ? UEFI сам по себе и есть CSM, охранник загрузок.

[Антон Мидюков]

Не понимаю смысл UEFI no CSM ? UEFI сам по себе и есть CSM, охранник загрузок.

CSM (Compatibility Support Module) - это режим совместимости Legacy BIOS. Если его отключить, загрузка в legacy режиме будет не доступна. При включении Secure Boot, автоматически отключается CSM. Если желаете загрузиться гарантированно в UEFI, отключайте CSM.

[red-matter]

Такогоу  меня нету CSM. Биосы раз в год обновляются, так что не успеешь уследить.

[red-matter]

Ладно время вылечит эту фигню.

[red-matter]

На скрине стоит политика опенром. Вот с ней и ставил. Она может и есть CSM.

[Speccyfighter]

В той статье написано, что важно наличие файла /EFI/boot/bootx64.efi, так вот это сработало. Таким образом, можно сделать вывод, что для установки системы под UEFI, как и её дальнейшего запуска, определения в UEFI BIOS, недостаточно одной только разбивки, необходимо удостоверится в структуре самого EFI-раздела. Я даже подозреваю, что такая схема сделана корпорацией Микрософт для создания дополнительной проблемы при установке посторонних ОС, наряду с сертефикатами secure boot.

В стандарте UEFI (а это открытый стандарт, есть реализации с открытым исходным кодом: https://github.com/tianocore/edk2 ) определено, что загрузиться без записи в NVRAM можно по пути /EFI/boot/bootx64.efi для x86_64). Если Вам это помогло, то у Вас проблема с записью в NVRAM. В последних стартеркитах и Симпли можно выбрать вариант установки загрузчика "EFI (для съёмных устройств)". Это ровно то же самое. Но Secure Boot придётся отключить.

Антон, только таким советом надо народ предупреждать, что он грохнет файл винды.

[Speccyfighter]

В той статье написано, что важно наличие файла /EFI/boot/bootx64.efi, так вот это сработало.

Так и есть.
Но этому bootx64.efi только гугл-хрома не хватает:

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

# strings  /mnt/disk0/EFI/Boot/bootx64.efi | grep -i http:// | wc -l
14


Я даже подозреваю, что такая схема сделана корпорацией Микрософт для создания дополнительной проблемы при установке посторонних ОС, наряду с сертефикатами secure boot.

ИМХО:
Эту ж0пу предусматривает сама архитектура efi которую замутил интел: если не хочешь писать в NVRAM, это должен быть /EFI/Boot/bootx64.efi. Т.е. осями ИЛИ/ИЛИ, но не вместе. А это уже само по себе зонд от глотки до прямой кишки.

Я даже подозреваю, что такая схема ...

Это не схема. Это полный пипец:

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

# find /mnt/disk0/ -type d | wc -l
50


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

# find /mnt/disk0/ -type f | wc -l
150


Попробуйте выключить Secure boot в UEFI BIOS, если он включен.

Спасибо. Я решил проблему, дело не в разбивке и не опции secure boot. Кстати, с этой включенной опцией загрузка намного быстрее, так что я оставил включенной.

У UEFI своя засада:
Secure Boot, по крайней мере в Lenovo G50, как и Fast Boot (который к UEFI не имеет отношения от слова совсем и ему уже сто лет в обед), доступен только при Boot Mode [UEFI]. А при Boot Mode [UEFI] становится недоступным всё что не-UEFI. Ни через UEFI BIOS, ни через Boot menu. Можно представить, что произойдёт, когда Legacy/CSM из UEFI BIOS выдерут совсем. Вот это будет зонд по самые гланды.

[Speccyfighter]

Не могли эти олухи сделать кнопку в биосе / Линукс UEFI, Линукс no UEFI.
Самая популярная ОС, после Винды всё таки.

Да, так и есть:
March, 2020 market share reports are now live.

UEFI сам по себе и есть CSM, охранник загрузок.

Даже интересно стало, в чём его такая защищённость, такая непробиваемость этого UEFI-я?
Его этот UEFI самого надо защищать:
При создании таблицы GPT, в MBR (Protective MBR) создаётся и запись в 16 байт плюс два байта сигнатуры MBR. И если эти 16 байт обнулить, то и "охраннику" придёт конец, и данным на устройстве.

Последовательность этого, проста как два байта:
- На устройтве с типом таблицы GPT, в файловой ext4 лежит каталог lost+found.
- Снимаем с устройства 512 байт в файл.
- Через biew обнуляем 16 байт записи не трогая сигнатуру MBR.
- Возвращаем 512-тибайтный файл на устройство с GPT.
- И fdisk говорит, что на устройстве был gpt, но после этой последовательности действий, он лихо превратился в dos без каких-либо следов файловой. Если обнулить и два байта сигнатуры mbr, то для fdisk устройство станет девственно чистым, - ни gpt, ни dos, ни разделов, ни данных. Хотя сами LBA 1 - LBA 33, LBA -1 - LBA -33 не затронуты. После такого фокуса, винда кстати тоже его увидит как неформатированный накопитель.

И тут ещё вопрос, кто кого охраняет.
Это в последних виндах пользователя огородили забором высотой в три метра и у него создалась иллюзия защищённости. И с этой иллюзией, пользователь виндоус пришёл в линукс.

[Speccyfighter]

UEFI сам по себе и есть CSM, охранник загрузок.

Даже интересно стало, в чём его такая защищённость, такая непробиваемость этого UEFI-я?
Его этот UEFI самого надо защищать:
При создании таблицы GPT, в MBR (Protective MBR) создаётся и запись в 16 байт плюс два байта сигнатуры MBR. И если эти 16 байт обнулить, то и "охраннику" придёт конец, и данным на устройстве.

Последовательность этого, проста как два байта:
- На устройтве с типом таблицы GPT, в файловой ext4 лежит каталог lost+found.
- Снимаем с устройства 512 байт в файл.
- Через biew обнуляем 16 байт записи не трогая сигнатуру MBR.
- Возвращаем 512-тибайтный файл на устройство с GPT.
- И fdisk говорит, что на устройстве был gpt, но после этой последовательности действий, он лихо превратился в dos без каких-либо следов файловой. Если обнулить и два байта сигнатуры mbr, то для fdisk устройство станет девственно чистым, - ни gpt, ни dos, ни разделов, ни данных. Хотя сами LBA 1 - LBA 33, LBA -1 - LBA -33 не затронуты. После такого фокуса, винда кстати тоже его увидит как неформатированный накопитель.

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

На этот случай в fdisk есть замечательные команды:

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

  Сценарий
   I   загрузить разметку из файла сценария sfdisk
   O   записать разметку в файл сценария sfdisk

Выглядит это так:

После разметки с gpt в fdisk, сохраняем разметку в сценарии:

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

Команда (m для справки): g
Created a new GPT disklabel (GUID: 9CEFAE48-4B9D-FD48-8868-FEF89B429DAF).

Команда (m для справки): n
Номер раздела (1-128, default 1):
Первый сектор (2048-30326750, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-30326750, default 30326750): 15000000

Создан новый раздел 1 с типом 'Linux filesystem' и размером 7,2 GiB.

Команда (m для справки): n       
Номер раздела (2-128, default 2):
Первый сектор (15000001-30326750, default 15001600):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (15001600-30326750, default 30326750):

Создан новый раздел 2 с типом 'Linux filesystem' и размером 7,3 GiB.

Команда (m для справки): m

Справка:

  GPT
   M   вход в наследственный/гибридный MBR

  Общие
   d   удалить раздел
   F   показать свободное неразмеченное пространство
   l   список известных типов разделов
   n   добавление нового раздела
   p   вывести таблицу разделов
   t   изменение типа раздела
   v   проверка таблицы разделов
   i   вывести информацию о разделе

  Разное
   m   вывод этого меню
   x   дополнительная функциональность (только для экспертов)

  Сценарий
   I   загрузить разметку из файла сценария sfdisk
   O   записать разметку в файл сценария sfdisk

  Записать и выйти
   w   запись таблицы разделов на диск и выход
   q   выход без сохранения изменений

  Создать новую метку
   g   создание новой пустой таблицы разделов GPT
   G   создание новой пустой таблицы разделов SGI (IRIX)
   o   создание новой пустой таблицы разделов DOS
   s   создание новой пустой таблицы разделов Sun


Команда (m для справки): O

Введите имя файла скрипта: smartbuy-gpt-parts.sh

Сценарий записан успешно.

Команда (m для справки): w
Таблица разделов была изменена.
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.



На убитом устройстве с gpt и обнулёнными или повреждёнными 16-ю байтами в Protective MBR, "улетели" все разделы и все файловые с данными.
Загоняем файл на устройство имитируя повреждение (обнуление) 16-тибайтной записи:

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

# dd if=./smartbuy-mbr.bin of=/dev/sdb
1+0 записей получено
1+0 записей отправлено
512 байт скопировано, 0,00350521 s, 146 kB/s

Но восстановить данные с убитой gpt обнулёнными 16-тью байтами, всё-таки можно. Используя сохранённый ранее сценарий, - ведь таблицу и разделы мы не трогали, а это важный момент:

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

# fdisk /dev/sdb

Добро пожаловать в fdisk (util-linux 2.33.2).
Изменения останутся только в памяти до тех пор, пока вы не решите записать их.
Будьте внимательны, используя команду write.

Команда (m для справки): p
Диск /dev/sdb: 14,5 GiB, 15527313408 байт, 30326784 секторов
Disk model: USB DISK 2.0   
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: dos
Идентификатор диска: 0x00000000

Команда (m для справки): m

Справка:

  DOS (MBR)
   a   переключение флага загрузки
   b   редактирование вложенной метки диска BSD
   c   переключение флага dos-совместимости

  Общие
   d   удалить раздел
   F   показать свободное неразмеченное пространство
   l   список известных типов разделов
   n   добавление нового раздела
   p   вывести таблицу разделов
   t   изменение типа раздела
   v   проверка таблицы разделов
   i   вывести информацию о разделе

  Разное
   m   вывод этого меню
   u   изменение единиц измерения экрана/содержимого
   x   дополнительная функциональность (только для экспертов)

  Сценарий
   I   загрузить разметку из файла сценария sfdisk
   O   записать разметку в файл сценария sfdisk

  Записать и выйти
   w   запись таблицы разделов на диск и выход
   q   выход без сохранения изменений

  Создать новую метку
   g   создание новой пустой таблицы разделов GPT
   G   создание новой пустой таблицы разделов SGI (IRIX)
   o   создание новой пустой таблицы разделов DOS
   s   создание новой пустой таблицы разделов Sun


Команда (m для справки): I

Введите имя файла скрипта: smartbuy-gpt-parts.sh

Created a new GPT disklabel (GUID: 9CEFAE48-4B9D-FD48-8868-FEF89B429DAF).
Создан новый раздел 1 с типом 'Linux filesystem' и размером 7,2 GiB.
Создан новый раздел 2 с типом 'Linux filesystem' и размером 7,3 GiB.
Сценарий применен успешно.

Команда (m для справки): p       

Диск /dev/sdb: 14,5 GiB, 15527313408 байт, 30326784 секторов
Disk model: USB DISK 2.0   
Единицы: секторов по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 512 байт
Размер I/O (минимальный/оптимальный): 512 байт / 512 байт
Тип метки диска: gpt
Идентификатор диска: 9CEFAE48-4B9D-FD48-8868-FEF89B429DAF

Устр-во      начало    Конец  Секторы Размер Тип
/dev/sdb1      2048 15000000 14997953   7,2G Файловая система Linux
/dev/sdb2  15001600 30326750 15325151   7,3G Файловая система Linux

Команда (m для справки): w

Таблица разделов была изменена.
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.



Данные восстановлены, в чём можно убедиться лично:

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

# mount /dev/sdb1 /mnt/disk1
# ll /mnt/disk1
итого 24
drwxr-xr-x 3 root root  4096 апр 18 08:51 ./
drwx------ 2 root root 16384 апр 18 08:51 lost+found/
drwxr-xr-x 5 root root  4096 мар 15 17:15 ../


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

# mount /dev/sdb2 /mnt/disk2
# ll /mnt/disk2
итого 24
drwxr-xr-x 3 root root  4096 апр 18 08:52 ./
drwx------ 2 root root 16384 апр 18 08:52 lost+found/
drwxr-xr-x 5 root root  4096 мар 15 17:15 ../


Чем может быть вызвано повреждение этих 16-ти байт? Да чем угодно. Даже начавшим сыпаться диском. Для восстановления тут правда придётся сначала снять образ диска. Но это уже совсем другая тема.

Собственно общий смысл идеи здесь тот же что и тут:
Как я восстанавливал убитые разделы
https://forum.altlinux.org/index.php?topic=29170.0

Но если физических повреждений винчестера нет, то работы тут, на 5 минут.

[Speccyfighter]

UEFI сам по себе и есть CSM, охранник загрузок.

А истинный охранник,  тихо сидит в Protective MBR, молчит, слушает это всё и думает:
"Вот щас как грохну своих пару-тройку байт и тогда посмотрим кто кого охраняет".