Ik zal een curieuze situatie vertellen die mij is overkomen, en hoe je een bijdrager kunt worden aan een bekend project.
Niet zo lang geleden was ik bezig met een idee: het opstarten van Linux rechtstreeks vanuit UEFI...
Het idee is niet nieuw en er zijn verschillende handleidingen over dit onderwerp. Een daarvan is hier te bekijken.
Eigenlijk zijn mijn langdurige pogingen om deze kwestie op te lossen uitgegroeid tot een redelijk goed uitgewerkt plan. . De oplossing is volledig functioneel en ik gebruik het op een deel van mijn thuiscomputers. Dit wordt iets gedetailleerder beschreven. .
De essentie van UEFI-Boot is dat de ESP (EFI-systeempartitie) samenvalt met de map /boot. Dat wil zeggen, alle kernels en initiƫle opstartbeelden (initrd) worden op diezelfde partitie geplaatst vanaf waar UEFI uitvoerbare bestanden kan starten en specifiek de opstartprogramma's van het systeem kan starten. Maar de kernel van Linux wordt al in veel distributies samengesteld met de UEFISTUB-optie, die het mogelijk maakt de kernel zelf vanuit UEFI te starten.
Er is Ć©Ć©n onaangenaam aspect aan deze oplossing: de ESP-partitie is geformatteerd in FAT32, waar je geen harde links kunt maken (die het systeem regelmatig maakt bij het bijwerken van initrd). En daar is verder niets ernstig aan, maar het is niet prettig om waarschuwingen van het systeem te zien bij het bijwerken van de kernelcomponenten...
Er is ook een andere weg.
De UEFI-opstartbeheerder (de plaats waar je de opstarter van het besturingssysteem moet registreren) kan naast opstartprogramma's/kernels van Linux ook stuurprogramma's laden. Dus je kunt het stuurprogramma van het bestandssysteem, waar /boot zich bevindt, laden en daar direct de kernel opstarten met UEFI-middelen. Het stuurprogramma moet uiteraard in de ESP-partitie worden geplaatst. Dit is ongeveer wat opstartprogramma's zoals GRUB doen. Maar het interessante is dat alle vaak gebruikte functies van GRUB al in UEFI aanwezig zijn. Juist, in zijn opstartbeheerder. En om het nog ingewikkelder te maken, de UEFI-opstartbeheerder heeft zelfs meer mogelijkheden in bepaalde opzichten.
Het lijkt een mooie oplossing, maar er is Ć©Ć©n "MAAR" (of eerder was het, maar daarover later meer). Het probleem is dat het UEFI-driver systeem behoorlijk eenvoudig is opgebouwd. Er is geen concept zoals het monteren van een bestandssysteem of het koppelen van een driver aan een specifiek apparaat. Er is een systeemaanroep met de voorwaardelijke naam Map die elk driver een voor een oppakt en probeert deze te koppelen aan alle, min of meer geschikte apparaten. En als de driver een apparaat kan koppelen, wordt er een mapping ā een koppelvermelding ā aangemaakt. Op precies die manier moet de opnieuw geladen driver worden geĆÆnitialiseerd binnen de grote hoop van alle anderen. En alles wat nodig is ā in het opstartrecord van de driver gewoon Ć©Ć©n bit (LOAD_OPTION_FORCE_RECONNECT) op 1 zetten, en UEFI zal na de laadtijd deze globale remap uitvoeren.
Maar dit is niet zo eenvoudig te doen. De standaardtool efibootmgr (deze wordt gebruikt om de UEFI-laadbeheer configuratie in te stellen) kan (of beter gezegd kon) dit bit niet zetten. Je moest het met de hand doen via een vrij complexe en gevaarlijke procedure.
En weer eens, terwijl ik het met de hand probeerde te doen, kon ik het niet langer volhouden en heb ik met het verzoek aan de ontwikkelaars om deze mogelijkheid toe te voegen.
Er zijn enkele dagen verstreken, maar niemand heeft op mijn verzoek gereageerd. En uit nieuwsgierigheid heb ik de broncode bekekenā¦ geforkt, en bedacht hoe ik deze functie "uit de losse pols" kon toevoegenā¦ "uit de losse pols" omdat ik niets bijzonders had geĆÆnstalleerd en de broncode gewoon in de browser bewerkte.
Van C (de programmeertaal) weet ik heel oppervlakkig iets af, maar ik heb ongeveer een oplossing in elkaar gezet (voornamelijk door te kopiĆ«ren en plakken)ā¦ goed, later dacht ik ā als ik daar toch ongetwijfeld vol fouten zit (mijn eerdere pogingen om iemands C-code te corrigeren verzamelden zich pas na de tiende poging) laat ik maar een Pull Request indienen. En toen .
Blijkbaar was er Travis CI aangesloten voor het controleren van pull requests. En hij gaf me zorgvuldig al mijn fouten aan. Nou, als de fouten bekend zijn ā waarom ze niet corrigeren: weer direct in de browser, en na de vierde poging compileerde de code (een prestatie voor mij).
En zo heb ik, zonder mijn browser te verlaten, een volkomen reƫle Pull Request ingediend voor de tool die praktisch in alle moderne Linux-distributies wordt gebruikt.
Ik was zelf verbaasd over het feit dat ik, zonder de taal echt te kennen en zonder iets zelf in te stellen (er zijn daar nogal wat afhankelijkheden van verschillende bibliotheken nodig voor de opbouw), en zelfs zonder ooit de compiler te hebben opgestart, gewoon in de browser een vrij werkende en nuttige functie 'gecodeerd' heb.
Echter, mijn verzoek hing zonder reactie sinds 19 maart 2019, en ik begon er al over te vergeten.
Maar gisteren werd dit verzoek toegevoegd aan de master.
Waar gaat mijn verhaal over? Het gaat erover dat het in de moderne technologie mogelijk is om echte code te schrijven in de browser, zonder lokaal enige ontwikkeltools en afhankelijkheden op te zetten.
Overigens, ik moet toegeven, dit is mijn tweede pull request voor bekende (tenzij in kleine kringen) tools. De vorige keer leidde mijn verzoek om enkele velden in de webinterface van SyncThing aan te passen tot mijn letterlijk eenregelige aanpassing in een omgeving die ik helemaal niet ken.
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquĆŖte. , alstublieft.
Moet ik nog meer schrijven of niet?
ja
niet aan te raden is
294 gebruikers hebben gestemd. 138 gebruikers hebben zich onthouden.
Bron: habr.com
