Расскажу о курьезной ситуации случившейся со мой и о том как стать конрибьютером в известный проект.
Не так давно возился я с одной идеей: загрузка 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. Ну и оформил.
А там оказался прикручен TraviCI на проверку пулл реквестов. И он мне старательно все мои ошибки выдал. Ну если известны — что бы и не поправить: опять прямо в браузере, и с четвертой попытки код собрался (достижение для меня).
И вот так, не вылезая из браузера я оформил вполне реальный Pull Request в утилиту которой пользуются практически во всех современных дистрибутивах Linux.
Меня самого удивил тот факт что я, толком не зная языка, и ничего у себя не настраивая (там по зависимостям не малая пачка библиотек для сборки нужна) и не разу даже компилятор не запуская, просто в браузере «накодил» вполне рабочую и полезную фичу.
Однако реквест мой висел без реакции с 19 марта 2019, и я уже начал про него забывать.
Но вот вчера этот реквест добавили в master.
____
Так о чем же мой рассказ. А он про то, что в рамках современных технологий оказалось, что реальный код уже можно писать в браузере, не разворачивая локально никаких девелоперских инструментов и зависимостей.
Причем, надо признаться, это уже второй мой пулл реквест в известные (по крайней мере в узких кругах) утилиты. Прошлый раз моя просьба поправить отображение некоторых полей в web-интерфейсе SyncThing вылилась в мою буквально одно-строчную правку в среде, которую я вообще не знаю.
Не так давно возился я с одной идеей: загрузка 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. Ну и оформил.
А там оказался прикручен TraviCI на проверку пулл реквестов. И он мне старательно все мои ошибки выдал. Ну если известны — что бы и не поправить: опять прямо в браузере, и с четвертой попытки код собрался (достижение для меня).
И вот так, не вылезая из браузера я оформил вполне реальный Pull Request в утилиту которой пользуются практически во всех современных дистрибутивах Linux.
Меня самого удивил тот факт что я, толком не зная языка, и ничего у себя не настраивая (там по зависимостям не малая пачка библиотек для сборки нужна) и не разу даже компилятор не запуская, просто в браузере «накодил» вполне рабочую и полезную фичу.
Однако реквест мой висел без реакции с 19 марта 2019, и я уже начал про него забывать.
Но вот вчера этот реквест добавили в master.
____
Так о чем же мой рассказ. А он про то, что в рамках современных технологий оказалось, что реальный код уже можно писать в браузере, не разворачивая локально никаких девелоперских инструментов и зависимостей.
Причем, надо признаться, это уже второй мой пулл реквест в известные (по крайней мере в узких кругах) утилиты. Прошлый раз моя просьба поправить отображение некоторых полей в web-интерфейсе SyncThing вылилась в мою буквально одно-строчную правку в среде, которую я вообще не знаю.
