Расскажу о забавной ситуации, которая произошла со мной, и о том, как стать участником известного проекта.
Не так давно у меня возникла идея: загрузить 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) не умеет (вернее, не знала как) устанавливать этот бит. Мне пришлось устанавливать его вручную, пройдя довольно сложную и опасную процедуру.
И в очередной раз попробовав сделать это руками, я не выдержал и оформил проблема на GitHub просить разработчиков добавить эту функцию.
Прошло несколько дней, но на мою просьбу никто не обратил внимания.
И из любопытства я посмотрел исходный код. Я его форкнул, и на коленях придумывал, как добавить эту фичу.
"На коленях", потому что ничего такого я не устанавливал и редактировал исходник код прямо в браузере.
Я знаю С (язык программирования) очень поверхностно, но примерное решение набросал (в основном копипаст).
а потом подумал - по крайней мере у меня там наверняка много ошибок (мои прошлые попытки редактировать чужое Код C был завершен примерно в 10-й раз) Я отправлю запрос на включение.
Хорошо изданный .
И там оказался прикреплен Travis CI для проверки пулл-реквестов.
И он старательно рассказал мне все мои ошибки.
Ну а если есть известные ошибки, то исправлять не обязательно: опять же прямо в браузере, и с четвёртой попытки код сработал (для меня достижение).
И вот так, не выходя из браузера, я отформатировал вполне реальный Pull Request в утилиту, которая используется практически во всех современных дистрибутивах Linux. Меня удивил тот факт, что, толком не зная языка, ничего не настраивая (зависимости требуют довольно много библиотек для сборки) и даже не запуская компилятор, я просто «закодировал» вполне работающую и полезную фичу в браузер.
Однако мой запрос оставался без ответа с 19 марта 2019 года, и я уже начал о нем забывать.
Но вчера этот запрос был добавлен в мастер.
Так о чем моя история? И он говорит о том, что в рамках современных технологий оказалось, что реальный код можно писать уже в браузере, не развертывая локально никаких инструментов разработки и зависимостей.
Более того, надо признаться, это уже второй мой пулл-реквест для известных (по крайней мере, в узких кругах) утилит. В прошлый раз моя просьба исправить отображение некоторых полей в веб-интерфейсе SyncThing привела к моему буквально однострочному редактированию в совершенно незнакомой мне среде.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Писать больше или нет 61,3% да 198 43,34% не стоит 140 Проголосовали 323 пользователя.
152 пользователя воздержались.
Теги: #*nix #github #с открытым исходным кодом #C++ #UEFI #браузер
-
Виртуальные Машины И Микроконтроллеры
19 Oct, 24 -
Qt + Ruby = Конфигурация В Linux И Windows
19 Oct, 24 -
Новости Проекта Sphinx, Весна 2010 Г.
19 Oct, 24 -
3 Простых Совета, Как Улучшить Качество Pr
19 Oct, 24
