Se pare că avem câțiva români care au pus mâna pe treabă și lucrează la propriile distribuții Linux, ceea ce este un lucru cu adevărat îmbucurător. Nu este ușor să construiești o distribuție de la zero sau chiar pornind de la una deja existentă, pentru că implică timp, răbdare și destul de multă muncă în spate pe care utilizatorul obișnuit nu o vede. Două dintre aceste proiecte aflate în dezvoltare se numesc Danubix (din păcate nu există niciun depozit online) și RetroLinux, și îi felicit pe dezvoltatori pentru curajul de a se apuca de un astfel de proiect.

Acum, că am spus asta, am și ceva de criticat - nu în mod răutăcios, ci constructiv, pentru că mi se pare important să fie spus.

Problema pe care o am cu ambele distribuții este tema vizuală aleasă de dezvoltatori. Danubix folosește un verde aprins pe fond aproape negru, totul plecând de la ecranul de autentificare și continuând în terminal și în mediul desktop. RetroLinux merge pe un roz-violet, cu un aspect retro-nostalgic specific anilor '80. Nu spun că aceste culori sunt urâte în sine, dar când o singură culoare domină absolut tot ce vezi pe ecran, devine obositor după o vreme.

O temă bună nu înseamnă să alegi o culoare care îți place și să o aplici peste tot. Înseamnă să combini mai multe culori, să ai tonuri calde și neutre care să nu forțeze ochiul, care să lase conținutul să respire. Când stai ore întregi în fața ecranului - fie că scrii cod, citești documentație sau administrezi un server - ultimul lucru de care ai nevoie este o paletă de culori agresivă care să îți obosească vederea.

Și nu este o problemă exclusivă a distribuțiilor românești. Dacă mă gândesc la distribuțiile Linux în general, niciuna nu vine din cutie cu o temă cu adevărat plăcută ochiului. Fie că sunt prea albe, fie că prea cenușii, fie că sunt prea negre, fie că au culori stridente ca să pară „moderne„ sau „distincte". Nu înțeleg de unde vine această modă și de ce nimeni nu încearcă să aducă ceva mai echilibrat. Nici în comunitatea de teme pentru Linux lucrurile nu stau mult mai bine - temele plăcute, cu o paletă de culori caldă și neutră, sunt rare și greu de găsit.

Poate că tocmai de aceea cei de la Danubix și RetroLinux au ales să meargă pe un accent cromatic puternic - ca să iasă în evidență, să aibă o identitate vizuală clară. Îi înțeleg, dar tot cred că există o cale de mijloc între „gri și plictisitor„ și „o singură culoare care țipă pe tot ecranul".

Sper ca, pe măsură ce aceste distribuții evoluează, să vedem și o maturizare a laturii vizuale. Fondul tehnic există și se vede că există implicare - Danubix vine deja cu un toolkit de securitate integrat, iar RetroLinux pare să aibă un sistem propriu de gestionare a configurațiilor. Acum ar fi momentul potrivit să se lucreze și la o temă mai prietenoasă cu ochii utilizatorului care o va folosi zilnic.

Acum câteva zile scriam despre cum HDD-ul extern atașat la Intel NUC se demonta noaptea din cauza USB autosuspend - nucleul punea adaptorul JMicron JMS578 în sleep după câteva secunde de inactivitate, iar când încerca să scrie pe el, primea device offline error și demonta partiția de urgență. Am dezactivat autosuspend-ul printr-o regulă udev, am adăugat nofail în fstab și am crezut că am închis subiectul.

Azi dimineață, la 6:46, același scenariu. A treia oară în trei săptămâni.

Ce spuneau jurnalele de data aceasta

Primul lucru pe care l-am verificat a fost dacă regula udev era activă și dacă JMicron-ul avea power/control setat la on. Discul apărea în lsblk ca sdd, ceea ce confirma că se reconectase singur după demontat, iar fstab folosea UUID, nu device name - deci nu era nici problema cu schimbarea numelui. Pur și simplu nu era montat.

Am rulat sudo journalctl -b | grep -E "mnt-data|sdd|mount" și am găsit ceva ce nu observasem înainte. La momentul exact al demontării, în jurnal apăreau mesaje de genul acesta:

sdd: Failed to create/update device symlink ... ignoring: Inappropriate ioctl for device

