Elmondok egy furcsa helyzetet, ami velem történt, és hogyan lehet hozzájárulni egy ismert projekthez.
Nemrégiben egy ötlet körül sürgölődtem: Linux betöltése közvetlenül UEFI-ből...
Az ötlet nem új, és van néhány útmutató e témában. Az egyiket meg lehet nézni
A régóta tartó próbálkozásaim e kérdés megoldására egy viszonylag kidolgozott megoldásra vezettek, amely teljesen működőképes, és én is használom néhány otthoni gépemen. Kicsit részletesebben ezt a megoldást ismertetem .
Az UEFI-Boot lényege, hogy az ESP (EFI System Partition) partíció összekapcsolódik a /boot könyvtárral. Vagyis minden kernel és a kezdeti betöltő képek (initrd) azon a partíción helyezkednek el, ahonnan az UEFI végrehajtható fájlokat indíthat, különösen a rendszerindítókat. Azonban sok disztribúcióban a Linux kernel már a UEFISTUB opcióval van összeállítva, ami lehetővé teszi, hogy a kernel UEFI-ből induljon.
Ennek a megoldásnak van egy kellemetlen momentuma - az ESP partíció FAT32-re van formázva, amely nem teszi lehetővé a kemény linkek létrehozását (amelyeket a rendszer rendszeresen létrehoz az initrd frissítésekor). Ezen nincs különösebb baj, de a kernel alkotóelemeinek frissítése során a rendszer figyelmeztetéseit látni nem éppen kellemes...
Van egy másik megoldás is.
Az UEFI betöltő menedzser (ahová be kell írni az operációs rendszer indítóját) nemcsak Linux indítókat/kernelt tud tölteni, hanem illesztőprogramokat is. Tehát betöltheted annak a fájlrendszernek az illesztőprogramját, ahol a /boot található, és közvetlenül onnan töltheted be a kernelt UEFI eszközökkel. Az illesztőprogramot természetesen az ESP partícióra kell helyezni. Ezt általában a GRUB típusú betöltők végzik. A lényeg az, hogy minden gyakran használt GRUB-funkció már megtalálható UEFI-ben. Pontosabban a betöltő menedzserében. Ha pedig még tovább menünk, akkor a UEFI betöltő menedzsernek bizonyos kérdésekben még több lehetősége is van.
Úgy tűnik, hogy szép megoldás, de van egy "DE" (vagy inkább volt, de erről később). Az a helyzet, hogy az UEFI illesztőprogramok rendszere meglehetősen egyszerű. Nincs olyan fogalom, mint a fájlrendszer csatlakoztatása vagy az illesztőprogram összekapcsolása egy adott eszközzel. Van egy rendszerhívás, amelynek feltételes neve Map, amely sorban veszi az összes illesztőprogramot, és megpróbálja összekapcsolni őket minden, többé-kevésbé megfelelő eszközzel. Ha az illesztőprogramnak sikerül csatlakoznia az eszközhöz, akkor létrejön egy térképezés — egy összekapcsolási bejegyzés. Éppen így kell inicializálni az újra betöltött illesztőprogramot a többi között. Mindössze annyira van szükség — a boot bejegyzésben be kell állítani egy bitet (LOAD_OPTION_FORCE_RECONNECT) 1-re, és az UEFI ezen bit betöltése után elvégzi ezt a globális újramappolást.
Csak éppen ezt megtenni nem olyan egyszerű. A standard efibootmgr segédprogram (amelyet az UEFI boot menedzser beállításához használnak) nem tudta (pontosabban nem tudta) beállítani ezt a bitet. Kézzel kellett ezt megtenni egy meglehetősen bonyolult és veszélyes eljáráson keresztül.
Most, hogy újra próbálkoztam ezzel kézzel, nem tudtam ellenállni, és létrehoztam kérve a fejlesztőket, hogy adják hozzá ezt a lehetőséget.
Pár nap eltelt, de senki nem figyelt a kérvésemre. Kíváncsiságból megnéztem a forrást... leforkoltam, és pár ötletet vetettem fel "a térben", hogyan lehetne ezt a funkciót hozzáadni... "a térben", mert semmi komolyat nem telepítettem, és közvetlenül a böngészőben szerkesztettem a forrást.
A (programozási nyelv) C-t nagyon felszínesen ismerem, de nagyjából összehoztam a megoldást (főként másolás-beillesztés révén)... aztán pedig eszembe jutott — akár ha biztosan van sok hibám (a múltbeli próbálkozásaim mások C-kódjának szerkesztésére a 10. próbálkozásra álltak össze) — létrehozok egy Pull Request-t. Nos, és .
Aztán kiderült, hogy a Travis CI integrálva van a pull requestek ellenőrzésére. És ő ügyesen mindent a hibáimról kiadott. Nos, ha ismertek a hibák — miért ne javítanám meg: megint közvetlenül a böngészőben, és a negyedik próbálkozás után a kód összeállt (számomra ez egy teljesítmény).
Így hát, anélkül, hogy elhagytam volna a böngészőt, létrehoztam egy teljesen valós Pull Request-et az eszközhöz, amelyet gyakorlatilag minden modern Linux disztribúciónál használnak.
Magam is meglepetés volt, hogy nyelvtudás nélkül, anélkül, hogy bármilyen beállítást végeztem volna (ott a függőségekhez nem kis csomó könyvtár szükséges a fordításhoz), és egyszer sem indítottam el a fordítót, egyszerűen a böngészőben "kodoltam" egy teljesen működő és hasznos funkciót.
Azonban a kérdésem 2019. március 19. óta reagálás nélkül lógott, és már kezdtem elfelejteni.
De tegnap ezt a kérdést hozzáadták a masterhez.
Miről is szól a mesém? Arról, hogy a modern technológiák keretében kiderült, hogy a tényleges kódot már a böngészőben is lehet írni, anélkül, hogy helyileg bármilyen fejlesztői eszközt és függőséget beállítanánk.
Egyébként be kell vallanom, hogy ez már a második pull requestem ismert (legalábbis szűk körökben) eszközökben. Az előző alkalommal a kérdésem, hogy javítsák a SyncThing webes felületének néhány mezőjének megjelenítését, gyakorlatilag egy sorte módosítást eredményezett egy olyan környezetben, amelyet egyáltalán nem ismerek.
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Érdemes még írni vagy sem
igen
nem érdemes
294 felhasználó szavazott. 138 felhasználó tartózkodott.
Forrás: habr.com
