Około 2 tygodnie zwlekałem z napisaniem tego wpisu, który jest zarazem ostatnim wpisem w temacie batalii, które prowadziłem z Raspberry Pi i freezami maliny po bliżej nieokreślonym czasie. Opisywałem to we wpisie Service down, service down. Raspberry Pi w sytuacji kryzysowej oraz Gdy malina zalicza glebę, logi prawdę powiedzą. Początkowo plan był taki, by zaktualizować ostatni wpis. Finalnie jednak postanowiłem zakończyć walkę: człowiek kontra maszyna – wpisem o tym.
W trakcie poszukiwań rozwiązania problemu z błędami, które wyrzucała malina w związku z dyskiem NVME, które owocowało następnie zwiechami urządzenia, znalazłem wpisy, które sugerowały winę kabla. Jako rozwiązanie, niektórzy pisali, że wystarczy owinąć kabel folią aluminiową. Z jednej strony argumentacja, że fale WiFi i bluetooth, oddziałują na kabel i połączenie, wydawały mi się logiczne. Z drugiej… irracjonalne. Albo inaczej: nie dawało mi spokoju, jak w domowych warunkach takie coś może mieć miejsce.
Finalnie, ponownie poszedłem za sugestią kkw i… połączyłem malinę przewodem RJ-45 do routera. Nie obyło się początkowo bez problemów z konfiguracją sieci, bo nie miałem skonfigurowanego połączenia kablowego, ostatecznie jednak od prawie1 10 dni RPI5 działa bez przerwy.
A, co ważne/ciekawe. Zmienne w /boot/firmware/config.txt oraz /boot/firmware/cmdline.txt wygląda na to, że nie działają na Ubuntu. Tak, jakby kernel nie brał ich w ogóle pod uwagę. Głupie wyłączenie WiFi, czy bluetooth za pomocą zmiennych w config.txt:
dtoverlay=disable-bt-pi5
dtoverlay=disable-wifi-pi5Po prostu nie robi nic. Sądzę, że zmienne, które wprowadzałem do obsługi NVME – też nie robiły nic, ale nie chcę tego sprawdzać. W myśl zasady jeśli coś działa – nie ruszaj: zostawiam malinkę w takiej a nie innej konfiguracji, działającą bez zarzutu :).
P.S. W pracy kolega ma RPI4 i też coś wspominał, że ma problemy z działaniem na WiFi, więc problem raczej nie jest jednostkowy i jest coś na rzeczy.
- Tydzień temu resetowałem urządzenie po update kernela. [↩]
Dodaj komentarz