Discul se deconecta și reconecta instantaneu - un reset cycle complet al adaptorului - iar udev nu reușea să creeze symlink-urile din /dev/disk/by-id/ pentru că adaptorul nu răspundea corect la anumite comenzi SCSI. Asta era un semnal clar că problema nu era la nivelul power management-ului, ci la nivelul driverului cu care nucleul comunica cu adaptorul.

UAS - driverul care creează probleme pe adaptoare ieftine

Kernelul Linux suportă două moduri de comunicare cu dispozitivele de stocare USB: BOT (Bulk-Only Transport), care e protocolul clasic și simplu, și UAS (USB Attached SCSI), introdus pentru performanță mai bună prin paralelizarea comenzilor SCSI și reducerea latency-ului. Pe hârtie, UAS e superior. În practică, multe adaptoare USB-SATA ieftine - inclusiv cele cu chipset JMicron JMS578 - au implementări firmware defectuoase ale UAS care duc la comportamente imprevizibile: reset cycles, erori de I/O sau, cum era cazul meu, demontări bruște.

Am verificat cu sudo dmesg | grep -i uas și răspunsul a fost imediat:

scsi host3: uas
scsi host2: uas
scsi host4: uas

Trei instanțe, câte una pentru fiecare reconectare a adaptorului din ultimele săptămâni. Nucleul detecta JMicron-ul, alegea UAS ca driver, pentru că adaptorul declara suport pentru el, și la un moment dat, în mod regulat, driverul intra în conflict cu firmware-ul adaptorului și provoca un reset.

Soluția: forțarea fallback-ului pe usb-storage

Linux are un mecanism de quirks prin care poți instrui kernelul să trateze anumite dispozitive diferit față de cum le-ar trata în mod normal, identificate prin idVendor și idProduct. Pentru a dezactiva UAS pe JMicron JMS578 și a forța folosirea driverului usb-storage (BOT), am creat un fișier de configurare:

sudo nano /etc/modprobe.d/usb-storage-quirks.conf

Cu conținutul:

options usb-storage quirks=152d:0578:u

Flag-ul u din lista de quirks înseamnă exact NO_UAS - nucleul va ignora faptul că adaptorul declară suport pentru UAS și va folosi în schimb usb-storage. Valorile 152d:0578 sunt idVendor:idProduct ale adaptorului, obținute cu lsusb.

Pentru ca modificarea să fie inclusă în initramfs și să se aplice la boot, înainte ca kernelul să încarce driverele USB, am rulat:

sudo update-initramfs -u
sudo reboot

După repornire, sudo dmesg | grep -E "uas|usb-storage|152d" a confirmat că totul funcționează corect:

usb 2-4: UAS is ignored for this device, using usb-storage instead
usb-storage 2-4:1.0: Quirks match for vid 152d pid 0578: 1800000

Ce am înțeles greșit în primul rând

Articolul anterior nu era complet greșit - USB autosuspend poate provoca exact aceleași simptome pe același tip de adaptor și rămâne o problemă reală pe sisteme unde discul stă inactiv ore întregi. Regula udev pentru power/control=on e în continuare validă ca măsură de precauție.

Dar cauza principală a reseturilor era UAS, nu autosuspend-ul. Cele două probleme pot coexista și se pot masca reciproc, mai ales că simptomele sunt aproape identice: device offline error, demontat brusc, reconectare imediată cu alt device name. Diferența e că autosuspend intra în acțiune după perioade lungi de inactivitate, în timp ce UAS putea provoca reset-ul și în mijlocul unei operații de scriere, ceea ce explica de ce problema persista chiar și după ce dezactivasem autosuspend-ul.

Dacă folosești un adaptor USB-SATA bazat pe JMicron JMS578 sau orice alt adaptor ieftin și ai probleme similare de stabilitate, primul lucru pe care ar trebui să-l verifici este dacă nucleul folosește UAS. Dacă da, dezactivarea lui prin quirks e simplă și din experiența mea rezolvă problema definitiv.

Dacă mă urmărești de ceva vreme pe jurnal, știi deja că am tot redus lista de servicii și platforme pe care le folosesc, mai ales pe cele ale companiilor mari care tratează utilizatorul ca pe un produs. Am scris deja cum am început să renunț și apoi cum am renunțat la Google, iar acum a venit rândul altor trei platforme cu care aveam o relație destul de veche: X (fostul Twitter), Reddit și Instagram.

