Differences
This shows you the differences between two versions of the page.
|
si:laboratoare:yocto-extra1 [2022/01/14 08:51] florin.stancu created |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Extended Yocto Tutorial ===== | ||
| - | |||
| - | Acest text vine ca supliment al laboratorului de Yocto și dorește să ofere informații pas cu pas despre îndeplinirea unor sarcini frecvente la generarea unei distribuții Linux (i.e., vă ajută la [[:si:teme2021:tema2|Tema 2]] :P). | ||
| - | |||
| - | |||
| - | ==== Mediul de lucru ==== | ||
| - | |||
| - | Pentru început, aveți nevoie de [[:si:teme2021:tema2#helpers_masina_virtuala|mașina virtuală furnizată la Tema 2]] descărcată. | ||
| - | |||
| - | Se recomandă să aveți ultima versiune de VMWare Workstation instalată, pe care o puteți descărca gratis de pe portalul [[https://vmware.pub.ro/]] (vă autentificați cu contul unic al facultății). | ||
| - | |||
| - | Recomandat ar fi să faceți uz de funcționalitatea de VM snapshotting pe care o pune VMWare la dispoziție, astfel încât să puteți pleca de la imaginea de bază (pe care să o țineți nemodificată!) și să aveți mai multe instanțe separate (sub forma unor snapshot-uri) pe care le puteți comuta manual după caz. De exemplu, doriți să experimentați ceva cu Yocto: faceți un snapshot nou, vă jucați liberi în acea instanță apoi, dacă experimentul a eșuat, puteți reveni mereu la starea anterioară a snapshot-ului (cu fișierele de atunci). | ||
| - | |||
| - | Pentru un ghid de folosire a snapshot-urilor în VMWare, vedeți [[https://linuxhint.com/take-virtual-machines-snapshots-vmware-workstation/|pagina aceasta]]. **TLDR:** Ctrl+M în VMWare pentru Snapshot Manager ;) | ||
| - | |||
| - | <note> | ||
| - | Un snapshot ocupă spațiu cât doar pentru modificările aduse la imaginea lui de bază (sau un alt snapshot pe care este bazat). | ||
| - | Folosiți cu încredere, însă este posibil ca spațiul de modificări făcute la un build să aibe ''~8 GB'' (puteți oricând combina snapshoturile reușite pentru a reduce spațiul). | ||
| - | </note> | ||
| - | |||
| - | <note tip> | ||
| - | Proiectul de VM al temei are deja un snapshot inițial făcut, dacă stricați ceva veți putea mereu reveni la varianta inițială a acestuia fără să-l re-descărcați ;) | ||
| - | </note> | ||
| - | |||
| - | |||
| - | ==== Starea / build-ul inițial, introducere kas ==== | ||
| - | |||
| - | Considerăm starea inițială a fișierelor din VM cu următoarea structură (doar cele de interes pentru laboratorul de față, altele pot fi prezente, e.g. din toolbox-ul temei 2, însă le vom ignora momentan): | ||
| - | <code> | ||
| - | /home/student/yocto: | ||
| - | |-- build # (generat de kas + Yocto bitbake) | ||
| - | | |-- cache | ||
| - | | |-- conf | ||
| - | | |-- conf # generate automat din kas.yml | ||
| - | | | |-- bblayers.conf | ||
| - | | | |-- local.conf | ||
| - | | | `-- templateconf.cfg | ||
| - | | `-- tmp | ||
| - | |-- layers # (descărcate prin kas) | ||
| - | | |-- meta-raspberrypi | ||
| - | | `-- poky | ||
| - | |-- kas.yml | ||
| - | </code> | ||
| - | |||
| - | Per parcursul acestui document, vom considera strict acest director de bază (neavând treabă în alte locuri). | ||
| - | |||
| - | În VM a fost deja invocat utilitarul ''[[https://kas.readthedocs.io/en/0.19.0/intro.html|kas]]'' (vedeți și documentația oficială), care a avut următoarele efecte: | ||
| - | |||
| - | * a clonat (descărcat) de pe git-ul oficial proiectele [[https://git.yoctoproject.org/poky/tree/|poky]] (ce conține sursele și scripturile principale ale Yocto) și [[https://github.com/agherzan/meta-raspberrypi/|meta-raspberrypi]] (Layer oficial pentru plăcuțele RaspberryPi); toate acestea pe baza descrierii din secțiunea ''repos'' a fișierului ''kas.yml''. | ||
| - | * a generat fișierele de configurare ale build-ului Yocto: ''build/conf/{bblayers.conf,local.conf,templateconf.cfg}''. | ||
| - | * a făcut un ''bitbake build'' inițial la imaginea de bază a distribuției Poky (''core-image-base''), lucru ce poate dura chiar și câteva ore (pentru compilarea atât a toolchain-ului, cât și ale kernelului și ale tuturor pachetelor instalate în distribuția de bază); din fericire, o dată compilate aceste pachete, vor rămâne în cache și vor fi refolosite la toate build-urile ulterioare (decât dacă schimbați versiunea layerelor descărcate sau doriți să upgradați pachetele -- we don't do that here!). | ||
| - | |||
| - | Deși acest mic tool ne-a automatizat din munca de setup a unui proiect nou Yocto, acesta vine cu inconvenientul că, dacă dorim să modificăm unul dintre fișierele generate (din ''build/conf/''), va trebui s-o facem prin intermediul fișierului de configurare ''kas.yml'' (more on this later). | ||
| - | |||
| - | De menționat ar fi faptul că imaginea de bază conține strict pachetele prevăzute de către fișierele implicite de configurare ale Poky și atât. Nu este nici măcar folosibilă în starea aceasta inițială (neavând parolă la contul de ''root''). | ||
| - | Pentru a schimba aceste lucruri avem nevoie să ne construim propriul layer, ceea ce vom și face în secțiunea următoare. | ||
| - | |||
| - | Observați faptul că nu puteți rula ''bitbake'' (dă ''command not found''). Acesta un executabil care nu se află de obicei în ''$PATH''-ul normal al sistemelor Linux, putând fi accesat doar după inițializarea mediului Yocto. | ||
| - | Reamintim că utilitarul ''kas'' ne-a descărcat codul sursă al ''poky'' în calea ''layers/poky/''. | ||
| - | |||
| - | Tot aici găsim și scriptul ''oe-init-build-env'' responsabil de inițializarea. | ||
| - | Astfel, dacă încărcăm acest script în shell-ul curent: <code bash> | ||
| - | student@vm:~/yocto$ source layers/poky/oe-init-build-env | ||
| - | ### Shell environment set up for builds. ### | ||
| - | You can now run 'bitbake <target>' | ||
| - | ... | ||
| - | </code> | ||
| - | ... utilitarele Yocto devin accesibile (însă doar în shell-ul actual, dacă utilizați mai multe terminale sau îl re-deschideți pe acesta, va trebui să repetați comanda în fiecare). **Atenție!** Comanda ne schimbă directorul nostru actual în ''build/'', dăm ''cd ..'' pentru a reveni în rădăcina proiectului nostru. | ||
| - | |||
| - | ==== 1. Layere și rețete ==== | ||
| - | |||
| - | [[https://docs.yoctoproject.org/overview-manual/yp-intro.html#the-yocto-project-layer-model|Un layer]] este, practic, o colecție de sine stătătoare de scripturi, metadate și alte resurse construcție a unui sistem Linux. | ||
| - | O distribuție Yocto este, practic, compusă din unul sau mai multe straturi așezate unul peste altul (unde Poky, desigur, stă la baza acestora) ce aplică operații de build într-o anumită ordine pentru a obține rezultatul dorit. | ||
| - | |||
| - | Pentru a crea un layer nou, putem folosi comanda ''bitbake-layers'': <code bash> | ||
| - | student@vm:~/yocto/build$ cd ../ # navigăm în afara directorului build/ | ||
| - | student@vm:~/yocto$ bitbake-layers create-layer meta-tutorial-si | ||
| - | NOTE: Starting bitbake server... | ||
| - | Add your new layer with 'bitbake-layers add-layer meta-tutorial-si' | ||
| - | </code> | ||
| - | |||
| - | <note info> | ||
| - | Nu recomandăm utilizarea directorului ''build/'' pentru a stoca codul layerelor, deoarece va fi ignorat de scriptul care împachetează arhiva cu sursele. La fel și cu directorul ''layers/'' (aici sunt stocate layerele third-party ce au fost / vor fi descărcate automat prin //kas//). | ||
| - | </note> | ||
| - | |||
| - | Această comandă va genera scheletul pentru noul nostru layer într-un director cu numele furnizat ca parametru. | ||
| - | Structura layer-ului nou creat va fi următoarea: <code> | ||
| - | meta-tutorial-si/ | ||
| - | |-- conf | ||
| - | | `-- layer.conf # variabile de configurație utilizate de layer | ||
| - | |-- COPYING.MIT | ||
| - | |-- README | ||
| - | `-- recipes-example # ce drăguț, avem și exemplu de o rețetă ;) | ||
| - | `-- example | ||
| - | `-- example_0.1.bb | ||
| - | </code> | ||
| - | |||
| - | Un ghid oficial pentru creare layere puteți [[https://docs.yoctoproject.org/dev-manual/common-tasks.html#understanding-and-creating-layers|găsi aici]] (să îl puteți consulta ulterior). | ||
| - | |||
| - | |||
| - | === Recipes (rețete) === | ||
| - | |||
| - | Pentru a fi util, un layer conține una sau mai multe rețete. | ||
| - | O rețetă este un fișier ''.bb'' cu sintaxă specială Bitbake ce descriu pașii de urmat de către sistemul de build pentru a genera pachete sau altera configurația unei distribuții. Apoi mai avem fișiere ''.bbappend'' care ne permit să re-configurăm rețetele din alte layere fără a le rescrie. | ||
| - | [[https://docs.yoctoproject.org/dev-manual/common-tasks.html#writing-a-new-recipe|Ghid oficial aici]]. | ||
| - | |||
| - | Rețetele se află, de obicei, într-un director cu prefixul **//recipes-//** în denumirea lor, însă comportamentul real este definit în fișierul layer.conf:<code make> | ||
| - | # We have recipes-* directories, add to BBFILES | ||
| - | BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ | ||
| - | ${LAYERDIR}/recipes-*/*/*.bbappend" | ||
| - | </code> | ||
| - | A se observa regula de globbing: se caută recursiv în orice director ce urmează această convenție, precum și sufixul de versionare ([[https://docs.yoctoproject.org/dev-manual/common-tasks.html#storing-and-naming-the-recipe|obligatoriu]]). | ||
| - | Desigur, nu avem de ce să o schimbăm, așa că trecem mai departe ;) | ||
| - | |||
| - | O rețetă are o sintaxă relativ similară cu o combinație de Makefile și script de shell (e.g., bash). | ||
| - | Putem vedea asta prin exemplul generat de //create-layer//:<code make> | ||
| - | SUMMARY = "bitbake-layers recipe" | ||
| - | DESCRIPTION = "Recipe created by bitbake-layers" | ||
| - | ... | ||
| - | python do_display_banner() { | ||
| - | # ... | ||
| - | bb.plain("* Example recipe created by bitbake-layers *"); | ||
| - | } | ||
| - | addtask display_banner before do_build | ||
| - | </code> | ||
| - | A se observa că este posibilă definirea de funcții în alte limbaje integrate (SHell sau chiar Python) ce se vor executa într-un anumit pas al procesului de build (vedeți [[https://docs.yoctoproject.org/dev-manual/common-tasks.html#overview|diagrama din documentația oficială]] pentru o idee). | ||
| - | |||
| - | Pentru a folosi layer-ul nou creat, este necesar ca acesta să fie introdus în fișierul (global) de configurație al Yocto referitor la acestea: ''bblayers.conf''. Ne reamintim, însă, faptul că tool-ul nostru helper de build va suprascrie orice modificări vom face. | ||
| - | Defapt, ne generează lista de straturi pe baza unui fișier de configurație ''kas.yml'', deci vom adăuga layer-ul nostru acolo: <code yaml> | ||
| - | # ... | ||
| - | repos: | ||
| - | # adăugăm, pur și simplu, o cheie nouă (opțional, putem să modificăm calea către layer) | ||
| - | meta-tutorial-si: | ||
| - | path: './meta-tutorial-si' | ||
| - | # atenție la identare! contează... yaml s-a inspirat din python :( | ||
| - | |||
| - | # ... restul de layere au fost descărcate prin URL de git... | ||
| - | meta-raspberrypi: | ||
| - | url: git://git.yoctoproject.org/meta-raspberrypi | ||
| - | # ... | ||
| - | </code> | ||
| - | |||
| - | Rulăm apoi ''kas build kas.yml''. Observăm că, în ''build/conf/bblayers.conf'' ne-a apărut layer-ul:<code make> | ||
| - | BBLAYERS ?= " \ | ||
| - | /home/student/yocto/layers/meta-raspberrypi \ | ||
| - | ... | ||
| - | /home/student/yocto/meta-tutorial-si" # <-- here it is | ||
| - | </code> | ||
| - | |||
| - | Doar că trebuia să ne printeze mesajul acela din rețeta //Example// la build, ceea ce nu se întâmplă... de ce oare? (heheee) | ||
| - | Să facem altfel: <code bash> | ||
| - | # REMINDER: să aveți oe-init-build-env activat! | ||
| - | student@vm:~/yocto$ bitbake example # să aveți oe-init-build-env activat! | ||
| - | Loading cache: 100% |##########| Time: 0:00:00 | ||
| - | ... | ||
| - | NOTE: Executing Tasks | ||
| - | *********************************************** | ||
| - | * * | ||
| - | * Example recipe created by bitbake-layers * | ||
| - | * * | ||
| - | *********************************************** | ||
| - | </code> | ||
| - | |||
| - | Now we're getting somewhere! Mai rămâne, deci, să adăugăm această rețetă undeva să fie executată la build-ul imaginii principale (//reminder:// denumită **''core-image-base''**: | ||
| - | <code bash> | ||
| - | student@vm:~/yocto$ cd meta-tutorial-si/ | ||
| - | student@vm:~/yocto/meta-tutorial-si$ mkdir -p recipes-core/images/ | ||
| - | student@vm:~/yocto/meta-tutorial-si$ vim recipes-core/images/core-image-base.bbappend | ||
| - | # iar în fișier vom scrie: (suntem în vim, deci apăsăm un 'i' înainte pentru insert mode) | ||
| - | IMAGE_INSTALL += " example" | ||
| - | # :wq ca să nu rămânem blocați :P | ||
| - | student@vm:~/yocto$ cd ../ | ||
| - | student@vm:~/yocto$ kas build kas.yml | ||
| - | </code> | ||
| - | |||
| - | ... //et voila!// | ||
| - | |||
| - | **Cum funcționează:** am extins rețeta imaginii de bază printr-un fișier ''.bbappend'' (pentru asta au fost concepute). Codul nostru va fi procesat după fișierul ''.bb'' original, astfel putând modifica [[https://docs.yoctoproject.org/singleindex.html#term-IMAGE_INSTALL|variabila IMAGE_INSTALL]] pentru a ne fi incluse pachete custom de către task-urile rețetei generatoare de imagine. | ||
| - | Also check [[https://docs.yoctoproject.org/singleindex.html#ref-features-image|these goodies]] (chestii gata făcute incluzabile printr-o linie de cod). | ||
| - | |||
| - | Ca alternativă, puteam construi o nouă imagine (e.g., ''tutorial-si-image'') care să pornească de la prima. Doar că trebuia să build-uim noua noastră imagine (''bitbake tutorial-si-image'' în loc de ''core-image-base''). | ||
| - | |||
| - | <note> | ||
| - | Am fi putut să facem același lucru prin modificarea ''conf/local.conf'' și adăugarea unei linii:<code make> | ||
| - | IMAGE_INSTALL_append = " example" | ||
| - | </code> | ||
| - | ... dar este, desigur, anti-practică! Vrem să avem toată funcționalitatea încapsulată în layer bine definit, păi ce facem noi aici... :P | ||
| - | </note> | ||
| - | |||
| - | |||
| - | ==== 2. Construirea unei distribuții utilizabile ==== | ||
| - | |||
| - | Înainte de a continua, **să aveți un layer creat** (e.g., ''meta-tutorial-si'' de la pasul anteror sau, desigur, puteți să folosiți ce altă denumire doriți) pe care îl vom extinde. | ||
| - | |||
| - | Pentru a avea o distribuție Linux utilizabilă va trebui, desigur, să avem creat un utilizator ;) | ||
| - | Apoi vom demonstra adăugarea de resurse (fișiere) în imaginea de bază. | ||
| - | |||
| - | === 2.1. Adăugare utilizator nou === | ||
| - | |||
| - | Se dă [[https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password|tutorialul acesta]]. Cum se procedează mai departe? | ||
| - | |||
| - | //"In your image recipe:"//. Deci ''vim meta-tutorial-si/recipes-core/images/core-image-base.bbappend'': | ||
| - | <code make> | ||
| - | # vechiul conținut: | ||
| - | IMAGE_INSTALL += "example" | ||
| - | # mai adăugăm: | ||
| - | inherit extrausers | ||
| - | # pentru a schimba parola la root: | ||
| - | EXTRA_USERS_PARAMS += "usermod -P student root;" | ||
| - | # pentru a adăuga un utilizator nou: | ||
| - | EXTRA_USERS_PARAMS += "useradd -P parolalastudent student;" | ||
| - | # atenție: trebuie să muncim în plus pentru a-i da drept de sudo utilizatorului, deci recomand root-ul | ||
| - | </code> | ||
| - | |||
| - | Apoi construim imaginea din nou: ''kas build kas.yml''. | ||
| - | Și rulăm:<code> | ||
| - | export LANG=en_US.UTF-8 # dacă runqemu se plânge că nu-l avem setat | ||
| - | # nu uitați să faceți source la oe-init-build-env dacă nu aveți utiltarele în PATH | ||
| - | runqemu qemuarm nographic | ||
| - | # pentru a ieși, trebuie să apăsăm combinația Ctrl+A, c | ||
| - | # va apărea un terminal qemu unde puteți scrie "quit" | ||
| - | </code> | ||
| - | |||
| - | <note warning> | ||
| - | Dacă doriți să folosiți scriptul ''launch.sh'', va trebui mai întâi să rulați ''sudo create-bridge.sh'' din consola VMWare (conexiunea la rețea va pica temporar). Apoi, rulați ''make bin_archive'' pentru a copia ultima imagine în cache-ul de arhivă (pentru distribuirea binarelor), deoarece scriptul folosește ultima imaginea salvată astfel! | ||
| - | </note> | ||
| - | |||
| - | === 2.2. Inspectare rootfs === | ||
| - | |||
| - | Următoarea întrebare care se pune este: cum vedem conținutul unei imagini generate? | ||
| - | Din fericire, suntem pe un sistem Linux, așadar putem folosi mount pentru a monta local partiția ext3/4 generată:<code bash> | ||
| - | student@vm:~/yocto$ sudo mount -o loop build/tmp/deploy/images/qemuarm/core-image-base-qemuarm.ext4 /mnt | ||
| - | student@vm:~/yocto$ ls -l /mnt | ||
| - | student@vm:~/yocto$ cat /etc/passwd | grep student | ||
| - | student:x:1000:1000::/home/student:/bin/sh | ||
| - | # YEAHHH! | ||
| - | # NU UITAȚI: să de-montați partiția la final!!! | ||
| - | # (altfel s-ar putea să se corupă imaginea de la dublă utilizare) | ||
| - | student@vm:~/yocto$ sudo umount /mnt | ||
| - | </code> | ||
| - | |||
| - | === 2.3. Adăugare resurse (fișiere, servicii) în imagine === | ||
| - | |||
| - | TODO | ||
