În urmă cu două săptămâni am scris că mi s-a stricat caseta de direcție și că cea comandată a dispărut. Astăzi am fost după mașină și mă bucur tare mult că am mașină din nou 🙂

Povestea este un pic cam lungă, dar o scurtez eu cum știu 🙂

În data de 22 iulie 2026 mi s-a stricat caseta de direcție în timp ce eram pe autostradă și veneam acasă de la serviciu. Am auzit ceva, dar nu am fost sigur, pentru că mergea muzica, și nici la volan nu am simțit prea tare, pentru că nu tot timpul mergea greu - uleiul nu se scursese de tot.

În după-amiaza zilei de 22 iulie am început să simt cum trebuie că volanul și direcția merg greu - uleiul se scursese cu totul. Bănuiala mea a fost că s-a stricat caseta de direcție, mai ales că știam că este una SH și nu una nouă. În urmă cu 4 ani, când am cumpărat mașina, am schimbat caseta de direcție și, din păcate, service-ul auto la care a fost mașina nu a găsit una nouă în acea vreme.

A doua zi, 23 iulie 2026, am fost la un service pe care nu îl recomand și mă bucur tare mult că nu era nimeni la recepție - după câteva minute de așteptare am plecat de acolo și m-am oprit pe strada mea, la un service mic, într-un garaj.

După-amiază, tot în data de 23, am fost la constatare și mi-au spus exact ce bănuiam eu. Caseta de direcție s-a dus cu totul, au căutat o casetă și au comandat-o, iar programarea pentru schimbare s-a făcut pe data de 28 iulie 2026.

Între timp, caseta comandată a dispărut - nu mai apărea în calculator - iar comanda s-a amânat, deci s-a amânat și reparația. Altă casetă nu s-a mai comandat, pentru că mecanicul a spus că ce se găsea în acel moment nu era bun, deși era mai scump.

Să vă spun prețurile așa, în mare, că nici eu nu le mai știu exact, înainte să trec mai departe cu povestea 🙂

• prima casetă a fost 2200 sau 2400 de lei, recondiționată
• cele pe care nu le-a comandat, pentru că erau proaste, costau: 3400-3600 de lei, respectiv 5000 de lei

Am rămas înțeles cu mecanicul că se mai uită el, mai trec eu pe acolo sau dau un telefon. Pe data de 3 august am fost la service, iar mecanicul a găsit caseta de care aveam nevoie și a comandat-o - de data asta a și venit.

Vineri, 7 august, la ora 09:00, am avut programarea, dar eu am lăsat mașina la ora 08:55 și speram ca până la ora închiderii mașina să fie gata. Din păcate, nu a fost așa. Pe la amiază m-a sunat și mi-a spus că caseta de direcție e bună, dar nu se potrivește - venea cu ceva ce eu nu am la mașină. A căutat altă casetă recondiționată, la 1700-1800 de lei, destul de bună, dar din păcate a fost la fel ca prima. Până la urmă a găsit o casetă de direcție SH la 700 de lei, care a fost exact ce aveam nevoie pentru mașină.

Problema nu s-a oprit doar la caseta de direcție. A mai trebuit schimbul de ulei și de filtre, a mai fost o problemă la un senzor de nivel de ulei, s-a schimbat pompa de apă suplimentară, antigelul, uleiul de servodirecție și un șurub de la dublul scut.

Prețul a tot crescut, dar asta nu e o problemă - mă bucur că s-au rezolvat toate problemele apărute.

Știu că vreți să știți cât m-a costat totul 🙂 Suma finală a fost de 4437 de lei. Mai sunt câteva lucruri de făcut, dar nu știu încă exact când 🙂

În urmă cu câteva zile am avut parte de una din acele dimineți în care nimic nu funcționează așa cum ar trebui, deși aparent nu am făcut nimic.

Curentul a picat de două ori într-un interval scurt, la câteva secunde distanță. Un lucru minor pentru majoritatea oamenilor, dar pentru cineva care ține câteva servicii pornite non-stop acasă, două întreruperi consecutive înseamnă întotdeauna un mic haos de reparat după aceea.

Ce s-a întâmplat de fapt

NUC-ul principal s-a repornit singur, așa cum era de așteptat, pentru că are setată în BIOS opțiunea de a porni automat după ce revine alimentarea. Problema a apărut la un disc extern conectat printr-un enclosure USB cu chipset JMicron, cel pe care îl folosesc pentru o parte din date. Acesta nu a mai pornit automat odată cu revenirea curentului. NUC-ul a pornit, sistemul de operare a încărcat, dar discul a rămas oprit, needetectat de nimic în lsblk. A trebuit să merg fizic și să repornesc manual enclosure-ul ca discul să fie recunoscut din nou, lucru confirmat imediat după aceea în dmesg, unde apărea corect ca disc SCSI atașat.

Efectul de domino asupra serviciilor

Odată ce discul a fost din nou disponibil, m-aș fi așteptat ca totul să revină la normal fără alte surprize. Uptime Kuma a început brusc să arate totul ca nefuncțional, deși containerele păreau să ruleze normal. Verificând mai atent, problema nu era la serviciile în sine, ci la rezolvarea numelor de domeniu: orice cerere nslookup sau ping către un nume extern se termina cu SERVFAIL.

Am verificat mai întâi conectivitatea de bază către internet, cu ping direct către o adresă IP, și mergea perfect. Deci nu era o problemă de rețea fizică sau de router, ci ceva strict legat de rezolvarea numelor. Am continuat cu cat /etc/resolv.conf, care arăta clar că rezolvarea era delegată complet către rețeaua privată prin care leg dispozitivele între ele, adică Tailscale, cu adresa lui specială de MagicDNS, 100.100.100.100.

