Vou contar para vocês uma situação engraçada que aconteceu comigo e como me tornar colaborador de um projeto famoso.
Há pouco tempo eu estava pensando em uma ideia: inicializar o Linux diretamente da UEFI...
A ideia não é nova e existem vários manuais sobre o assunto. Você pode ver um deles
Na verdade, as minhas tentativas de longa data para resolver esta questão resultaram numa decisão completamente formalizada. . A solução está funcionando bastante e eu a uso em algumas de minhas máquinas domésticas. Esta solução é descrita com um pouco mais de detalhes. .
A essência do UEFI-Boot é que a partição ESP (EFI System Partition) é combinada com o diretório /boot. Aqueles. todos os kernels e imagens de bootstrap (initrd) estão localizados na mesma partição a partir da qual o UEFI pode iniciar arquivos executáveis e, em particular, iniciar carregadores de inicialização do sistema. Mas o próprio kernel Linux em muitas distribuições já vem montado com a opção UEFISTUB, que permite que o próprio kernel seja iniciado a partir do UEFI.
Esta solução tem um momento desagradável - a partição ESP está formatada em FAT32, na qual é impossível criar links físicos (que o sistema cria regularmente ao atualizar o initrd). E não há nada de particularmente criminoso nisso, mas ver avisos do sistema ao atualizar componentes do kernel não é muito agradável...
Existe outra maneira.
O gerenciador de boot UEFI (o mesmo onde você precisa registrar o bootloader do SO) pode, além dos bootloaders/kernels do Linux, também carregar drivers. Assim, você pode carregar o driver para o sistema de arquivos onde você tem /boot e carregar o kernel diretamente de lá usando UEFI. O driver, é claro, precisa ser colocado na partição ESP. Isso é aproximadamente o que bootloaders como o GRUB fazem. Mas o destaque é que todas as funções do GRUB usadas com frequência já estão em UEFI. Mais precisamente no seu gerenciador de downloads. E para ser ainda mais chato, o gerenciador de inicialização UEFI tem ainda mais recursos em alguns assuntos.
Parece ser uma bela solução, mas existe um “MAS” (ou melhor, era, mas falaremos mais sobre isso depois). O fato é que o sistema de driver UEFI é bastante simples. Não existe montagem de um sistema de arquivos ou associação de um driver a um dispositivo específico. Existe uma chamada de sistema com o nome convencional Map, que pega cada driver por vez e tenta associá-lo a todos, pelo menos os dispositivos adequados. E se o motorista conseguiu pegar o dispositivo, um mapeamento é criado - um registro de conexão. É exatamente assim que o driver recém-carregado deve ser inicializado em um heap comum com todos os outros. E tudo que você precisa é definir um bit (LOAD_OPTION_FORCE_RECONNECT) como 1 no registro de inicialização do driver e a UEFI fará esse remapeamento global após carregá-lo.
Mas isso não é tão fácil de fazer. O utilitário efibootmgr padrão (que é usado para configurar o gerenciador de descarregamento UEFI) não sabe (ou melhor, não sabia como) definir esse bit. Tive que instalá-lo manualmente através de um procedimento bastante complicado e perigoso.
E mais uma vez, tendo tentado fazer com as mãos, não aguentei e formalizei pedindo aos desenvolvedores que adicionem esse recurso.
Vários dias se passaram, mas ninguém prestou atenção ao meu pedido. E por curiosidade, olhei o código-fonte... bifurquei-o e descobri de joelhos como adicionar esse recurso... “De joelhos” porque não instalei nada parecido e editei o código-fonte código diretamente no navegador.
Conheço C (a linguagem de programação) muito superficialmente, mas esbocei uma solução aproximada (principalmente copiar e colar)... e então pensei - pelo menos provavelmente tenho muitos erros lá (minhas tentativas anteriores de editar o de outra pessoa O código C foi concluído na décima vez). Vou emitir uma solicitação pull. Bem .
E lá o Travis CI acabou sendo anexado para verificar solicitações pull. E ele me contou diligentemente todos os meus erros. Bom, se há erros conhecidos, não há necessidade de consertar: de novo, direto no navegador, e na quarta tentativa o código funcionou (uma conquista para mim).
E assim, sem sair do navegador, formatei um Pull Request muito real em um utilitário que é usado em quase todas as distribuições Linux modernas.
Fiquei surpreso com o fato de que, sem realmente conhecer a linguagem, sem configurar nada (as dependências requerem algumas bibliotecas para montagem) e sem sequer executar o compilador, eu simplesmente “codifiquei” um recurso completamente funcional e útil no navegador .
No entanto, meu pedido não atendeu desde 19 de março de 2019 e eu já havia começado a esquecê-lo.
Mas ontem esta solicitação foi adicionada ao master.
Então, sobre o que é a minha história? E ele está falando sobre o fato de que, dentro da estrutura das tecnologias modernas, descobriu-se que o código real já pode ser escrito no navegador, sem implantar quaisquer ferramentas de desenvolvimento e dependências localmente.
Além disso, devo admitir, esta já é minha segunda solicitação de pull para utilitários bem conhecidos (pelo menos em círculos estreitos). Da última vez, minha solicitação para corrigir a exibição de alguns campos na interface da web do SyncThing resultou em minha edição literalmente de uma linha em um ambiente que eu não conheço.
Apenas usuários registrados podem participar da pesquisa. por favor
Devo escrever mais ou não?
-
sim
-
não vale a pena
294 usuários votaram. 138 usuários se abstiveram.
Fonte: habr.com