Soluții

Diagnosticarea și rezolvarea erorii „Kernel panic – not syncing: Attempted to kill init!”

• Data 03/08/2026
• Autor Mihai Geambasu
• 0
• 39

1. Introducere și definirea erorii

Eroarea Kernel panic - not syncing: Attempted to kill init! reprezintă o stare critică de eroare neremediabilă în sistemele de operare Linux. În această stare, nucleul (kernel-ul) oprește complet executarea oricărei instrucțiuni pentru a preveni coruperea datelor sau deteriorarea fizică a sistemului de fișiere.

Mesajul indică direct faptul că primul proces lansat de kernel la pornirea sistemului (procesul cu PID 1, numit init sau systemd) a fost oprit neașteptat sau a fost terminat forțat (killed). Deoarece procesul init este „părintele” tuturor celorlalte procese din sistem, oprirea lui face imposibilă funcționarea în continuare a sistemului de operare.

2. Cauzele principale ale erorii

Defectarea sau prăbușirea procesului init are loc, în general, în prima fază de boot (încărcare) a sistemului și este cauzată de următoarele categorii de probleme:

A. Coruperea sau lipsa imaginii initramfs / initrd

Imaginea Initial RAM Disk (initramfs) conține driverele și modulele necesare kernelului pentru a putea citi și monta discul principal. Dacă această imagine este coruptă, lipsă sau a fost generată greșit după o actualizare de kernel, sistemul nu poate lansa init.

B. Probleme legate de configurarea Bootloader-ului (GRUB)

• Anumiți parametri de boot din configurarea GRUB trimit kernelul către un disc greșit (ex: o adresă root=UUID=... incorectă).

• Parametrul init= arată către o cale inexistentă (ex: /sbin/init lipsește sau este corupt).

C. Coruperea sistemului de fișiere sau a discului (Filesystem / Hardware)

• Sector defect pe disc (SSD/HDD) în zona unde se află executabilul /sbin/init sau /lib/systemd/systemd.

• Corupere cauzată de o oprire necorespunzătoare a alimentării cu energie electrică.

D. Lipsa spațiului pe disc în timpul actualizărilor (/boot plin)

O cauză extrem de frecventă pe servere și calculatoare de birou este umplerea partiției /boot. Dacă la un update de sistem (apt upgrade / dnf update) discul este $100\%$ plin, noul kernel sau imaginea initramfs se va scrie parțial, rezultând o imagine invalidă la următorul restart.

E. Neconcordanță între arhitectura sistemului și module

Executarea unui kernel pe $64$ de biți cu un proces init compilat pentru o altă arhitectură necompatibilă sau din cauza unor permisiuni de fișiere alterate (/sbin/init și-a pierdut drepturile de execuție chmod +x).

3. Ghid 

Când întâmpinați această eroare, sistemul nu mai poate porni normal. Rezolvarea necesită intervenția prin mediul de recuperare (GRUB sau un Live USB).

Pasul 1: Pornirea dintr-o versiune anterioară de Kernel (Meniul GRUB)

Aceasta este cea mai rapidă metodă de testare și recuperare:

1. Reporniți sistemul și țineți apăsată tasta Shift sau Esc pentru a afișa meniul GRUB.

2. Selectați Advanced options for Ubuntu/Debian/RHEL.

3. Alegeți o versiune anterioară de kernel (de exemplu, o versiune mai veche care nu are eticheta recovery mode).

4. Dacă sistemul pornește cu succes, problema este legată strict de ultimul kernel instalat sau de imaginea sa initramfs.

Pasul 2: Regenerarea imaginii initramfs

Dacă ați reușit să intrați într-un kernel vechi sau folosind un Live USB (prin metoda chroot), regenerați fișierele de boot:

• Pe sisteme bazate pe Debian / Ubuntu:

  Bash

  sudo update-initramfs -u -k all
  sudo update-grub
  

• Pe sisteme bazate pe RHEL / CentOS / Fedora:

  Bash

  sudo dracut --regeneration --force
  sudo grub2-mkconfig -o /boot/grub2/grub.cfg
  

Pasul 3: Repararea sistemului de fișiere (fsck)

Dacă eroarea este provocată de un disc corupt:

1. Porniti dintr-un Live USB/CD de Linux.

2. Deschideți un terminal și identificați partiția de sistem (ex: /dev/sda1 sau /dev/nvme0n1p2) cu comanda lsblk.

3. Rulați verificarea și repararea partiției:

   Bash

   sudo fsck -y /dev/sda1
   

Pasul 4: Curățarea spațiului din partiția /boot

Dacă partiția /boot este plină și a blocat actualizarea:

1. Porniți din Live USB și montati partiția de sistem.

2. Ștergeți kernel-urile vechi nefuncționale sau fișierele temporare nefinalizate din /boot.

3. Rulați comanda de curățare a pachetelor incomplete:

   Bash

   # Dintr-un mediu chroot:
   apt-get clean
   apt-get autoremove
   dpkg --configure -a
   

4. Măsuri de prevenție

• Evitați umplerea partiției /boot: Configurați sistemul să păstreze doar 2-3 imagini de kernel (utilizați opțiuni de curățare automată precum Purgeremovedupes sau installonly_limit în managerul de pachete).

• Nu opriți forțat calculatorul în timpul actualizărilor: Închiderea alimentării în timp ce se execută comenzi de tip update-initramfs sau dracut va deteriora garantat fișierele de boot.

