Je vais vous raconter une situation amusante qui m'est arrivée et comment devenir contributeur à un projet célèbre.
Il n'y a pas si longtemps, j'avais une idée : démarrer Linux directement depuis l'UEFI...
L’idée n’est pas nouvelle et il existe de nombreux manuels sur ce sujet. Vous pouvez en voir un
En fait, mes tentatives de longue date pour résoudre ce problème ont abouti à une solution complètement formalisée. . La solution fonctionne assez bien et je l'utilise sur certaines de mes machines personnelles. Cette solution est décrite un peu plus en détail. .
L'essence de UEFI-Boot est que la partition ESP (EFI System Partition) est combinée avec le répertoire /boot. Ceux. tous les noyaux et images d'amorçage (initrd) sont situés sur la même partition à partir de laquelle UEFI peut lancer des fichiers exécutables et, en particulier, lancer les chargeurs de démarrage du système. Mais le noyau Linux lui-même dans de nombreuses distributions est déjà assemblé avec l'option UEFISTUB, qui permet au noyau lui-même d'être lancé depuis l'UEFI.
Cette solution a un moment désagréable : la partition ESP est formatée en FAT32, sur laquelle il est impossible de créer des liens durs (que le système crée régulièrement lors de la mise à jour de l'initrd). Et il n'y a rien de particulièrement criminel à cela, mais voir les avertissements du système lors de la mise à jour des composants du noyau n'est pas très agréable...
Il existe une autre façon.
Le gestionnaire de démarrage UEFI (le même que celui dans lequel vous devez enregistrer le chargeur de démarrage du système d'exploitation) peut, en plus des chargeurs de démarrage/noyaux Linux, également charger des pilotes. Vous pouvez donc charger le pilote du système de fichiers sur lequel vous avez /boot et charger le noyau directement à partir de là en utilisant UEFI. Le pilote doit bien entendu être placé dans la partition ESP. C'est à peu près ce que font les chargeurs de démarrage comme GRUB. Mais le point fort est que toutes les fonctions GRUB fréquemment utilisées sont déjà dans l'UEFI. Plus précisément dans son gestionnaire de téléchargement. Et pour être encore plus ennuyeux, le gestionnaire de démarrage UEFI a encore plus de capacités dans certains domaines.
Cela semble être une belle solution, mais il y a un « MAIS » (ou plutôt, c'était le cas, mais nous y reviendrons plus tard). Le fait est que le système de pilote UEFI est assez simple. Il n'existe pas de montage d'un système de fichiers ou d'association d'un pilote à un périphérique spécifique. Il existe un appel système avec le nom conventionnel Map, qui prend chaque pilote tour à tour et essaie de l'associer à tous, au moins les appareils appropriés. Et si le conducteur a réussi à récupérer l'appareil, un mappage est alors créé - un enregistrement de connexion. C'est exactement ainsi que le pilote nouvellement chargé doit être initialisé dans un tas commun avec tous les autres. Et tout ce dont vous avez besoin est de définir un bit (LOAD_OPTION_FORCE_RECONNECT) sur 1 dans l'enregistrement de démarrage du pilote et UEFI effectuera ce remappage global après l'avoir chargé.
Mais ce n’est pas si facile à faire. L'utilitaire standard efibootmgr (qui est utilisé pour configurer le gestionnaire de déchargement UEFI) ne sait pas comment (ou plutôt ne savait pas comment) définir ce bit. J'ai dû l'installer manuellement via une procédure assez compliquée et dangereuse.
Et encore une fois, après avoir essayé de le faire avec mes mains, je n'ai pas pu le supporter et j'ai officialisé demander aux développeurs d'ajouter cette fonctionnalité.
Plusieurs jours se sont écoulés, mais personne n'a prêté attention à ma demande. Et par curiosité, j'ai regardé le code source... Je l'ai forké, et j'ai compris à genoux comment ajouter cette fonctionnalité... « À genoux » parce que je n'ai rien installé de tel et j'ai édité le source code directement dans le navigateur.
Je connais C (le langage de programmation) très superficiellement, mais j'ai esquissé une solution approximative (principalement copier-coller)... et puis j'ai pensé - au moins j'ai probablement beaucoup d'erreurs là-bas (mes tentatives passées pour éditer le code de quelqu'un d'autre). Le code C a été complété environ la 10ème fois) J'émettrai une Pull Request. Bien .
Et là, Travis CI s'est avéré être attaché pour vérifier les demandes d'extraction. Et il m'a raconté avec diligence toutes mes erreurs. Eh bien, s'il y a des erreurs connues, il n'est pas nécessaire de les corriger : encore une fois, directement dans le navigateur, et à la quatrième tentative, le code a fonctionné (une réussite pour moi).
Et juste comme ça, sans quitter le navigateur, j'ai formaté une très vraie Pull Request dans un utilitaire utilisé dans presque toutes les distributions Linux modernes.
J'ai été surpris par le fait que, sans vraiment connaître le langage, sans rien configurer (les dépendances nécessitent pas mal de bibliothèques pour l'assemblage), et sans même exécuter le compilateur, j'ai simplement « codé » une fonctionnalité complètement fonctionnelle et utile dans le navigateur .
Cependant, ma demande est restée sans réponse depuis le 19 mars 2019, et je commençais déjà à l'oublier.
Mais hier, cette demande a été ajoutée au maître.
Alors, de quoi parle mon histoire ? Et il parle du fait que, dans le cadre des technologies modernes, il s’est avéré que le vrai code peut déjà être écrit dans le navigateur, sans déployer localement d’outils de développement ni de dépendances.
De plus, je dois l'admettre, c'est déjà ma deuxième pull request pour des utilitaires bien connus (au moins dans les cercles étroits). La dernière fois, ma demande de correction de l'affichage de certains champs dans l'interface web de SyncThing a abouti à ma modification littéralement d'une seule ligne dans un environnement que je ne connais pas du tout.
Seuls les utilisateurs enregistrés peuvent participer à l'enquête. s'il te plait.
Dois-je écrire davantage ou pas ?
-
oui
-
ça ne vaut pas le coup
294 utilisateurs ont voté. 138 utilisateurs se sont abstenus.
Source: habr.com