Ik zal je vertellen over een grappige situatie die mij is overkomen, en hoe je een bijdrage kunt leveren aan een beroemd project.
Nog niet zo lang geleden zat ik met een idee te sleutelen: Linux rechtstreeks vanuit UEFI opstarten...
Het idee is niet nieuw en er zijn een aantal handleidingen over dit onderwerp. Je kunt er een zien
Eigenlijk resulteerden mijn langdurige pogingen om dit probleem op te lossen in een volledig geformaliseerd probleem . De oplossing werkt behoorlijk en ik gebruik hem op sommige van mijn thuismachines. Deze oplossing wordt iets gedetailleerder beschreven. .
De essentie van UEFI-Boot is dat de ESP-partitie (EFI System Partition) wordt gecombineerd met de map /boot. Die. alle kernels en bootstrap-images (initrd) bevinden zich op dezelfde partitie van waaruit UEFI uitvoerbare bestanden kan starten en, in het bijzonder, systeemopstartladers kan starten. Maar de Linux-kernel zelf is in veel distributies al geassembleerd met de UEFISTUB-optie, waarmee de kernel zelf vanuit UEFI kan worden gestart.
Deze oplossing heeft één onaangenaam moment: de ESP-partitie is geformatteerd in FAT32, waarop het onmogelijk is om harde links te maken (die het systeem regelmatig maakt bij het updaten van de initrd). En daar is niets bijzonder misdadigs aan, maar het zien van systeemwaarschuwingen bij het updaten van kernelcomponenten is niet erg prettig...
Er is een andere manier.
De UEFI-bootmanager (dezelfde waar je de OS-bootloader moet registreren) kan, naast bootloaders/Linux-kernels, ook stuurprogramma's laden. U kunt dus het stuurprogramma laden voor het bestandssysteem waar u /boot hebt en de kernel rechtstreeks vanaf daar laden met behulp van UEFI. De bestuurder moet uiteraard in de ESP-partitie worden geplaatst. Dit is ongeveer wat bootloaders zoals GRUB doen. Maar het hoogtepunt is dat alle veelgebruikte GRUB-functies al in UEFI aanwezig zijn. Meer precies in de downloadmanager. En om het nog saaier te maken: de UEFI-opstartmanager heeft in sommige zaken nog meer mogelijkheden.
Het lijkt een mooie oplossing, maar er is één “MAAR” (of beter gezegd, dat was het, maar daarover later meer). Feit is dat het UEFI-stuurprogramma vrij eenvoudig is. Er bestaat niet zoiets als het mounten van een bestandssysteem of het koppelen van een stuurprogramma aan een specifiek apparaat. Er is een systeemoproep met de conventionele naam Map, die elke bestuurder om de beurt neemt en deze probeert te associëren met alle, in ieder geval geschikte apparaten. En als de chauffeur het apparaat heeft kunnen ophalen, wordt er een mapping gemaakt: een verbindend record. Dit is precies hoe het nieuw geladen stuurprogramma moet worden geïnitialiseerd in een gemeenschappelijke heap met alle anderen. En het enige dat u nodig hebt, is één bit (LOAD_OPTION_FORCE_RECONNECT) in te stellen op 1 in het opstartrecord van het stuurprogramma, waarna UEFI deze globale remap zal uitvoeren nadat het is geladen.
Maar dit is niet zo eenvoudig om te doen. Het standaard hulpprogramma efibootmgr (dat wordt gebruikt om de UEFI-offloadmanager te configureren) weet niet hoe (of beter gezegd, wist niet hoe) dit bit in te stellen. Ik moest het handmatig installeren via een nogal ingewikkelde en gevaarlijke procedure.
En nogmaals, nadat ik het met mijn handen had geprobeerd, kon ik het niet uitstaan en formaliseerde ik het ontwikkelaars vragen om deze functie toe te voegen.
Er gingen enkele dagen voorbij, maar niemand besteedde aandacht aan mijn verzoek. En uit nieuwsgierigheid keek ik naar de broncode... ik splitste het en bedacht op mijn knieën hoe ik deze functie kon toevoegen... "Op mijn knieën" omdat ik zoiets niet had geïnstalleerd en de broncode had bewerkt code rechtstreeks in de browser.
Ik ken C (de programmeertaal) heel oppervlakkig, maar ik schetste een oplossing bij benadering (meestal kopiëren-plakken)... en toen dacht ik - daar zitten in ieder geval waarschijnlijk veel fouten (mijn eerdere pogingen om die van iemand anders te bewerken C-code is ongeveer voor de 10e keer voltooid) Ik zal een Pull Request uitgeven. Goed .
En daar bleek Travis CI aangesloten om pull-requests te controleren. En hij vertelde me ijverig al mijn fouten. Nou, als er bekende fouten zijn, is het niet nodig om deze te repareren: nogmaals, rechtstreeks in de browser, en bij de vierde poging werkte de code (een prestatie voor mij).
En zomaar, zonder de browser te verlaten, heb ik een heel echt Pull Request geformatteerd in een hulpprogramma dat in bijna alle moderne Linux-distributies wordt gebruikt.
Ik was verrast door het feit dat ik, zonder de taal echt te kennen, zonder iets in te stellen (afhankelijkheden vereisen nogal wat bibliotheken voor assemblage), en zonder zelfs maar de compiler uit te voeren, eenvoudigweg een volledig werkende en nuttige functie in de browser.
Sinds 19 maart 2019 reageerde mijn verzoek echter niet meer, en ik begon het al te vergeten.
Maar gisteren is dit verzoek toegevoegd aan master.
Dus waar gaat mijn verhaal over? En hij heeft het over het feit dat, binnen het raamwerk van moderne technologieën, is gebleken dat echte code al in de browser kan worden geschreven, zonder lokaal ontwikkelingstools en afhankelijkheden in te zetten.
Bovendien moet ik toegeven dat dit al mijn tweede pull-verzoek is voor bekende (althans in kleine kringen) hulpprogramma's. De vorige keer resulteerde mijn verzoek om de weergave van enkele velden in de SyncThing-webinterface te corrigeren in mijn letterlijk éénregelige bewerking in een omgeving die ik helemaal niet ken.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Moet ik nog meer schrijven of niet?
-
ja
-
niet de moeite waard
294 gebruikers hebben gestemd. 138 gebruikers onthielden zich van stemming.
Bron: www.habr.com