Setarea care lipsea

Verificând jurnalul serviciului cu journalctl -u tailscaled, am găsit exact momentul problemei: la boot, Tailscale a configurat DNS-ul cu o listă goală de resolvere din spate, DefaultResolvers:[], ceea ce înseamnă practic că orice cerere de rezolvare primea automat un refuz, fără nicio explicație vizibilă din exterior. MagicDNS rula, dar nu avea unde să trimită mai departe cererile pentru domenii din afara rețelei private.

Interesant e că, în mod normal, acest lucru nu ar fi trebuit să conteze deloc, pentru că fiecare mașină are propriul sistem local de rezolvare a numelor, configurat separat și folosit implicit. Dar exact în fereastra aceea de repornire, ceva a făcut ca rețeaua privată să preia controlul complet asupra rezolvării, cu accept-dns activat implicit, înlocuind temporar configurația locală funcțională. Asta explică și de ce, până la acest incident, nu întâmpinasem niciodată problema: pur și simplu nu depinsesem practic de acel mecanism până acum.

Soluția a fost să dezactivez temporar acel comportament automat cu tailscale set --accept-dns=false, să confirm că rezolvarea locală funcționează din nou, apoi să-l reactivez explicit cu tailscale set --accept-dns=true. De data asta, la reactivare, Tailscale a apucat să tragă corect lista completă de resolvere de la serverul central, iar rezolvarea a revenit la normal aproape instant.

Discul care nu vrea SMART

Cât timp am tot investigat, am încercat și să verific starea de sănătate a discului extern cu smartctl, ca să mă asigur că nu cumva enclosure-ul refuzase să pornească din cauza unei probleme mai grave la disc. Aici m-am lovit de o limitare separată: chipset-ul JMicron din enclosure nu translatează corect comenzile SAT necesare pentru SMART prin USB, indiferent de varianta încercată, -d sat, -d usbjmicron, -d scsi, cu sau fără -T permissive. E o limitare de firmware cunoscută la acest tip de punte, nu ceva ce se repară din partea sistemului de operare. Discul funcționează normal, dar monitorizarea SMART completă rămâne indisponibilă cât timp stă în acest enclosure.

Ce rămâne de învățat

Cel mai clar semnal din tot acest episod e că infrastructura de acasă are nevoie de un sistem de alimentare neîntreruptibilă, măcar pentru echipamentele critice. E un proiect pe care îl am deja în plan, dar care, ca orice proiect de acest fel, așteaptă momentul potrivit din punct de vedere financiar și de timp.

Până atunci, rămâne lecția practică: o pană de curent nu înseamnă doar oprire și repornire. Poate scoate la iveală dependențe ascunse între sisteme, comportamente care păreau stabile doar pentru că niciodată nu au fost puse cu adevărat la test. Uneori ai nevoie exact de un asemenea incident ca să vezi clar unde sunt punctele slabe ale propriei configurații, chiar dacă prețul plătit e o dimineață pierdută cu depanare în loc de altceva mai plăcut.

#blaugust2026

Luna aceasta particip la Blaugust, un eveniment sau, mai bine zis, o provocare în care în mod normal trebuie să scrii 31 de articole în 31 de zile în luna august. Până acum am reușit să public câte un articol în fiecare zi și nu numai - nu contează doar articolele, se pot publica și imagini, și clipuri video, practic orice - ceea ce eu am făcut doar cu o notă (micropostare).

Recent am aflat de provocarea The 100 Pics și de anul trecut mai știu și de provocarea 100 Days To Offload. Mă gândesc tot mai des ca, după ce se termină Blaugust 2026, să fac și aceste două noi provocări, pentru că sunt interesante.

La provocarea „The 100 Pics” trebuie să postez 100 de imagini într-un an, nu contează dacă sunt imagini/poze noi sau vechi - tot ce contează este să public 100 de imagini într-un an. Regulile sunt foarte simple:

• poate începe în orice zi,
• trebuie folosit #the100pics la postare,
• și trebuie să scriu/vorbesc despre acest lucru.

Provocarea „100 Days To Offload” este foarte asemănătoare cu cea cu imaginile, doar că aici este vorba de articole scrise - tot 100 de articole într-un an de zile. Și aici regulile sunt simple:

• se poate începe în orice zi,
• trebuie folosit #100DaysToOffload la postare,
• trebuie scris/vorbit despre provocare.

Sunt două provocări mult mai ușoare decât Blaugust - provocarea de 31 de articole în 31 de zile nu este obligatorie, se pot scrie și 5 articole în această lună - important este să participi și să scrii pe propriul tău jurnal.

Să revin la cele două provocări. După cum spuneam/scriam, este mult mai ușor de participat la ele. Pentru mine, personal, provocarea cu imaginile/pozele este un pic mai grea, pentru că nu fac multe poze, deși mi-ar plăcea să fac acest lucru mai des, și poate că această provocare mă va face să fac poze mult mai des.

Provocarea cealaltă este mult, dar mult mai ușoară, pentru că deja scriu pe jurnal, dacă vă uitați la Arhivă veți vedea că postez destul de des. Deci nu o să fie o problemă pentru mine această provocare.

Aș vrea să văd și bloggeri români participând la aceste provocări, așa că vă invit să participați și voi dacă vedeți/citiți această postare.

#blaugust2026