Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Полезная ссылка, как раз про настройку ядря для всего этого: wiki.gentoo.org/wiki/EFI_stub_kernel
Спасибо, но именно поэтому я и написал статью.
Всё зависит от реализации загрузчика. Например, ram-disk отдельным файлом преспокойно поддерживается в настоящее время большинством прошивок, а в статье по вашей ссылке его запихивают в ядро, что в 90% случаев не нужно.
upd: упомянул в статье об этом.
Всё зависит от реализации загрузчика. Например, ram-disk отдельным файлом преспокойно поддерживается в настоящее время большинством прошивок, а в статье по вашей ссылке его запихивают в ядро, что в 90% случаев не нужно.
upd: упомянул в статье об этом.
Например, ram-disk отдельным файлом преспокойно поддерживается в настоящее время большинством прошивок
Наверное таки не прошивками, но самим ядром
Сам загружаюсь так:
efibootmgr --create --label "Gentoo" --loader '\EFI\gentoo\kernel.efi' -u 'root=LABEL=Gentoo initrd=EFI\gentoo\initrd.img init=/usr/lib/systemd/systemd'
Уже отписал в статье возможную причину: рекомендации по встраиванию рам-диска в ядро пошли, скорее всего, из-за массового неверного указания пути к нему: в ранних реализациях boot stub, ядро не плевалось ошибкой о неверном пути к ram-disk, а молча отказывалось грузиться. Видимо поэтому, все начали массово внедрять его в ядро, решив, что он не поддерживается. Хотя поддержка параметра initrd существует с момента добавления в ядро Boot Stub.
Странно, что у вас грузится с относительным путём к initrd. В аннотации к коду по Boot Stub явно указано, что путь должен быть абсолютный.
Странно, что у вас грузится с относительным путём к initrd. В аннотации к коду по Boot Stub явно указано, что путь должен быть абсолютный.
Отличная статья! Грамотно написано, понятно изложено. Хотел бы, чтобы вы написали про практическое применение Secure Boot в Linux, т.к. я хоть и теоретически подкован, у меня нет устройств, где можно это пощупать.
Моя статья: Немного про UEFI и Secure Boot
а я, лентяй, все так и не допишу статью про TPM
Моя статья: Немного про UEFI и Secure Boot
а я, лентяй, все так и не допишу статью про TPM
У меня несколько вопросов по теме.
1) Когда-то ставил убунту в ефи режиме, она прописала себя в список ос в ефи( нврам?). После этого несколько раз винчестер полностью переразбивал, менял ос, но убунта висит в меню ефи. как убрать?
2) Иногда подсоединяю винт с восьмой виндой, gpt разбивка. В меню загрузки ефи появляется «виндоус бут манагер». Вытаскиваю винт — меню пропадает. Значит эта запись (или что-то другое — тогда что?) хранится на винчестере. Можно ли хранить на одном винчестере несколько загрузчиков?
3) Касательно хакинтошей — есть загрузчик кловер, который умеет на лету править таблицы управления питанием. Есть ли практические варианты его применения для линукс? для windows (кроме подсовывания таблицы слик)?
1) Когда-то ставил убунту в ефи режиме, она прописала себя в список ос в ефи( нврам?). После этого несколько раз винчестер полностью переразбивал, менял ос, но убунта висит в меню ефи. как убрать?
2) Иногда подсоединяю винт с восьмой виндой, gpt разбивка. В меню загрузки ефи появляется «виндоус бут манагер». Вытаскиваю винт — меню пропадает. Значит эта запись (или что-то другое — тогда что?) хранится на винчестере. Можно ли хранить на одном винчестере несколько загрузчиков?
3) Касательно хакинтошей — есть загрузчик кловер, который умеет на лету править таблицы управления питанием. Есть ли практические варианты его применения для линукс? для windows (кроме подсовывания таблицы слик)?
Когда-то ставил убунту в ефи режиме, она прописала себя в список ос в ефи( нврам?). После этого несколько раз винчестер полностью переразбивал, менял ос, но убунта висит в меню ефи. как убрать?
Через тот же efibootmgr
1) Когда-то ставил убунту в ефи режиме, она прописала себя в список ос в ефи( нврам?). После этого несколько раз винчестер полностью переразбивал, менял ос, но убунта висит в меню ефи. как убрать?
Как уже сказали, либо efibootmgr, либо EFI Shell закинуть на флешку как \EFI\BOOT\bootx64.efi. Загрузиться с него, и командой bcfg удалить пункт:
bcfg boot dump -v
bcfg boot rm N
Ещё, в теории, некоторые прошивки могут поддерживать элементарное редактирование прямо из интерфейса биоса.
2) Иногда подсоединяю винт с восьмой виндой, gpt разбивка. В меню загрузки ефи появляется «виндоус бут манагер». Вытаскиваю винт — меню пропадает. Значит эта запись (или что-то другое — тогда что?) хранится на винчестере. Можно ли хранить на одном винчестере несколько загрузчиков?
Извините, но в статье всё это описано, не хочу повторяться.
3) Касательно хакинтошей — есть загрузчик кловер, который умеет на лету править таблицы управления питанием. Есть ли практические варианты его применения для линукс? для windows (кроме подсовывания таблицы слик)?
Точно не знаю, возможно поможет какая магия с написанием скрипта для UEFI Shell. Здесь уже глубже надо копаться.
1)…
под рутом запускаем efibootmgr без параметров.
Видим что-то подобное:
root@ubuntu64:~# efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0004,0003,0002
Boot0000* ubuntu
Boot0001* Ubuntu EFI
Boot0002 CD/DVD Drive
Boot0003* Hard Drive
Boot0004* ubuntu
Смотрим идентификатор пункта, который хотим удалить. Допустим, 4-й:
Пишем:
root@ubuntu64:~# efibootmgr -b 0004 -B
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0003,0002
Boot0000* ubuntu
Boot0001* Ubuntu EFI
Boot0002 CD/DVD Drive
Boot0003* Hard Drive
Вуаля!
(а вообще — man efibootmgr в помощь)
под рутом запускаем efibootmgr без параметров.
Видим что-то подобное:
root@ubuntu64:~# efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0004,0003,0002
Boot0000* ubuntu
Boot0001* Ubuntu EFI
Boot0002 CD/DVD Drive
Boot0003* Hard Drive
Boot0004* ubuntu
Смотрим идентификатор пункта, который хотим удалить. Допустим, 4-й:
Пишем:
root@ubuntu64:~# efibootmgr -b 0004 -B
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0003,0002
Boot0000* ubuntu
Boot0001* Ubuntu EFI
Boot0002 CD/DVD Drive
Boot0003* Hard Drive
Вуаля!
(а вообще — man efibootmgr в помощь)
а насколько эта nvram является nvram'ом?
просто sram с батарейкой (и можно всё сбросить выниманием батарейки)?
или же пишется во флешку (например, ту же, что и содержит сам uefi)?
просто sram с батарейкой (и можно всё сбросить выниманием батарейки)?
или же пишется во флешку (например, ту же, что и содержит сам uefi)?
Когда-то потратил много времени на борьбу с efi на ноуте. Через bcdedit и через efibootmgr.
В результате так и не смог заставить прошивку загружать что-то кроме \EFI\Microsoft\Boot\bootmgfw.efi, поэтому просто переименовал его, а вместо него поставил Shell.efi.
Потом, как упоминается в статье, скопировал на efi-раздел ядро и initrd и из оболочки загружал любую нужную ОС.
А пока писал эти строчки — вспомнил, что забыл закинуть новое ядро на efi-раздел после его обновления.
В результате так и не смог заставить прошивку загружать что-то кроме \EFI\Microsoft\Boot\bootmgfw.efi, поэтому просто переименовал его, а вместо него поставил Shell.efi.
Потом, как упоминается в статье, скопировал на efi-раздел ядро и initrd и из оболочки загружал любую нужную ОС.
А пока писал эти строчки — вспомнил, что забыл закинуть новое ядро на efi-раздел после его обновления.
Чтобы не забывать, советую использовать один из вариантов автоматического копирования ядра при обновлении из этой статьи.
Достаточно многие моменты весьма условны и (на самом деле!) неважны.
Нужно реально щупать, что да как, на конкретной системе.
По спецификации — да, возможно.
По факту — вовсе необязательно! Эти правила, как правило (упс!) нужны только чтобы вендоры не запутались с файлами. А для, собственно, загрузки это неважно!
Вообще говоря, не очень важно. Ядро как-то само разбирается со слэшами! (опять же, по факту).
Я на своей рабочей убунте сделал просто: скопировал ядро и initrd на efi-раздел (создал для порядка папку myubuntu и кинул в него), после чего прописал его в загрузку такой командой:
Тут как раз-таки (почти) всё против описанных правил: путь к ram-диску через прямые слэши, отсутстие .efi расширения у ядра. Но! Всё работает! (по крайней мере на двух моих системах).
Ровно так же можно игнорировать и требования про путь //EFI//vendor.
Например, вполне рабочий вариант — монтировать efi-раздел на /boot. И тогда пути можно вообще указывать напрямую:
(проверял! Работает!)
Так получается меньше телодвижений в случае обновления ядра (по сути — обновить пункт меню и всё).
Да, и ещё: в прошлой статье по теме была путаница по поводу записи параметров ядра в efibootmgr. Мол, это делает опция -u. На самом деле — нет. Параметры — это строка после всех опций. А -u всего лишь указывает, что она должна быть записана в nvram в юникоде (иначе ядро может и не понять).
Нужно реально щупать, что да как, на конкретной системе.
Кроме того, все файлы в данном разделе должны находиться в директории \EFI\, которая, в свою очередь, является единственной в корне раздела
Файлы должны иметь расширение .efi.
По спецификации — да, возможно.
По факту — вовсе необязательно! Эти правила, как правило (упс!) нужны только чтобы вендоры не запутались с файлами. А для, собственно, загрузки это неважно!
ВАЖНО: Путь к ram-диску передаётся абсолютный через обратные слеши " \ ", а не прямые! Например, initrd=\EFI\archlinux\initramfs-linux.img.
Вообще говоря, не очень важно. Ядро как-то само разбирается со слэшами! (опять же, по факту).
Я на своей рабочей убунте сделал просто: скопировал ядро и initrd на efi-раздел (создал для порядка папку myubuntu и кинул в него), после чего прописал его в загрузку такой командой:
efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\myubuntu\\vmlinuz-3.8.0-31-generic -L "Ubuntu EFI" -u "initrd=/EFI/myubuntu/initrd.img-3.8.0-31-generic root=/dev/mapper/ssdsys-root ro quiet splash"Тут как раз-таки (почти) всё против описанных правил: путь к ram-диску через прямые слэши, отсутстие .efi расширения у ядра. Но! Всё работает! (по крайней мере на двух моих системах).
Ровно так же можно игнорировать и требования про путь //EFI//vendor.
Например, вполне рабочий вариант — монтировать efi-раздел на /boot. И тогда пути можно вообще указывать напрямую:
efibootmgr -c -d /dev/sda -p 1 -l \\vmlinuz-3.8.0-31-generic -L "Ubuntu EFI" -u "initrd=/initrd.img-3.8.0-31-generic root=/dev/mapper/ssdsys-root ro quiet splash"(проверял! Работает!)
Так получается меньше телодвижений в случае обновления ядра (по сути — обновить пункт меню и всё).
Да, и ещё: в прошлой статье по теме была путаница по поводу записи параметров ядра в efibootmgr. Мол, это делает опция -u. На самом деле — нет. Параметры — это строка после всех опций. А -u всего лишь указывает, что она должна быть записана в nvram в юникоде (иначе ядро может и не понять).
Я уже писал выше: если бы все так советовали, как советуете вы, был бы хаос, какой сейчас и происходит с EFI.
Предложу эксперимент: возьмите ванильное ядро версии ниже 3.8.0 и попробуйте там ваши прямые слеши. Думаю, вы удивитесь!
Теперь возьмите среднестатистического юзера убунты, который ещё не обновился до последнего релиза и сидит на 3.5.0. Он этих тонкостей не знает, в случае проблемы в код ядра не полезет, он не знает существует ли там бэкпорт с этими чёртовыми слешами или нет. Он читает вашу статью, в которой написано, что на слеши — плевать. У него не получается. Не получается ещё у сотни. Из этой сотни появляется ещё один автор, который пишет свою статью с костылями, и так по рекурсии… В итоге «ваши эти интернетики» превращаются в мусорку. Разве это хорошо? Я так не считаю. Для чего тогда нужны стандарты? Чтобы пальцем в небо тыкать?
То же самое с расширением .efi: вы уверены, что нет таких прошивок, которым плевать на расширение? Я вот не уверен. А сотни и тысячи людей, у которых они потенциально есть, прочитав статью, где все плевали на расширение, останутся в печали, что ничего не работает. И опять из этих кто-то выйдет, напишет статью, найдёт где-то ещё псевдо-причину, как с этими рам-дисками случилось…
Путь к папке вендора в статье был в разделе общей информации. Там я не писал «должен», я написал «рекомендуется». По-моему, разница очевидна.
А проведём второй эксперимент: возьмём юзера с OpenSUSE и предложим ему проделать данную процедуру? Фейл! А почему? А потому что по умолчанию в этом дистрибутиве ядро и ещё пара файлов линкуются через символьную ссылку на /boot, а наш efi-раздел внезапно FAT32, который не поддерживает симлинки. Зачем этот вариант советовать всем, тем самым явно отсекая пользователей openSUSE (и, возможно, ещё каких-то дистрибутивов)?
Предложу эксперимент: возьмите ванильное ядро версии ниже 3.8.0 и попробуйте там ваши прямые слеши. Думаю, вы удивитесь!
Теперь возьмите среднестатистического юзера убунты, который ещё не обновился до последнего релиза и сидит на 3.5.0. Он этих тонкостей не знает, в случае проблемы в код ядра не полезет, он не знает существует ли там бэкпорт с этими чёртовыми слешами или нет. Он читает вашу статью, в которой написано, что на слеши — плевать. У него не получается. Не получается ещё у сотни. Из этой сотни появляется ещё один автор, который пишет свою статью с костылями, и так по рекурсии… В итоге «ваши эти интернетики» превращаются в мусорку. Разве это хорошо? Я так не считаю. Для чего тогда нужны стандарты? Чтобы пальцем в небо тыкать?
То же самое с расширением .efi: вы уверены, что нет таких прошивок, которым плевать на расширение? Я вот не уверен. А сотни и тысячи людей, у которых они потенциально есть, прочитав статью, где все плевали на расширение, останутся в печали, что ничего не работает. И опять из этих кто-то выйдет, напишет статью, найдёт где-то ещё псевдо-причину, как с этими рам-дисками случилось…
Путь к папке вендора в статье был в разделе общей информации. Там я не писал «должен», я написал «рекомендуется». По-моему, разница очевидна.
Например, вполне рабочий вариант — монтировать efi-раздел на /boot.Верно, если вы не заметили, в статье это упоминается. Но почему не упоминается как единственно верный вариант?
А проведём второй эксперимент: возьмём юзера с OpenSUSE и предложим ему проделать данную процедуру? Фейл! А почему? А потому что по умолчанию в этом дистрибутиве ядро и ещё пара файлов линкуются через символьную ссылку на /boot, а наш efi-раздел внезапно FAT32, который не поддерживает симлинки. Зачем этот вариант советовать всем, тем самым явно отсекая пользователей openSUSE (и, возможно, ещё каких-то дистрибутивов)?
Если вы чуть внимательнее посмотрите — я ничего не советую. Т.е. ВООБЩЕ ничего!
Лишь констатирую факты.
Да, эти факты основаны на «грязных хаках» — и поэтому им место не в статье, а _под_ статьёй, в комментариях. Собственно, там они и есть.
А потому что — см. вторую строчку комментария!
Лишь констатирую факты.
Да, эти факты основаны на «грязных хаках» — и поэтому им место не в статье, а _под_ статьёй, в комментариях. Собственно, там они и есть.
А проведём второй эксперимент: возьмём юзера с OpenSUSE и предложим ему проделать данную процедуру? Фейл! А почему?
А потому что — см. вторую строчку комментария!
Нужно реально щупать, что да как, на конкретной системе.
Спасибо за статью, стало значительно понятнее, как с этим EFI все устроено.
Еще было бы интересно почитать про Secure Boot и загрузчики :)
Еще было бы интересно почитать про Secure Boot и загрузчики :)
Было бы здорово почитать туториал/статью на тему программирования EFI-приложения. Написание тетриса какого-нибудь, например.
загрузчик UEFI делает очень просто: он перебирает все подряд разделы и диски и ищет один особенный.
Интересно, что происходит, когда на каждом из четырех дисков присутствует первый раздел «EFI boot».
А ничего — например, на серверах Dell это работало так:
- ставим ОС
- клонируем раздел с EFI на другие диски
- для каждого раздела в EFI создаем ссылку на EFI-загрузчик на этом разделе
- при загрузке EFI выбирает загрузчик из списка согласно заданных приоритетов
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linux Kernel EFI Boot Stub или «Сам себе загрузчик»