Nu a fost o decizie luată dintr-odată, ci mai degrabă ceva ce s-a tot copt în timp, pe măsură ce observam că timpul petrecut pe aceste platforme nu îmi aducea mare lucru - poate câteva informații interesante din când în când, dar și multă agitație, conținut irelevant și senzația că derulezi la nesfârșit fără un scop anume.

X (fostul Twitter)

La fel ca orice rețea socială mare, X colectează o cantitate impresionantă de date despre tine - ce citești, cât timp petreci pe fiecare postare, ce legături accesezi, ce dispozitiv folosești, de unde te conectezi - și toate acestea sunt folosite pentru a construi un profil cât mai detaliat care să fie valorificat prin publicitate. Nu este nimic surprinzător în asta, este modelul de business al întregului ecosistem al rețelelor sociale, dar cu cât mă gândeam mai mult la asta, cu atât mi se părea mai greu de justificat că ofer toate aceste informații în schimbul unor postări pe care le uitam în câteva minute.

La un moment dat mi-am dat seama că deschideam aplicația mai mult din obișnuință decât din interes real, ceea ce este un semn destul de clar că era timpul să renunț și am șters contul.

Reddit

Reddit are o mulțime de articole și discuții interesante și recunosc că am găsit acolo conținut util de-a lungul timpului - probleme tehnice, discuții despre homelab, sfaturi despre hardware, comunități de nișă unde găseai oameni care știau exact despre ce vorbesc. Dar interesul față de conținut nu înseamnă că trebuie să ignori ce se întâmplă cu datele tale, iar Reddit colectează destul de agresiv - istoricul de navigare, postările pe care le citești chiar dacă nu interacționezi cu ele, adresa IP, dispozitivul, și tot ce se poate deduce din comportamentul tău pe platformă. Mai mult decât atât, Reddit a vândut accesul la toate datele generate de utilizatori unor companii terțe pentru antrenarea modelelor de inteligență artificială, fără să-i întrebe nimeni pe cei care au generat acel conținut. Asta mi s-a părut o limită destul de clară și, sincer, renunțarea la cont nu a fost deloc grea.

Instagram

Instagram era platforma pe care o deschideam destul de des, probabil din obișnuință mai mult decât din interes real. Meta este probabil cea mai agresivă companie în ceea ce privește colectarea datelor - Instagram urmărește tot ce faci în aplicație, dar și în afara ei prin pixeli de urmărire și integrări cu alte situri, combină datele cu tot ce știe Facebook despre tine și construiește un profil extrem de detaliat care merge mult dincolo de ce ai distribuit tu vreodată în mod voit. Tocmai pentru că o deschideam atât de des, mi-am dat seama că ofeream foarte multe date în schimbul unui beneficiu real destul de mic, și acesta a fost motivul principal pentru care am decis să renunț.

Cu ce am rămas

Acum că am renunțat și la cele trei, tabloul arată cam așa, și nu o să mint că este unul perfect din punct de vedere al confidențialității.

Facebook îl mai folosesc în principal pentru câteva grupuri interesante unde se mai întâmplă discuții care merită urmărite - altfel probabil că și acesta ar fi plecat de mult. WhatsApp este mai greu de ocolit câtă vreme toată România este acolo, și nu poți renunța la un canal de comunicare fără să pierzi legătura cu oameni reali din viața ta. Netflix îl mai țin pentru că soția îl folosește, deși în casă există și Stremio ca alternativă. YouTube rămâne pentru că am YouTube Family și pentru că nu există cu adevărat o alternativă viabilă.

Cât despre Claude AI, îl folosesc pentru că nu știu altceva mai bun în momentul de față pentru ce am eu nevoie, dar mă joc și cu alte opțiuni - Lumo AI, Mistral AI și Venice AI - ca să văd ce oferă fiecare și cum evoluează lucrurile.

La telefoane, situația este similară - Android și iOS sunt departe de ideal, iar ce mă atrage cu adevărat ar fi un Fairphone cu /e/OS, care combină un hardware reparat ușor cu un sistem de operare degooglet, sau pe viitor un Motorola cu GrapheneOS. Deocamdată nu am făcut pasul, dar ideea este acolo.

Sunt conștient că lista de mai sus nu este tocmai curată, dar renunțarea la servicii nu înseamnă că trebuie să fii perfect dintr-odată, ci că mergi pas cu pas în direcția în care crezi că e bine să mergi. Și față de acum câțiva ani, diferența este deja uriașă.