• Folosiți surse de alimentare neîntreruptibile (UPS): Pe servere de producție, întreruperile bruște de curent sunt principala cauză a coruperii procesului init și a sistemului de fișiere.

Diagnosticarea și rezolvarea erorii „Bus error (core dumped)” în Linux

• Data 03/08/2026
• Autor Mihai Geambasu
• 3
• 38

1. Introducere și definirea erorii

Eroarea Bus error (core dumped) este generată în sistemele de operare de tip Unix/Linux atunci când procesorul (CPU) încearcă să acceseze o adresă de memorie RAM la care hardware-ul nu poate efectua o citire sau o scriere fizică.

Din punct de vedere al sistemului de operare, această eroare corespunde semnalului SIGBUS (Semnalul cu numărul 7). Când kernelul Linux trimite acest semnal unui proces, aplicația este oprită forțat, iar sistemul creează un fișier numit core dump (o imagine a stării memoriei din momentul prăbușirii) pentru analiză ulterioară.

2. Cauzele principale ale erorii SIGBUS

Spre deosebire de Segmentation Fault (SIGSEGV) — care apare când un program încearcă să acceseze memorie nealocată sau nepermisă din punct de vedere software —, Bus Error (SIGBUS) indică aproape întotdeauna o problemă de aliniere fizică, de acces la hardware sau de stocare/fișiere mapate.

Cele mai frecvente cauze sunt:

1. Probleme de aliniere a memoriei (Memory Alignment Error):

   • Apare pe arhitecturi CPU mai stricte (cum ar fi ARM, SPARC) sau pe arhitecturi x86 în cazul instrucțiunilor vectoriale (AVX/SSE).

   • Se întâmplă când procesorul încearcă să citească un tip de date (de exemplu, un întreg pe 4 sau 8 octeți) de la o adresă de memorie care nu este divizibilă cu dimensiunea acelui tip de date.

2. Eroare la fișierele mapate în memorie (mmap):

   • Dacă o aplicație folosește funcția mmap() pentru a încărca un fișier direct în memorie, iar fișierul de pe disc este trunchiat, șters sau devine inaccesibil în timp ce procesul încearcă să îl citească/scrie.

3. Erori de citire/scriere fizică I/O (Disk / Hardware Failure):

   • Sector defect pe hard disk/SSD pe care se află fișierul de swap sau aplicația executată.

   • Probleme legate de rețea dacă se folosește un sistem de fișiere de rețea (NFS, SMB) care își pierde conexiunea la fișierul mapat.

4. Instrucțiuni hardware defectuoase (Defecțiuni RAM):

   • Module de memorie RAM fizic defecte sau setări incorecte în BIOS (XMP/overclock instabil).

3. Ghid pas cu pas pentru rezolvare și diagnosticare

Pasul 1: Identificarea rapidă a fișierelor mapate și spațiului pe disc

Dacă eroarea apare la rularea unui program standard sau a unui utilitar de sistem (ex: python, node, un utilitar din rețea):

• Verifică spațiul pe disc: Rulează df -h. Dacă disk-ul este plin ($100\%$), scrierile pe fișiere mmap pot eșua cu SIGBUS.

• Verifică mount-urile de rețea: Dacă rulezi un script peste NFS sau un drive de rețea, asigură-te că conexiunea este stabilă.

Pasul 2: Analiza fișierului Core Dump cu gdb

Pentru a găsi linia exactă de cod din cauza căreia s-a prăbușit aplicația:

1. Activați crearea fișierelor core dump în terminal:

   Bash

   ulimit -c unlimited
   

2. Rulați din nou aplicația pentru a genera fișierul core.

3. Deschideți fișierul core cu debugger-ul GNU (gdb):

   Bash

   gdb ./nume_executabil core
   

4. În consola gdb, tastați comanda bt (backtrace) pentru a vedea funcția și linia exactă unde s-a emis semnalul SIGBUS.

Pasul 3: Rularea sub valgrind (pentru dezvoltatori)

Dacă analizați propriul cod (C/C++), valgrind poate detecta accesul nealiniat sau pointerii invalizi:

valgrind --tool=memcheck ./nume_executabil

Pasul 4: Testarea memoriei RAM (Hardware)

Dacă eroarea apare aleatoriu în diverse programe care funcționau normal în trecut, cauza poate fi hardware:

• Verificați logurile kernelului cu comanda:

  Bash

  dmesg -T | grep -iE "memory|error|ecc|mce"
  

• Rulați un test dedicat de memorie: MemTest86 sau utilitarul memtester direct din Linux.

4. Cum se previne Bus Error în Codul Sursă (C / C++)

Dacă sunteți dezvoltator software, iată cele mai bune practici pentru a evita SIGBUS:

• Respectați alinierea structurilor: Nu folosiți casting direct de la un pointer de tip char* (1 byte) la un pointer de tip uint64_t* (8 bytes) fără să verificați alinierea adresei.

• Folosiți directiva alignas (C++11/C11):

  C++

  alignas(8) char buffer[64]; // Garantează alinierea la 8 octeți
  

• Tratarea corectă a apelului mmap: Când lucrați cu mmap, verificați întotdeauna dimensiunea fișierului folosind fstat() înainte de acces și capturați semnalul SIGBUS folosind sigaction().