Не так давно возился я с одной идеей: загрузка Linux непосредственно из UEFI…
Идея не нова и есть некоторое количество мануалов на эту тему. Один из них можно посмотреть тут
Собственно мои давние попытки решить этот вопрос вылились во вполне оформленное решение. Решение вполне рабочее и я его использую на части своих домашних машин. Чуть более подробно это решение описано тут.
Суть UEFI-Boot в том, что ESP (EFI System Partition) раздел совмещается с каталогом /boot. Т.е. все ядра, и образы начальной загрузки (initrd) размещаются на том самом разделе с которого UEFI может запускать исполняемые файлы и в частности запускать загрузчики системы. Но само ядро Linux уже во многих дистрибутивах собирается с опцией UEFISTUB, которая позволяют само ядро запустить из UEFI.
Есть у этого решения один неприятный момент — ESP раздел отформатирован в FAT32, на которой невозможно создать жесткие ссылки (которые система создает регулярно при обновлении initrd). И ничего особо криминального в этом нет, но видеть предупреждения системы при обновлении компонентов ядра — не очень то приятно…
Есть и другой путь.
Менеджер загрузки UEFI (тот самый куда нужно прописать загрузчик ОС) умеет кроме загрузчиков/ядер Linux загружать еще и драйверы. Так что можно загрузить драйвер той файловой системы, где у вас лежит /boot и прямо оттуда загружать ядро средствами UEFI. Драйвер, само собой, нужно положить в раздел ESP. Примерно этим и занимаются загрузчики типа GRUB. Но изюминка как раз в том что все часто используемые функции GRUB уже есть в UEFI. Точнее в его менеджере загрузки. А если быть еще зануднее, то у менеджера загрузки UEFI есть даже больше возможностей в некоторых вопросах.
Вроде бы красивое решение, но есть одно «НО» (вернее было, но об этом позже). Дело в том, что система драйверов UEFI устроена довольно незатейливо. Там нет такого понятия как монтирование файловой системы или связывание драйвера с конкретным устройством. Там есть системный вызов с условным именем Map (англ.) который берет по очереди каждый драйвер и пытается связать его со всеми, худо-бедно подходящими устройствами. И если драйвер устройство смог подцепить, то создается маппинг — связующая запись. Именно так в общей куче со всеми остальными и должен инициализи?роваться вновь загруженный драйвер. И вот всего-то и нужно — в загрузочной записи драйвера поставить один бит (LOAD_OPTION_FORCE_RECONNECT) в 1 и UEFI после его загрузки сделает этот самый глобальный ремап.
Только вот сделать это не так то просто. Стандартная утилита efibootmgr (средствами которой и производится настройка менеджера разгрузки UEFI) не умеет (точнее не умела) ставить этот бит. Приходилось руками его ставить через довольно сложную и опасную процедуру.
И вот в очередной раз попробовав сделать это руками я не выдержал и оформил issue на GitHub с просьбой к разработчикам добавить эту возможность.
Прошло несколько дней, но на мою просьбу никто не обратил внимание. И я из любопытства глянул на исходники… форкнул, да и прикинул «на коленках» как эту фичу добавить… «На коленках» потому что ничего такого себе не ставил и прямо в браузере исходники редактировал.
C (язык программирования) я знаю очень поверхностно, но примерно решение накидал (преимущественно копи-пастом)… ну а потом подумалось — а хоть у меня там наверняка куча ошибок (прошлые мои попытки править чужой C-код собирались раза с 10-го) оформлю-ка я Pull Request. Ну и оформил.
А там оказался прикручен Travis CI на проверку пулл реквестов. И он мне старательно все мои ошибки выдал. Ну если известны ошибки — что бы и не поправить: опять прямо в браузере, и с четвертой попытки код собрался (достижение для меня).
И вот так, не вылезая из браузера, я оформил вполне реальный Pull Request в утилиту, которой пользуются практически во всех современных дистрибутивах Linux.
Меня самого удивил тот факт что я, толком не зная языка, и ничего у себя не настраивая (там по зависимостям не малая пачка библиотек для сборки нужна) и не разу даже компилятор не запуская, просто в браузере «накодил» вполне рабочую и полезную фичу.
Однако реквест мой висел без реакции с 19 марта 2019, и я уже начал про него забывать.
Но вот вчера этот реквест добавили в master.
Так о чем же мой рассказ. А он про то, что в рамках современных технологий оказалось, что реальный код уже можно писать в браузере, не разворачивая локально никаких девелоперских инструментов и зависимостей.
Причем, надо признаться, это уже второй мой пулл реквест в известные (по крайней мере в узких кругах) утилиты. Прошлый раз моя просьба поправить отображение некоторых полей в web-интерфейсе SyncThing вылилась в мою буквально одно-строчную правку в среде, которую я вообще не знаю.
Комментарии (63)
ZaEzzz
12.10.2019 22:24Будущее наступило давно.
Точно сказать не могу, но наверное лет пять тому назад я уже мог спокойно оформлять коммиты в браузере.
Но это не прижилось от слова совсем — нет окружения рабочей среды. Хотя до сих пор мелкие коммиты на скорую руку иногда делаю так же в браузере.
NetBUG
13.10.2019 22:52Именно
Фикс сделать — возможно, исправить конфликт — весьма удобно, но писать новую функциональность — такое себе
LuckyOok
12.10.2019 22:48Да, хотелось бы побольше про кодинг прямо в браузере.
Про TraviCI тоже — зачем оно, что оно есть, почём, и самое главное — как его организовать для себя.Sly_tom_cat Автор
12.10.2019 22:58TravisCI конкретно мне не зашел. Мне как-то больше понравился CircleCI.
Оба этих *CI имеют хорошую интеграцию с GitHub. И в этой связке легко настраиваются на проверку кода на «собираемость» и на прохождение unit-тестов, а также можно настроить загрузку бинариков например на тот же GitHub залить собранные бинарики в ассеты релиза.
Хотя конечно в плане тестов можно и не ограничиваться unit-тестами, можно практически любой уровень автоматизированного тестирования организовать.
Собственно именно благодаря автоматической сборке навешенной как обязательная проверка для пуллреквеста и можно кодить в браузере — написали код, закомммитили в свою репу, а а в ваш пулреквест этот коммит автоматом попадет и произойдет повторная проверка сборки. Не прошло — лезите в этот *CI (прямо по ссылке из пуллреквеста) и смотрите какие были ошибки — правите код коммитите по новой.
DreamingKitten
12.10.2019 22:49Есть у этого решения один неприятный момент — ESP раздел отформатирован в FAT32, на которой невозможно создать жесткие ссылки (которые система создает регулярно при обновлении initrd). И ничего особо криминального в этом нет, но видеть предупреждения системы при обновлении компонентов ядра — не очень то приятно…
Это проблема? initrd вообще не нужен, как и ссылки куда-то там. У меня есть два ноута (разных), на обоих ESP и есть /boot и на нём лежит ровно один файл — efistub'нутое ядро. Всё работает.bisquitie
13.10.2019 20:29Вот у меня всегда был такой вопрос - зачем нужен initrd? Одной из моих первых систем была Gentoo (установил раза с пятого, особо ничего не понимая), и никогда не делал initrd - включил нужные драйвера в ядро при компиляции и загружал без всяких initrd, зачем его делать?
IGR2014
12.10.2019 23:02Я вас и больше обрадую. Будущее прям ещё дальше скакнуло — GitHub Actions. И не нужны никакие внешние CI
Sly_tom_cat Автор
12.10.2019 23:10GitHub Actions мне показалось пока сыроватым. Но ему от роду то всего-ничего. Уверен что оно действительно потеснит внешние решения. Но вот переносить свое CI решение с одной платформы на другую — нужны серьезные мотивы.
IGR2014
12.10.2019 23:48Я и не говорил про переносить. Можно сразу несколько использовать же.
Да, Actions пока сыроваты, но работают вполне сносно. Мне приятно что до них можно добраться в один клик без переходов на другие сайты. И результат сразу видно возле последнего коммита. Удобные плюшки
dikkini
12.10.2019 23:48GitLab CI, если говорить про компанию
GitHub Actions, если говорить про pet проекты
BugM
13.10.2019 01:45GitLab CI, если говорить про компанию
Про маленькую компанию. Он тормозит жутко, если немного побольше в него запустить.
GitHub Actions, если говорить про pet проекты
Или богатую компанию.
chupasaurus
13.10.2019 18:51Self-hosted Gitlab тормозит одинаково при любой нагрузке, эту фичу правда сейчас дорабатывают. В моей маленькой (около сотни разработчиков, 400 реп) компании инсталляция ещё не смогла упереться ни в один из ресурсов.
AlexanderMarginal
13.10.2019 14:10В рамках отказа от оитхаба в свете их поглощения мягкими?
0xd34df00d
13.10.2019 15:49А чем это поглощение плохо?
AlexanderMarginal
13.10.2019 15:53Все к чему прикасаются мягкие становится ужасным
Viceroyalty
13.10.2019 17:22А ведь таких примеров — масса
AlexanderMarginal
13.10.2019 18:11+
Скайп прям один из самых наглядных примеров.
Да и вообще мягкие имеют свой путь, как Россия — все их продукты дерьмо, Гейтс точно не русский?Sly_tom_cat Автор
13.10.2019 18:21Со скайпом вообще веселуха. У нас на работе его используют в основном для внешних связей (внутри slack). У многих стоит Linux и вот замечено уже многими у нас — Skype-for-Linux работает куда как надежнее чем на винде.
Так что все что кажется не так как кажется и я бы не стал все вся обобщать — это не здоровый подход по жизни, ИМХО.AlexanderMarginal
13.10.2019 18:23-1Просто на Linux все что угодно работает лучше чем на винде))))
А на Mac OS еще лучше))
ZiggiPop
13.10.2019 20:43А правда, что скайп хоть когда-то не был дерьмом? Можно узнать когда конкретно?
DreamingKitten
13.10.2019 21:24+1Году этак в 2006 он меня прямо поразил поддержкой множественных подключений с разных устройств и синхронизацией истории в них. По сравнению с аськой это был просто технологический прорыв, и вот примерно в то время его десктопные клиенты ещё не были дерьмом и не тормозили.
var
14.10.2019 12:57Не было таких времен, он всегда был ужасным, кривым и тормознутым.
А сейчас это стало сильно заметнее, появились инструменты, которые делают все тоже самое, но быстрее в разы лучше и безопаснее.
Но нормальной замены для видеозвонков, объективно — нет. :/
VEG
13.10.2019 20:01+1C# и TypeScript — хороши. GitHub после поглощения стал пока что только лучше. VS Code, не глядя на то, что работает на Electron, работает шустро. Ну и также не стоит забывать, что они также «прикасаются» и к куче других значимых вещей, принимают активное участие в разработке C++, например. Да и к Linux они прикасались, и не раз. Так что не надо =)
Skype да, не лучший пример. Для текстового IM перешёл в Telegram, Skype остался только для видеозвонков. Мобильный клиент у Skype слишком тяжёлый и тормозной для постоянного использования. Да и новый десктопный клиент тоже теперь задумчивый.
dominigato
13.10.2019 23:10Те инженеры майкрософт, с которыми работал и просто пересекался по некоторым темам, создали впечатление не очень высокого профессионализма.
Это я так мягко и политкорректно. Наверняка там есть много грамотных людей, но мне они еще не попадались.
Mayurifag
14.10.2019 04:49Github Actions неплох, но, увы,
«We're working on caching packages and artifacts between workflow executions, we'll have it by mid-November.»
lostmsu
12.10.2019 23:51+1Да, заголовок так себе. Надо было прямо там писать про EFI.
И статье не помешали бы подзаголовки, а то легко потеряться, если нужно вернуться назад перечитать абзац.
LuckyOok
13.10.2019 07:48Я, когда название увидел, думал, что будет что-то вроде этого: https://technix.github.io/instead-playground/
DjSens
13.10.2019 10:25IDE как онлайн сервис, за абонентку, такое будущее нас ждёт…
Мне вот тоже надоело софт устанавливать и настраивать на разных рабочих местах, поэтому установил на одном компе и подключаюсь туда удаленно программы писать. Даже со смартфона, но с него неудобно — экран маленький, жду когда очки VR подешевеют
Naves
13.10.2019 10:53Внезапно вспомнилось.
Вы видели как конфиг граба строится?
Вы редактируете специальный файл, который управляет шаблонизатором и строит монструозный boot.cfg.
Lilo — один файл, и больше ничего.
habr.com/en/company/oleg-bunin/blog/458922Sly_tom_cat Автор
13.10.2019 11:40Ни Grub ни Lilo с UEFI в принципе не нужны. Возможностей диспетчера загрузки UEFI вполне достаточно для загрузки ОС без посредников.
Другое дело — настраивать диспетчер загрузки UEFI не так то просто и порой опасно (окирпичить совсем комп трудно, но восстанавливать потом тоже непросто).
И большая часть проблем тут обычно от кривой вендорской реализации UEFI.
Так что выкидывать загрузчики на свалку еще рановато.
FSA
13.10.2019 18:18Я тоже баловался загрузкой ядра через UEFI. Но потом забил на это дело, потому что Grub позволяет держать на разделе несколько ядер (как минимум новое и старое, которое точно работает). На у экономия 3 секунд на загрузку Grub… Так ли часто вы компьютер перезагружаете?
Sly_tom_cat Автор
13.10.2019 19:43Ну у меня довольно старенький ноут — на нем немного больше 3 секунд экономии. Точных замеров не делал, но прирост скорости загрузки — ощутимый.
По поводу нескольких ядер — так и UEFI может загружать столько вариантов сколько вам надо. Конкретно в UEFI-Boot реализовано именно так: в пункты меню загрузчика UEFI добавляются записи для всех ядер, которые утилита находит в /boot. Более того за счет задания переменной UEFI BootOrder загрузка делается поэтапно — если со самым свежим ядром не загрузится то UEFI будет пытаться загружаться с предыдущим.FSA
13.10.2019 19:47> Конкретно в UEFI-Boot реализовано именно так: в пункты меню загрузчика UEFI добавляются записи для всех ядер, которые утилита находит в /boot.
К сожалению, мой ноут находит только загрузчик со стандартным именем. Хотя, может быть я не знаю, как правильно называть ядра. По крайней мере, если батарейку отключить, что найдётся только
EFI/BOOT/BOOTX64.EFI.Sly_tom_cat Автор
13.10.2019 20:04Это сильно зависит от реализации UEFI для каждой конкретной модели и вендора. К сожалению старые UEFI прошивки были очень глючные.
EFI/BOOT/BOOTX64.EFI — это место расположения загрузчика, которое используется если не задано других опций загрузки в менеджере загрузки UEFI. И вам хотя бы в том повезло что отключение батарейки приводит к ожидаемым результатам.
Но вот если без эксцессов, то прописанные опции загрузки BOOTxxxx сначала перебираются в порядке заданном в BootOrder. А вот если их нет или по ним загрузка не удалась, то запускается режим recovery в котором первым делом производится попытка загрузиться из EFI/BOOT/BOOTX64.EFI.
А как прописывать разные ядра — можете посмотреть на гитхабе (смотрите ссылки в начале статьи).FSA
13.10.2019 21:52Я об этом и говорю, чем плясать с бубном и надеяться, что твои записи не будут уничтожены случайным сбросом настроек, проще положить в EFI/BOOT/BOOTX64.EFI grub и пусть он уже рулит загрузкой. Кстати, нормально загрузить Windows 8.1 из Grub не получается. Иногда просто чего-то не находится, иногда грузится. Я не нашёл логики. Спасает, что можно Windows на отдельном винте держать и уже через меню загрузки BIOS грузить нужную систему.
caffeinum
13.10.2019 12:22Наверное, следующий шаг, это когда Travis запускает тесты прямо в браузере, чтоб не ждать 5 минут, пока он соберется на виртуалке, и быстрее разрабатывать?
Sly_tom_cat Автор
13.10.2019 14:17CircleCI когда с виртуалок на докер образы перешли начали все проверять очень даже быстро — ни каких 5-и минутах речи нет — от силы 1, а иногда и быстрее.
TravisCI (когда я его пробовал) потому и не зашел, что тормозной до жути с этими своими виртуалками.
solver
13.10.2019 14:21Один я немного фоигел от того, что в мастер важной части ОС приняли наколенную поделку, автор которой не то что не особо разбирается в языке, но еще и пропихнул код чисто через CI, который многого просто не может проверить?
Sly_tom_cat Автор
13.10.2019 14:51Ну наверно я не правильно сформулировал. На С у меня просто опыта мало и был он давно. Поэтом синтаксис его меня немного напрягает. И это выливается в то что после моих изменений С-код надо несколько раз прогонять через компилятор пока я там все нужные «знаки препинания» не расставлю.
dominigato
13.10.2019 15:27Нет, не один. Я только надеюсь что они релизят не из мастера все-таки, а делают еще какие-нибудь тесты там. Иначе это вообще жесть какая-то.
При всем уважению к автору, его желанию помочь людям и вложить свою лепту в опенсурс.
Но нельзя просто запихнуть функционал не делая никаких тестов. CI там проверяет какие-то совершенно поверхностные вещи и если вы не делали специальный тест на свой функционал (а вы не делали), то он даже вашу функцию просто пропустит. Да и скорее всего там юнит тесты какие-то, ничего серьезного не тестируется.
Честно говоря мне страшно за будущее efibootmgr с такой политикой мерджей.Sly_tom_cat Автор
13.10.2019 15:58Не совсем так.
Как работает эта фича я руками проверил на нескольких прошивках UEFI.
Спеки UEFI я изучал достаточно детально. И добавленный код полностью соответствует спецификации UEFI.
Сбоку из мастера я таки сделал и проверил — то что я делал руками и то что работало — работает будучи сделанным и утилитой. Речь то про один бит в структуре загрузочной записи менеджера загрузки UEFI.
Да и код мой авторы проверили и подправили местами.dominigato
13.10.2019 16:06Сбоку из мастера я таки сделал и проверил — то что я делал руками и то что работало — работает будучи сделанным и утилитой
OK, из статьи это не было очевидно. Но вы уверены что проверили весь функционал, который был затронут?
Речь то про один бит в структуре загрузочной записи менеджера загрузки UEFI.
Я видел как один character в пулл реквесте ломал кучу продуктов и огорчил много людей. Нет такого "я всего лишь ...", любое нетестированное изменение может испортить продукт и работу большому количеству пользователей. Потом конечно кинутся править, но это все время, ресурсы, убытки.Sly_tom_cat Автор
13.10.2019 17:39Да, я подергал все места, которых касались мои «шаловливые ручки»: man страницы, парсинг входных параметров, проверка совместимости входных параметров, задание значения (не активно) по умолчанию и собственно обработку изменения LOAD_OPTION_FORCE_RECONNECT, которая управляется двумя новыми опциями -f и -F.
Так что (на сколько я могу судить), ничего сломать мне не удалось.
Да и опыт добавления своего функционала в чужой код у меня есть. Конкретно в этом PR вместо того что бы пытаться совместить обработку двух опций (LOAD_OPTION_ACTIVE и LOAD_OPTION_FORCE_RECONNECT) в одой функции я таки сделал копию функции от LOAD_OPTION_ACTIVE и переправил ее на LOAD_OPTION_FORCE_RECONNECT — это тоже не самый лучший паттерн, но в плане добавления функционала такой копи-паст страхует от ненужного вмешательства в работающий код. Позже, если кто-то захочет это место привести к одной общей функции — ну вельком.
merhalak
13.10.2019 15:56Огорчает содержание всех яиц в одной корзине. Например то, что GitLab начинает разрабатывать и продвигать свою Web IDE. В результате получается такой огромный монстр: и система контроля версий, и доска задач, и Web IDE и CI и т.д. Атомарная замена любого из данных сервисов только дублированием функциональности в стороннем приложении, а не заменой и миграцией с одного сервиса на другой. EEE какой-то, давящий конкурентов на корню.
IE6 version X/Y/Z.
Lexicon
13.10.2019 15:57Я бы как минимум изменил заголовок, ибо ожидал прочесть статью совершенно другого вида.
Не говоря о том, что итог статьи, опять же, не связан с тезисом заголовка.
P.S.
Здесь замешана темная магия или Владимир Владимирович?
ivan386
14.10.2019 01:01Так это процент от всех проголосовавших а выбрать можно оба ответа одновременно (там checkbox). Вот и получилось больше 100%.
perfect_genius
13.10.2019 21:22C (язык программирования)
Можно проще — «Си».
wxmaper
Пишете красиво, но тема статьи, её содержание и заголовок у вас почему-то живут в параллельных вселенных.
Sly_tom_cat Автор
САРКАЗМ_МОДЕ=ON
А разве на хабре принято иначе?
extempl
А вы на редакторов равняетесь?
Sly_tom_cat Автор
Это моя первая статья и оно само как-то так получилось.