Acum câteva zile am primit un mail de la un urmăritor al canalului meu de PeerTube și al jurnalului. Mi-a scris că îi plac articolele și că urmărește canalul cu interes, ceea ce m-a bucurat sincer, pentru că nu este ceva obișnuit să primești un mesaj de genul acesta.

Însă mailul nu s-a oprit acolo. Urmăritorul respectiv era curios - și totodată sceptic - dacă folosesc sau nu inteligența artificială pentru a scrie articolele. A menționat despre etichetele AI Usage și Note by AI, lucruri despre care am auzit, dar cărora nu le-am acordat prea multă atenție.

I-am răspuns la mail, dar nu i-am spus direct dacă folosesc sau nu AI-ul la articole, și am făcut asta dintr-un motiv simplu: din felul în care a scris, mi-am dat seama că este unul dintre acei oameni care pune etichete, fie pe oameni, fie pe lucruri, fără prea multă nuanță. Nu am nicio problemă să fiu transparent, dar nu simt nevoia să mă justific în fața cuiva care a venit deja cu o concluzie formată.

Eu nu sunt genul de om care să pună etichete, nici oamenilor și nici lucrurilor, și tocmai de aceea nu îmi plac oamenii care fac asta. Prefer să judec lucrurile după ce le înțeleg, nu după ce aud despre ele.

Acum, ca să fiu clar cu toată lumea care citește jurnalul: eu sunt o persoană simplă, îmi place comoditatea și prețuiesc orice unealtă sau lucru care îmi face viața mai ușoară. Exact din același motiv am renunțat la Arch și Fedora și am trecut la Linux Mint - nu pentru că celelalte distribuții sunt rele, ci pentru că Linux Mint îmi face viața mai simplă și mai liniștită. Același principiu îl aplic și la orice altceva, inclusiv la inteligența artificială.

Dacă folosesc AI la articole sau nu este, în primul rând, problema mea. Nu am nicio obligație față de nimeni să explic cum scriu, cu ce instrumente lucrez sau cât timp petrec în fața tastaturii. Ceea ce contează este că ceea ce ajunge publicat pe acest jurnal reflectă gândurile și experiențele mele reale, nu ale unui algoritm.

Dacă totuși cineva nu este de acord cu modul în care aleg să lucrez, îl invit respectuos să nu mai urmărească jurnalul, canalele de YouTube și PeerTube, și nici conturile de socializare. Nu îmi doresc să pierd cititori sau urmăritori, dar nici nu am de gând să îmi schimb felul de a fi sau de a lucra pentru a satisface așteptările altcuiva.

Există proiecte open-source care apar, bifează câteva stele pe GitHub și dispar la fel de discret cum au venit. TuxPulse nu este unul dintre ele. De-a lungul a șase versiuni majore, proiectul a trecut printr-o transformare pe care puțini ar fi anticipat-o la început - de la un experiment în Python la o rescriere completă în Rust, după un audit de securitate care a pus totul sub semnul întrebării.

Un proiect construit în public, cu tot ce implică asta

TuxPulse a pornit modest, ca un exercițiu personal al dezvoltatorului. Prima versiune nu impresiona prin complexitate, dar stabilea un punct de plecare. Ceea ce a urmat a fost un proces vizibil pentru oricine urmărea repository-ul: versiunile s-au succedat rapid, fiecare aducând câte ceva în plus față de precedenta.

Momentul care a dat cu adevărat sens proiectului a fost v3.0, când a apărut un catalog de aplicații cu posibilitatea de instalare cu un singur clic - sau în lot, dacă voiai mai multe deodată. Nu mai era un script de sistem oarecare, ci un tool cu o utilitate concretă. Versiunea 4.0 a adus un redesign al interfeței și o restructurare a logicii interne. Versiunile 5.x și-au propus extinderea compatibilității spre Fedora și Arch Linux.

Pe hârtie, traiectoria părea liniară și promițătoare.

Când un audit îți arată ce nu voiai să știi

La un moment dat, cineva din comunitate a propus un audit de securitate al aplicației. Dezvoltatorul a acceptat. Concluzia a fost dureroasă: structura internă a codului introducea vulnerabilități serioase, iar lista problemelor identificate nu era scurtă.

