Злой UEFI не загружает хороший Debian
Всем привет.
Ситуация следующая — есть Dell Inspiron 5558 (красненький :3).
Изначально на нем стояла убунта.Для некоторых тестов и заданий решил установить винду — отформатировал раздел (один на 500 гб), разбил на 2 по
250 гб, на один поставил восьмерочку, на второй — переустановил убунту (фетиш у меня такой, всё должно быть установлено мной, а не производителем). Всё работало нормально.
Потом надобность в винде отпала окончательно, решил поставить дебиан.
Захожу в установщик, и что-то меня перемкнуло, и тыкаю на «Использовать весь диск». А там была какая-то виндовая ересь (100мб), и ещё каких-то два раздела, на одном из которых был образ для восстановления системы, а на втором — невесть что.
Не придал особого значения, дохожу до конца установки, перезагружаюсь — нет устройства для загрузки.
Захожу в настройки БИОСа — в Legacy стандартно: порядок загрузки с диска, флешки и харда. А вот в UEFI — пусто. Не вопрос, есть же кнопка «Добавить запись». Добавляю запись grub’а (она там была единственная в ФС, ошибиться не вышло бы). Сохраняюсь, перезагружаюсь — нет устройства для загрузки. И тут я начинаю что-то подозревать.
Захожу в настройки, в UEFI снова пусто. Короче говоря, не сохраняется оно никак.
Пробовал ставить Федору, Дебиан, Убунту — ни Lilo, ни Grub не хотят устанавливаться. Пробовал запустить установку Арча — «Load EFI install, Reboot to hardware блаблабла»: первый пункт не делает ничего, второй тупо выключает ноутбук.
И так, знатоки, внимание, вопрос: чего теперь делать, кроме как выбросить его через окно?
Странное что-то, можешь попробовать полностью снести MBP/GPT таблицу на диске и поставить ОС начисто. Самый простой способ это сделать — бутануть любой дитстр в Live-режим. Узнать маппинг диска (например это /dev/sda) и в консоли
Дело в 100МБ разделе, на нём находится считываемый БИОСом файл загрузчика, в том числе и граба.
Отформатирован он должен быть в понимаемую БИОСом FS.
Какое то легаси fat УГ.
Так работать не будет. На ЛОРе вопрос уже разжёван.
Запомни простое правило. В каком режиме ты загрузил установщик, в таком же режиме ОС и установится. Загрузил в легаси — установится для легаси. Загрузил в uefi — установится для uefi. uefi без наличия специфичных разделов работать не будет.
Захожу в настройки БИОСа — в Legacy стандартно
Ну и нафиг тебе это UEFI? Тебе надо не просто загрузить дебиан, а загрузить максимально через жопу?
Только UEFI, только хардкор. Так решил Dell, и не позволяет загружать операционку кроме как через него (либо у меня руки слишком кривые, что скорее)
When creating a fresh partition table, certain considerations may be in order:
* For data (non-boot) disks, and for boot disks used on BIOS-based computers with GRUB as the boot loader, partitions may be created in whatever order and in whatever sizes are desired.
* Boot disks for EFI-based systems require an EFI System Partition (GPT fdisk internal code 0xEF00) formatted as FAT-32. The recom‐ mended size of this partition is between 100 and 300 MiB. Boot-related files are stored here. (Note that GNU Parted identifies such partitions as having the «boot flag» set.)
* The GRUB 2 boot loader for BIOS-based systems makes use of a BIOS Boot Partition (GPT fdisk internal code 0xEF02), in which the secondary boot loader is stored, without the benefit of a filesystem. This partition can typically be quite small (roughly 32 KiB to 1 MiB), but you should consult your boot loader documentation for details.
* If Windows is to boot from a GPT disk, a partition of type Microsoft Reserved (GPT fdisk internal code 0x0C01) is recommended. This partition should be about 128 MiB in size. It ordinarily follows the EFI System Partition and immediately precedes the Win‐ dows data partitions. (Note that old versions of GNU Parted create all FAT partitions as this type, which actually makes the par‐ tition unusable for normal file storage in both Windows and Mac OS X.)
* Some OSes’ GPT utilities create some blank space (typically 128 MiB) after each partition. The intent is to enable future disk utilities to use this space. Such free space is not required of GPT disks, but creating it may help in future disk maintenance. You can use GPT fdisk’s relative partition positioning option (specifying the starting sector as ‘+128M’, for instance) to sim‐ plify creating such gaps.
Источник
Не загружает EFI+Ubuntu
ставил сегодня Ubuntu 14.04 x64 на EFI-based комп с предустановленной, но после перезагрузки не видит винт вообще — ни винду, ни убунту.
использованы были разделы /, /boot, /boot/efi . boot флаг установлен на раздел с efi.
Пробовал поправить все через boot-repair, как написано здесь, но безрезультатно.
Как можно исправить этот загрузчик?
В bios или при выборе диска загрузки пункт «загрузиться в EFI-Shell» есть? Если есть, грузишься, fs0: , dir , ищешь grubx64.efi, grub.cfg. Запускаешь grubx64.efi.
Если загрузится получилось см. man efibootmgr .
нету. или я как-то не так захожу.
(U)EFI shell должнен быть, поищи хорошенько в материнке или бутменю.
Разметка MBR, что ли? Не все UEFI умеют грузиться с MBR, некоторые признают только GPT (у меня такой, например). Ещё EFI-раздел должен быть в FAT32, его тип раздела должен быть EF00.
использованы были разделы /, /boot, /boot/efi
Зачем отделять отдельно /boot?
Не во всех UEFI есть встроенный шелл.
Записать шелл на флешку — дело 5 минут.
разметка GPT, EFI — в fat32. Устанавливался напрямую установщиком Ubuntu.
Отеделение или не отделение бута — это не принципиальный вопрос в большинстве случаев.
Какие клавиши есть для входа в EFI Shell? Del, F12 — вход в биос (если что, bios — american megatrends).
Еще один может быть важный факт: раздел EFI — не первый. Хотя когда стояла винда, всё работало и так.
Записать шелл на флешку — дело 5 минут.
Я-то в курсе, я говорил про встроенный шелл, который «должнен быть, поищи хорошенько в материнке или бутменю».
Отеделение или не отделение бута — это не принципиальный вопрос в большинстве случаев.
На работоспособность это вряд ли повлияло, просто смысла нет отделять.
в биосе нет строчки Internal EFI Shell. вообще ничего нет связанного с EFI.
Как? тупо скачать Shell_Full.efi и через dd на флэшку?
Не надо никаких dd. Просто скопируй файл на флешку (fat32) и все.
но послперезагрузки не видит винт вообще — ни винду, ни убунту.
Т.е как «вообще»? Винт инициализируется UEFI? Если да, то есть ли помимо него записи в boot menu типа «Ubuntu», «Windows Boot Loader»?
видимо, винт не инициализируется uefi (?).
После очередной попытки установки (на этот раз тот же образ записывался через dd) обнаружилась еще пара багов:
1) Ubuntu определяет EFI как-то через раз. В этот раз при разбивке диска не было строчки в меню, которая позволяла бы назначить раздел EFI.
2) На последнем этапе Восстановления пакетов установщик сказал, что все пакеты — битые.
P.S.: Я начинаю тихо ненавидеть ubuntu.
Если он виден в установщике, значит инициализируется. Что насчет второго вопроса?
Ubuntu определяет EFI как-то через раз. В этот раз приразбивке диска не былострочки в меню, которая позволяла бы назначить раздел EFI.
Возможно ты в этот раз загрузился в Legacy-режиме.
boot-repair определяет оба раздела — и с виндой, и с линуксом на борту.
в этот раз загрузка подготавливалась через биос (там есть два, если не больше этапов загрузки — сначала смотрит то, что в биосе стоит по первому приоритету, затем загружается еще одно нечто, в котором можно выбрать устройство, с которого загружаться. увы, в этом списке нет винта).
сначала смотрит то, что в биосе стоит по первому приоритету
Что значится в списке? По твоему описанию там нет ни винта, ничего.
эм. вероятно, я как-то не так описал. в списке Boot Device Priority винт обнаруживается. после Save & Exit и ребута, когда доходит до программы загрузки диска (и это уже не биос и не загрузчики систем, что-то новое. может и uefi, ни разу не видел, как оно выглядит, но если и так, то оно никак не показывает, что это uefi, показывает только марку винта — 2,2 TB и статус-бар. Да, это не размер диска, а марка), снова появляется предложение нажать любую клавишу для выбора устройства загрузки. И вот именно в этом списке нет разделов винта, только флэшки.
то есть, винт как устройство обнаруживается, а разделы на себе он не видит. Загрузчик убунты ставился по всякому, в том числе и в /dev/sda. Его он тоже не мог найти.
в случае форматирования раздела с EFI, установщик ведь сможет его поправить?
Источник
Почему UEFI Secure boot это трудность для Linux
Недавняя публикация на Хабре об ограничениях UEFI вызвала широкое обсуждение, в продолжении темы, хочу поделиться переводом актуального поста из блога Matthew Garrett, одного из разработчиков RedHat.
Я писал о технических деталях поддержки Linux`ом спецификации UEFI Secure boot. Не смотря на то, что я прямо указал, что она игнорирует вопросы лицензирования и распространение ключей, тем не менее опираясь на неё люди утверждают, что поддержка Secure boot может быть добавлена в Linux с минимальными усилиями. В некотором смысле, они правы. Технические детали реализации достаточно просты. Но трудности заключены не в них.
Safe boot требует, что бы весь код, который взаимодействует с железом, был доверенным.
В настоящее время, если вы можете выполнить не доверенный код до загрузки ОС, то можете сделать с ОС всё, что захотите. Secure boot предоставляет механизм, который позволяет быть уверенным, что вы запускаете только доверенный код, что призвано защитить от подобных сценариев. Итак, ваши UEFI драйвера снабжены цифровой подписью, загрузчик так же снабжен цифровой подписью и может загрузить только подписанное ядро. Если для загрузки вами использовался только доверенный код, то вы можете быть уверены, что ваша ОС в безопасности. Но, в отличии от загрузки доверенного кода, Secure boot не даёт вам возможности быть уверенным, что выполняется только доверенный код. Это должно быть обеспечено политиками ОС.
На первый взгляд это не составляет большой проблемы. Но на самом деле является ей. Представьте, что у вас есть подписанный загрузчик Linux и подписанное ядро Linux и эти подписи сделаны с помощью глобального доверенного ключа. Они будут загружаться на любом железе использующем Secure boot. Теперь представьте, что злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI, прерывает выполнение кода ядром и вызывает загрузчик Windows — что-то вроде kexec, но чуть более сложное. Загрузчик Windows уверен, что он выполняется в Secure boot, но на самом деле, всё, что на его взгляд заслуживает доверия, является поддельным кодом UEFI, написанным злоумышленником. Ключ шифрования пользователя записывается, ядро Windows модифицируется таким образом, что бы скрыть код Linux и не смотря на то, что всё выглядит замечательно, данные вашей кредитной карточки уже на пути в Китай. В этом сценарии подписанное ядро Linux просто используется как загрузчик вредоносного ПО. Единственным признаком, что что-то не так, является чуть более долгая загрузка ОС.
Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания. Всё что выходит за пределы стандартных модулей ядра? Так же до новых встреч. Самостоятельная сборка новых драйверов? В другой раз. Всё это явно не сделает людей счастливее.
(Тоже самое, конечно, касается и Windows. Windows 7 позволяет запретить проверку цифровой подписи драйверов, но Windows 8 не позволит этого сделать, если система использует механизм Secure boot).
Лицензирование
GPLv3 имеет различные требования к доступности ключей используемых для подписи. Согласно новым требованиям Microsoft, система должна поддерживать установку пользовательских ключей, что позволит пользователям использовать их собственные загрузчики ОС, этого вполне может быть достаточно, что бы соблюсти требования лицензии. Но мы попадаем в зависимость от Microsoft — если они уберут это требование, то пользователи теряют свою свободу и мы оказываемся в неловком положении с вопросом о лицензировании. Обсуждения о том, что конкретно мы сможем предпринять в этом случае, еще продолжаются, но на текущей момент эта проблема не решена.
Распространение ключей
Спецификация UEFI не определяет, кто будет являться центральным удостоверяющим центром. Microsoft настаивает, что бы каждый имел свой собственный ключ. Мы, конечно, можем сгенерировать собственные ключи, но не всё так просто с производителями оборудования. Не существует пути, который гарантировал бы, что все производители железа поддержат их. И, очевидно, если мы сгенерируем ключ, мы не сможем просто передать его приватную часть третьим лицам. Это значит, что для людей станет невозможным выпуск собственных дистрибутивов, основанных на других, без получения их личного ключа. Для получения ключа будет требоваться какая-либо процедура проверки идентификации, которая, вероятно, окажется дорогостоящей, и так же вероятно, что может потребоваться легально зарегистрированная организация, для обеспечения проверки идентификационных данных. Думаю, это будут сертификаты Extended Validation, а не Startssl Free. Таким образом, диструбутивы Linux созданные энтузиастами, окажутся в прошлом.
Разве Custom mode не решает эту проблему?
Сертификационные требования Microsoft указывают, что все системы должны поддерживать Custom mode, реализация этой функции должна обеспечить возможность пользователям устанавливать их собственные ключи. Производители Linux смогут поставлять их собственные ключи вместе с дистрибутивом и устанавливать собственные политики. Все счастливы. На самом деле, всё не так хорошо. Людям придётся тратить невероятное количество времени и усилий для того чтобы установить Linux, вместо того, чтобы просто вставить CD в привод. Потребность изменения прошивки и её перенастройка добавляет дополнительный барьер и ограничивает возможность установки Linux лишь более технически грамотными пользователями. А это еще хуже. Вот полное описание требований к Custom mode:
1. Для физически находящегося за устройством пользователя, должна быть возможность использования режима Custom mode, для модифицирования содержимого базы данных сигнатур Secure boot и PK (прим. переводчика: PK — private key).
2. Если пользователь удаляет PK, то при выходе из режима Custom mode, система будет функционировать в режиме Setup Mode c выключенным по-умолчанию Secure Boot.
3. Меню настройки прошивки должно уведомлять о включении Secure boot, а так же о режиме функционирования Standard или Custom mode. Меню настройки так же должно предоставлять возможность возвратиться от Custom к Standard mode, с восстановлением заводских настроек по-умолчанию.
Здесь кое-что упущено, например:
— Какое-либо описание UI. Это делает фактически невозможным документирование процесса установки Linux, когда первый шаг (а) запутан и (б) зависит от производителя. Производители железа стараются выделить себя, предлагая свои собственные уникальные интерфейсы прошивок. Custom mode в них может выглядеть совершенно по-разному.
— Какое-либо описание формата ключа. Простое бинарное представление ключа? Или структура EFI_SIGNATURE_DATA? Ключ в кодировке base64, далее защищенный ROT13? Мы просто не знаем.
— Какой-либо путь для использования режима Custom mode при unattended-варианте установки ОС. Интерфейс прошивки требует физического присутствия пользователя. Желаете установить ОС на несколько тысяч машин по сети? Это не масштабируемый подход.
— … и одна мелочь, на самом деле, нигде нет требований, что бы пользователь мог сам добавлять ключ, производители железа могут воспользоваться этим, разрешив лишь удалять ключи. Это не плохо, пока пользователи могут удалять PK, потому-что затем они вернутся обратно в Setup mode и смогут установить наши ключи из установщика, но на практике это по-прежнему будет вызывать проблемы.
Всё таки Custom mode не решает всех проблем. Custom mode с строго определенным UI и форматом ключа был бы на много лучше, но по-прежнему не решит проблему с автоматическим unattended-вариантом установки ОС.
Источник
