Buildroot to doskonałe narzędzie do budowania dedykowanego Linuxa na platformy wbudowane. Bardzo długo nie wiedziałem, dlaczego czasem trzeba budować projekt od zera, a czasem wystarczy zbudowanie tylko nowo dodanych elementów.
Okazuje się, że wykrywanie co ma zostać przebudowane w niezawodny sposób jest bardzo trudne. Buildroot zastosował innowacyjny algorytm i… po prostu tego nie robi. To użytkownik ma wiedzieć kiedy pełny ‘rebuild’ jest potrzebny (to wręcz cytat z oficjalnej dokumentacji). Przenoszenie odpowiedzialności na użytkownika nie jest niczym złym, ale warto zdawać sobie z tego sprawę.
Jest kilka sytuacji, w których pełny rebuild będzie na 100% konieczny:
✅ Gdy zmieniamy konfigurację toolchaina
✅ Po dodaniu biblioteki, która opcjonalnie może być użyta przez inne programy,
✅ Gdy paczka zostaje usunięta (bo bez pełnej przebudowany zostanie w sysroocie)
✅ Gdy zmieniamy coś w szkielecie rootfs’a (tutaj sprawę ułatwia używanie overlayów)
Jeśli chcesz dowiedzieć się jak używać overlayów w Buildroocie – korzystam z nich w artykule wprowadzającym do tego narzędzia: https://linuxdev.pl/buildroot-dla-raspberry-pi-krok-po-kroku/
Również w podlinkowanym artykule natknąłem się właśnie na problem z nagle psującym się systemem. Obraz budował się w porządku, ale po wgraniu na kartę pamięci i wrzuceniu do Raspberry Pi, zacząłem widzieć bardzo dziwne, niespodziewane błędy. Przykład:
[ 0.000000] Booting Linux on physical CPU 0x0
...
[ 1.234567] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.234567] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---Żadna z wprowadzonym zmian nie powinna spowodować aż tak drastycznego buntu. Nie ma nawet szansy na uzyskanie konsoli, bo kernel strajkuje. Kortyzol lekko podskoczył, bo „przecież powinno działać” i widząc poziom niespójności błędu potencjalnie czekała mnie dłuuga sesja debugowania. Na szczęście przypomniało mi się, że kilka lat temu mierzyłem się z podobnym problemem.
Zostało to nawet udokumentowane! Byłem tak zdesperowany, że założyłem pytanie na stacku, mojej ostatniej desce ratunku: https://raspberrypi.stackexchange.com/questions/111507/buildroot-udev-disables-serial-console
Pytanie nie doczekało się odpowiedzi… Na szczęście odpowiedziałem sobie sam. Po bardzo długim główkowaniu, szukaniu i walczeniu z technologią okazało się, że właśnie ponowne przebudowanie projektu od zera rozwiązałoby problem dużo szybciej! Teraz mając więcej doświadczenia doszedłem do tego w znacznie krótszym czasie. A jeszcze lepiej byłoby zrobić coś zupełnie innego, czyli…
zajrzeć do oficjalnej dokumentacji.
Tak, to właśnie w oficjalnej dokumentacji znajdują się wyszczególnione sytuacje kiedy MUSIMY przebudować nasz projekt. Nauczka na przyszłość – lepiej uczyć się na cudzych doświadczeniach, niż na własnych. Chociaż wtedy na dłużej zapamiętamy…
Poniżej znajdziesz link do oficjalnej dokumentacji Buildroota. Trzeba przyznać, że jak na tak techniczny dokument czyta się ją całkiem nieźle.
Dodaj komentarz