Reacția inițială a fost să abandoneze proiectul. Este greu să construiești ceva versiune după versiune și apoi să afli că fundația are fisuri. Dar după o scurtă perioadă de reflecție, decizia a fost să repare, nu să renunțe. Versiunea v5.2 a rezolvat problemele cele mai critice și a stabilizat temporar situația.

Temporar - pentru că soluțiile aplicate tratau simptomele, nu cauza.

De ce Rust

Python a fost alegerea naturală la început: accesibil, rapid de scris, suficient pentru un proiect experimental. Dar un tool de sistem care rulează cu privilegii ridicate are cerințe diferite față de un script obișnuit. Siguranța la nivel de memorie, performanța și controlul fin asupra resurselor sunt lucruri pe care Python nu le poate garanta în același mod.

Dezvoltatorul mai scrisese în Rust - o aplicație de întreținere pentru sisteme Windows. Comparând cele două experiențe, concluzia a fost clară: pentru ceea ce urma să devină TuxPulse, Rust era singura alegere care avea sens pe termen lung.

Așa că totul a luat-o de la capăt.

Versiunile 6.0.0 și 6.0.1

v6.0.0 este primul pre-release al noii generații - o aplicație rescrisă integral, cu o interfață regândită și cu securitatea tratată ca prioritate de la primul rând de cod, nu ca un strat adăugat ulterior. v6.0.1 continuă în aceeași direcție, adăugând detalii treptat.

TuxPulse nu face telemetrie, nu colectează niciun fel de date și rămâne complet gratuit și open-source. Este un proiect construit din curiozitate și menținut din principiu - exact tipul de software pe care comunitatea Linux îl merită mai des.

Dacă vreți să îl testați sau să contribuiți, codul se găsește în întregime pe GitHub.

Pe 9 aprilie 2026, ultimul angajat plătit al Session Technology Foundation (STF) și-a încheiat ultima zi de muncă. De atunci, una dintre cele mai serioase alternative private la WhatsApp și Signal este dezvoltat exclusiv de voluntari, cu infrastructura finanțată doar până pe 8 iulie 2026. Dacă până atunci nu sunt strânși 1 milion de dolari, proiectul se închide.

Ce este Session

Session este un messenger open source, criptat end-to-end, care nu îți cere nici număr de telefon, nici adresă de email pentru a-l folosi. La înregistrare primești pur și simplu un ID generat aleatoriu. Mesajele nu trec printr-un server central, ci printr-o rețea de tip onion routing - similar cu Tor - ceea ce face ca metadatele să nu fie colectate deloc. Cine vorbești, când, cu cine - nimic din toate astea nu ajunge nicăieri.

Peste 1,5 milioane de oameni îl folosesc lunar. A fost descărcat de peste 13 milioane de ori. A ajuns un instrument important pentru jurnaliști, activiști și cetățeni din țări unde guvernele blochează sau monitorizează comunicațiile. În perioada conflictului din Iran, echipa Session a înregistrat în jur de 50.000 de conturi noi pe zi, doar din acea regiune.

Cum s-a ajuns aici

Chris McCabe, co-fondatorul Session, a publicat în martie 2026 un apel personal în care explica situația fără menajamente: organizațiile care stau în spatele proiectului au trecut prin ani dificili, iar supraviețuirea lui nu mai este garantată. El cerea ca fiecare utilizator să contribuie cu cel puțin un dolar - dacă toți cei care folosesc aplicația ar fi făcut asta, problema ar fi fost rezolvată pe loc.

Nu s-a întâmplat. Comunitatea a donat, dar insuficient. Până la data de față, STF a primit aproximativ 65.000 de dolari - bani care ajung să țină infrastructura de bază în viață până pe 8 iulie, dar nu și să plătească programatori.

Rezultatul este că dezvoltarea este oprită. Nu vor fi lansate versiuni noi în această perioadă. Defectele existente vor rămâne cel mai probabil nerezolvate. Funcționalitățile în lucru - Protocol v2, care aduce forward secrecy, criptografie post-quantum și gestionare îmbunătățită a dispozitivelor, și Session Pro, un abonament premium menit să asigure sustenabilitate financiară pe termen lung - au fost înghețate.

De ce contează

Trăim într-un moment în care supravegherea digitală devine tot mai normalizată. Platforma pe care o folosești pentru a comunica cu familia, cu colegii, cu prietenii nu e neutră - fiecare mesaj trimis printr-un serviciu centralizat poate fi, la un moment dat, accesat, interceptat sau folosit împotriva ta.

