ProHoster > Blogs > Administrācija > Nākotne jau ir klāt vai iekodējiet tieÅ”i pārlÅ«kprogrammā

Nākotne jau ir klāt vai iekodējiet tieÅ”i pārlÅ«kprogrammā

Es jums pastāstīŔu par smieklīgu situāciju, kas notika ar mani, un to, kā kļūt par līdzstrādnieku slavenā projektā.

Pirms neilga laika es izdomāju ideju: palaist Linux tieŔi no UEFI...
Ideja nav jauna, un par Å”o tēmu ir vairākas rokasgrāmatas. JÅ«s varat redzēt vienu no tiem Å”eit

PatiesÄ«bā mani ilgstoÅ”ie mēģinājumi atrisināt Å”o problēmu noveda pie pilnÄ«bā formalizēta lēmums. Risinājums ir diezgan efektÄ«vs, un es to izmantoju dažās savās mājas iekārtās. Å is risinājums ir aprakstÄ«ts nedaudz sÄ«kāk. Å”eit.

UEFI-Boot bÅ«tÄ«ba ir tāda, ka ESP (EFI System Partition) nodalÄ«jums tiek apvienots ar /boot direktoriju. Tie. visi kodoli un sāknÄ“Å”anas attēli (initrd) atrodas tajā paŔā nodalÄ«jumā, no kura UEFI var palaist izpildāmos failus un jo Ä«paÅ”i palaist sistēmas sāknÄ“Å”anas ielādes. Bet pats Linux kodols daudzos izplatÄ«jumos jau ir samontēts ar opciju UEFISTUB, kas ļauj palaist paÅ”u kodolu no UEFI.

Å im risinājumam ir viens nepatÄ«kams moments - ESP nodalÄ«jums ir formatēts FAT32, uz kura nav iespējams izveidot cietās saites (kuras sistēma regulāri izveido, atjauninot initrd). Un tur nav nekā Ä«paÅ”i krimināla, taču redzēt sistēmas brÄ«dinājumus kodola komponentu atjaunināŔanas laikā nav Ä«paÅ”i patÄ«kami...

Ir arī cits veids.

UEFI sāknÄ“Å”anas pārvaldnieks (tas pats, kur jāreÄ£istrē OS sāknÄ“Å”anas ielādētājs) var papildus bootloaderiem/Linux kodoliem ielādēt arÄ« draiverus. Tātad jÅ«s varat ielādēt draiveri failu sistēmai, kurā jums ir /boot, un ielādēt kodolu tieÅ”i no turienes, izmantojot UEFI. Draiveris, protams, ir jāievieto ESP nodalÄ«jumā. Tas ir aptuveni tas, ko dara sāknÄ“Å”anas ielādētāji, piemēram, GRUB. Bet galvenais ir tas, ka visas bieži izmantotās GRUB funkcijas jau ir UEFI. PrecÄ«zāk tā lejupielādes pārvaldniekā. Un, lai bÅ«tu vēl garlaicÄ«gāk, UEFI sāknÄ“Å”anas pārvaldniekam dažos jautājumos ir vēl lielākas iespējas.

Å Ä·iet, ka tas ir skaists risinājums, bet ir viens ā€œBETā€ (pareizāk sakot, tas bija, bet par to vēlāk). Fakts ir tāds, ka UEFI draiveru sistēma ir diezgan vienkārÅ”a. Nav tādas lietas kā failu sistēmas uzstādÄ«Å”ana vai draivera saistÄ«Å”ana ar noteiktu ierÄ«ci. Ir sistēmas izsaukums ar nosacÄ«to nosaukumu Map, kas ņem katru vadÄ«tāju pēc kārtas un mēģina to saistÄ«t ar visām, vismaz piemērotajām ierÄ«cēm. Un, ja vadÄ«tājs varēja paņemt ierÄ«ci, tiek izveidots kartējums - savienojuma ieraksts. TieÅ”i Ŕādā veidā tikko ielādētais draiveris ir jāinicializē kopējā kaudzē ar visiem pārējiem. Un viss, kas jums nepiecieÅ”ams, ir iestatÄ«t vienu bitu (LOAD_OPTION_FORCE_RECONNECT) uz 1 draivera sāknÄ“Å”anas ierakstā, un UEFI veiks Å”o globālo pārkartoÅ”anu pēc tā ielādes.