Session nu e perfect. Are probleme de adopție, interfața nu e la fel de șlefuită ca Signal, și modelul de finanțare s-a dovedit fragil. Dar ideea din spatele lui - un messenger care nu știe cine ești și nu poate ști cu cine vorbești - rămâne valoroasă. Și e greu de înlocuit.

Dacă proiectul dispare, codul rămâne pe GitHub. Poate că cineva va continua. Poate că nu. Dar o comunitate de 1,5 milioane de utilizatori activi care nu reușește să strângă 1 milion de dolari pentru a salva un instrument care îi protejează spune ceva despre cât de mult prețuim cu adevărat confidențialitatea - nu în vorbe, ci în fapte.

Dacă proiectul îți pare valoros, STF acceptă donații la getsession.org/donate. Termenul limită e 8 iulie 2026.

Am mai citit câteva știri despre războiul din Iran. De această dată SUA a arătat cât de slabă este. Și pierde un război important și acest lucru îl vede China și Rusia, dar și Europa.

Europa sper să învețe ceva din acest lucru și din toate experiențele cu SUA de când Trump este Președinte.

Pe 8 aprilie 2026, guvernul francez a făcut un anunț pe care mulți dintre noi îl așteptau de mult timp: DINUM, direcția interministerială pentru digitalizare a Franței, a anunțat oficial că statul va abandona Windows-ul în favoarea Linux pe stațiile de lucru guvernamentale. Nu e un zvon, nu e un pilot izolat undeva într-un colț de minister - e o declarație formală, publicată pe situl oficial al guvernului, cu ministri care semnează și cu termene concrete.

Contextul mai larg este că Franța vrea să-și reducă dependența față de tehnologiile digitale din afara Europei, iar această mișcare face parte dintr-o strategie mai amplă de suveranitate digitală. Ministrul David Amiel a spus-o destul de direct: statul nu mai poate accepta să depindă de soluții ale căror reguli, tarife și evoluții nu le controlează nimeni din Europa. Suveranitatea digitală nu mai e o opțiune, e o necesitate - cam ăsta e mesajul.

Concret, DINUM va coordona un plan interministerial, iar fiecare minister (inclusiv operatorii publici) trebuie să-și formalizeze propriul plan până în toamnă, acoperind mai multe domenii: stațiile de lucru, uneltele de colaborare, antivirusul, inteligența artificială, bazele de date, virtualizarea și echipamentele de rețea. Practic, un audit complet al dependențelor tehnologice, cu un calendar clar pentru reducerea lor.

Nu e vorba doar de desktop-uri, cum explică și cei de la Linuxiac. Franța poziționează adoptarea Linux-ului ca parte dintr-o politică mai largă axată pe suveranitate și interoperabilitate. Paralel cu asta, Casa Națională de Asigurări de Sănătate migrează cei 80.000 de angajați ai săi către unelte din suita interministerială suverană - Tchap, Visio și FranceTransfert - iar platforma de date de sănătate urmează să fie mutată pe o soluție de încredere până la finalul lui 2026.

Ce distribuție Linux vor folosi? Deocamdată nu se știe, decizia urmând să vină ceva mai târziu, pe măsură ce fiecare minister își conturează planul propriu. Primele „întâlniri industriale ale digitalului" sunt programate pentru iunie 2026, unde se vor formaliza coalițiile public-privat pentru suveranitate europeană.

Ce mi se pare important de subliniat e că nu vorbim despre o aventură idealistă a unor entuziaști Linux dintr-un birou oarecare, ci despre o decizie politică la cel mai înalt nivel, cu responsabilități clare și termene asumate public. E genul de mișcare pe care, dacă o face o țară de talia Franței, devine greu de ignorat și pentru celelalte guverne europene.

Și inevitabil mă gândesc la România, care plătește în continuare licențe Microsoft din bani publici, fără ca subiectul să ajungă vreodată cu adevărat pe agenda nimănui. Nu cer miracole, dar măcar o discuție serioasă la nivel guvernamental despre suveranitate digitală și soluții open source ar fi un început. Franța a demonstrat că se poate, că există voință politică și că nu e nevoie să aștepți ca Microsoft să-ți spună când și cum îți upgradezi infrastructura. Rămâne de văzut dacă și la noi se trezește cineva la un moment dat.

De două ori în același număr de săptămâni, m-am trezit cu Nextcloud inaccesibil și cu un mesaj de eroare despre directorul de date invalid. De fiecare dată, cauza era aceeași: HDD-ul extern pe care îl folosesc ca stocare principală pe thinkserver nu mai era montat.

Prima dată am crezut că am uitat să-l adaug în /etc/fstab. L-am montat manual, am adăugat intrarea corectă cu opțiunile defaults,nofail și am crezut că am rezolvat problema. La câteva zile distanță, același scenariu. De data aceasta era clar că ceva mai adânc nu funcționează cum trebuie.

Ce spuneau jurnalele

Am rulat sudo journalctl -b | grep -i "mnt|sd|fstab|mount" și răspunsul a fost imediat. La ora 6:36 dimineața pe 4 aprilie, și din nou la 6:20 pe 9 aprilie, apăreau aceste mesaje în jurnal:

device offline error, dev sdb, sector 0 op 0x1:(WRITE)
EXT4-fs (sdb1): shut down requested (2)
Aborting journal on device sdb1-8.
systemd: Unmounting mnt-data.mount - /mnt/data...
systemd: mnt-data.mount: Deactivated successfully.

Kernelul detecta că device-ul a dispărut brusc în timp ce scria pe el, oprea jurnalul EXT4 ca să nu corupă datele, și demonta partiția în mod de urgență. HDD-ul se reconecta imediat după, dar cu un alt device name - sdb devenea sdc și invers - iar systemd nu îl remonta automat.

Problema nu era în fstab. Problema era că HDD-ul se deconecta fizic.

Cauza: USB autosuspend

HDD-ul este conectat printr-un adaptor USB-SATA cu chipset JMicron JMS578. Linux are o funcție numită USB autosuspend care pune device-urile USB în sleep după o perioadă de inactivitate pentru a economisi energie. Valoarea implicită pe acest sistem era de 2000 de milisecunde - adică 2 secunde de inactivitate erau suficiente pentru a suspenda adaptorul.

În timpul zilei, cu containere Docker care accesează constant datele de pe HDD, autosuspend-ul nu apuca să intre în acțiune. Dar noaptea, după ore de inactivitate, adaptorul intra în sleep și nu se trezea corect atunci când kernelul încerca să scrie pe el. Rezultatul era device offline error și demontarea de urgență.

Am confirmat că autosuspend-ul era activ cu:

for d in /sys/bus/usb/devices/*/idVendor; do
  vendor=$(cat $d)
  if [ "$vendor" = "152d" ]; then
    dir=$(dirname $d)
    echo "autosuspend_delay_ms: $(cat $dir/power/autosuspend_delay_ms)"
  fi
done

Rezultatul: autosuspend_delay_ms: 2000.

Rezolvarea

Soluția este să forțezi device-ul USB să rămână activ permanent prin setarea power/control la valoarea on:

for d in /sys/bus/usb/devices/*/idVendor; do
  vendor=$(cat $d)
  if [ "$vendor" = "152d" ]; then
    dir=$(dirname $d)
    echo on | sudo tee $dir/power/control
  fi
done

Cu control: on, valoarea autosuspend_delay_ms este ignorată complet, indiferent ce valoare are.

Pentru ca setarea să persiste după reboot, am creat o regulă udev:

sudo nano /etc/udev/rules.d/99-usb-hdd-nosuspend.rules

Cu conținutul:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152d", ATTR{idProduct}=="0578", ATTR{power/autosuspend_delay_ms}="-1", ATTR{power/control}="on"

Valorile idVendor și idProduct le-am obținut din lsusb. Regula se aplică de fiecare dată când adaptorul este detectat de sistem, fie la boot, fie după o reconectare fizică.

Am reîncărcat regulile udev și am remontat HDD-ul:

sudo udevadm control --reload-rules
sudo mount -a

Ce am învățat

Un HDD extern conectat prin USB nu se comportă la fel ca unul intern conectat SATA. Kernelul îl tratează ca pe orice alt device USB și îi aplică politicile de economisire a energiei, indiferent că pe el rulează date critice pentru servicii. Opțiunea nofail din fstab este utilă - împiedică sistemul să se blocheze la boot dacă HDD-ul nu e disponibil - dar nu face nimic pentru a preveni demontarea în timpul funcționării.

Dacă folosești un HDD extern ca stocare pentru servicii self-hosted, autosuspend-ul USB este primul lucru pe care trebuie să-l dezactivezi.