Bet tas nav tik vienkārÅ”i izdarāms. Standarta utilÄ«ta efibootmgr (kas tiek izmantota, lai konfigurētu UEFI izkrauÅ”anas pārvaldnieku) nezina, kā (vai drÄ«zāk, nezināja, kā) iestatÄ«t Å”o bitu. Man tas bija jāinstalē manuāli, izmantojot diezgan sarežģītu un bÄ«stamu procedÅ«ru.

Un atkal, mēģinot to izdarÄ«t ar savām rokām, es neizturēju un formalizējos problēma vietnē GitHub aicinot izstrādātājus pievienot Å”o funkciju.

Pagāja vairākas dienas, bet neviens manam lÅ«gumam nepievērsa uzmanÄ«bu. Un aiz ziņkārÄ«bas es paskatÄ«jos avota kodu... Es to sagriezu un uz ceļiem izdomāju, kā pievienot Å”o funkciju... ā€œUz ceļiemā€, jo es neko tādu neinstalēju un rediģēju avotu kodu tieÅ”i pārlÅ«kprogrammā.

Es zinu C (programmÄ“Å”anas valodu) ļoti virspusēji, bet es ieskicēju aptuvenu risinājumu (pārsvarā copy-paste)... un tad nodomāju - vismaz man tur ir daudz kļūdu (mana pagātnes mēģinājumi rediģēt kāda cita C kods tika aizpildÄ«ts apmēram 10. reizi) Es izsniegÅ”u Pull Request. Nu izdots.

Un tur izrādÄ«jās, ka Travis CI ir pievienots, lai pārbaudÄ«tu pull pieprasÄ«jumus. Un viņŔ man cÄ«tÄ«gi izstāstÄ«ja visas manas kļūdas. Ja ir zināmas kļūdas, tās nav jālabo: atkal tieÅ”i pārlÅ«kprogrammā, un ceturtajā mēģinājumā kods darbojās (man tas ir sasniegums).

Un tieÅ”i tāpat, neizejot no pārlÅ«kprogrammas, es formatēju ļoti Ä«stu Pull Request utilÄ«tprogrammā, kas tiek izmantota gandrÄ«z visos mÅ«sdienu Linux izplatÄ«jumos.

Mani pārsteidza fakts, ka, Ä«sti nezinot valodu, neko neiestatot (atkarÄ«bu montāžai ir vajadzÄ«gas diezgan daudzas bibliotēkas) un pat nepalaižot kompilatoru, es vienkārÅ”i ā€œiekodējuā€ pilnÄ«bā strādājoÅ”u un noderÄ«gu funkciju pārlÅ«kprogramma.

Tomēr kopÅ” 19. gada 2019. marta mans pieprasÄ«jums palika bez atsauces, un es jau biju sācis par to aizmirst.

Bet vakar Ŕis pieprasījums tika pievienots meistaram.

Par ko tad ir mans stāsts? Un viņŔ runā par to, ka mÅ«sdienu tehnoloÄ£iju ietvaros izrādÄ«jās, ka reālu kodu jau var ierakstÄ«t pārlÅ«kprogrammā, lokāli neizvietojot nekādus izstrādes rÄ«kus un atkarÄ«bas.

Turklāt, jāatzÄ«st, Å”is jau ir mans otrais pievilcÄ«bas pieprasÄ«jums labi zināmiem (vismaz Å”aurās aprindās) komunālajiem pakalpojumiem. IepriekŔējā reizē mans lÅ«gums labot dažu SyncThing tÄ«mekļa saskarnes lauku rādÄ«jumus izraisÄ«ja manu burtiski vienas rindiņas rediģēŔanu vidē, kuru es vispār nezinu.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai man rakstīt vairāk vai nē?

  • jā

  • nav tā vērts

Nobalsoja 294 lietotāji. 138 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru