„Dependency failed for sssd-pam.socket” în Ubuntu, după rularea scriptului Omakub

Recent am fost nevoit să schimb NVMe-ul pe desktop-ul cu Ubuntu. Problema era una veche: aveam un model 2242, mult prea scurt pentru slotul 2280 al plăcii de bază. Inițial, în loc de o extensie-adaptor, am recurs la banda adezivă textilă, cu gândul că voi găsi un adaptor în câteva zile.

Evident, acele zile s-au transformat în luni bune. Până la urmă am renunțat la ideea adaptorului și am decis să îl înlocuiesc complet cu un SSD 2280. Odată cu instalarea noului drive, am profitat de ocazie pentru a pune Ubuntu 24.04 curat, peste care am rulat scriptul Omakub pentru configurare.

Instalarea a părut să decurgă normal, însă la prima repornire solicitată de scriptul de pe Ubuntu 24.04.3 LTS, m-am lovit de o problemă neașteptată. Sistemul a refuzat să mai pornească, blocându-se complet înainte de a ajunge la interfața grafică.

Simptome observate la prima pornire

Sistemul nu ajungea, așadar, la ecranul de login. În locul interfeței grafice obișnuite, ecranul rămânea blocat pe un terminal text care afișa multiple erori critice, majoritatea fiind legate de SSSD (System Security Services Daemon):

• [DEPEND] Dependency failed for sssd-pam.socket - SSSD PAM Service responder socket.
• [DEPEND] Dependency failed for sssd-pam-priv.socket - SSSD PAM Service responder private socket.
• [DEPEND] Dependency failed for sssd-sudo.socket - SSSD Sudo Service responder socket.
• [DEPEND] Dependency failed for sssd-nss.socket - SSSD NSS Service responder socket.

Alte erori observate în flux au fost:

• [FAILED] Failed to start GRUB boot loader recovery script.
• [FAILED] Failed to start WPA supplicant.
• [DEPEND] Dependency failed for Modem Manager.

Starea sistemului era complet blocată la boot, fără acces la interfața grafică și, inițial, fără posibilitatea de a accesa un TTY (Ctrl+Alt+F2).

Cauza principală

SSSD (System Security Services Daemon) a fost instalat automat ca dependență de Omakub, dar nu a fost configurat corect. Socket-urile SSSD au eșuat la pornire, blocând procesul de boot și serviciile dependente, inclusiv autentificarea PAM și display manager-ul.

Ulterior, după deblocarea boot-ului, s-au manifestat și probleme cu GNOME Desktop Environment și driverul grafic Intel i915.

Cum am rezolvat problema

În cazul în care vă loviți la un moment dat de această problemă și sistemul este complet blocat, iată pașii pe care i-am urmat pentru a-l readuce la viață.

Pasul 1: Accesarea Recovery Mode

Deoarece sistemul nu bootează normal și TTY-urile nu răspund (inițial), singura soluție pentru a prelua controlul este Recovery Mode.

1. Reporniți computerul.
2. Țineți apăsată tasta Shift în timpul boot-ului pentru a accesa meniul GRUB.
3. Selectați „Advanced options for Ubuntu„.
4. Alegeți „Recovery mode” (de obicei a doua opțiune cu același kernel).
5. Din meniul de recovery, selectați „root – Drop to root shell prompt”.

1. Apasați Enter pentru maintenance (nu este necesară parola în recovery mode).
2. Remount filesystem-ul ca read-write (în recovery mode este read-only by default):

mount -o remount,rw /

Pentru verificare, rulați mount | grep " / " și asigurați-vă că obțineți rw (read-write) în output.

Pasul 2: Dezinstalarea SSSD – Deblocarea boot-ului

Acesta este pasul critic care deblochează sistemul și permite boot-ul și accesul la TTY. SSSD nu este necesar pe un PC personal (este folosit pentru autentificare enterprise/centralizată). Dezinstalarea lui elimină dependențele care blocau pornirea sistemului.

# Dezinstalare SSSD și toate componentele sale:
apt remove --purge sssd sssd-common libpam-sss libsss-sudo
apt autoremove
apt clean

Apoi, reconfigurați PAM (Pluggable Authentication Modules), un pas crucial pentru autentificarea locală:

# Reconfigurează PAM (Pluggable Authentication Modules):
pam-auth-update --force

Când apare interfața text pam-auth-update:

• Folosiți săgețile sus/jos pentru navigare.
• Apăsați Space pentru a bifa/debifa opțiuni.
• Apăsați Tab pentru a ajunge la butonul OK.
• Asigurați-vă că sunt bifate DOAR:
  • [*] Unix authentication
  • [*] Register user sessions
  • [*] Create home directory on login
  • [*] GNOME Keyring Daemon (dacă apare)
• IMPORTANT: [ ] SSSD trebuie să fie NEBIFAT (dezactivat)!

La final, opriți și blocați orice serviciu SSSD rămas în sistem și restartați:

# Oprește și blochează orice serviciu SSSD rămas în sistem:
systemctl disable sssd sssd-pam sssd-sudo sssd-autofs sssd-nss sssd-pac sssd-ssh 2>/dev/null
systemctl mask sssd 2>/dev/null

# Reboot
reboot

Pasul 3: Prima pornire după eliminarea SSSD

După reboot, sistemul va porni mult mai departe decât înainte:

• Nu mai sunt erori [DEPEND] Dependency failed for sssd.
• TTY-urile devin accesibile (Ctrl+Alt+F2, F3, etc.).
• Sistemul ajunge la ecranul de login grafic (GDM).

Dar apare o nouă problemă: după introducerea parolei, login-ul eșuează cu mesajul:

Failed to start session

Ecranul devine negru și revine la prompt-ul de login.

Pasul 4: Accesarea TTY pentru debugging

Acum că SSSD nu mai blochează boot-ul, putem accesa TTY-urile. Apăsați Ctrl + Alt + F2 (sau F3, F4, F5, F6) pentru a accesa un TTY (terminal text). Logați-vă cu username-ul și parola. Autentificarea funcționează, doar sesiunea grafică eșuează.

Pasul 5: Activarea SSH (Opțional, pentru debugging confortabil)

Dacă doriți să lucrați de pe alt computer pentru debugging mai ușor, puteți instala și porni serverul SSH:

# Instalare și pornire SSH server:
sudo apt update
sudo apt install openssh-server
sudo systemctl start ssh
sudo systemctl enable ssh

# Aflarea IP-ul sistemului
ip a
# sau
hostname -I

# Conectați-vă de pe alt computer
ssh nume_utilizator@adresa_IP

Pasul 6: Diagnosticarea problemei cu sesiunea grafică

Din TTY sau SSH, investigăm de ce sesiunea grafică eșuează:

# Verificați logurile de boot:
sudo journalctl -b | grep -i "failed\|error" | less

# Verificați erorile specifice GDM:
sudo journalctl -u gdm | tail -50

# Verificați erorile de sesiune X:
cat ~/.xsession-errors

Erorile identificate în cazul meu au fost:

• gdm.service: Failed with result 'core-dump'
• gpu-manager.service: Failed with result 'start-limit-hit'
• i915 0000:00:02.0: [drm] [ENCODER:98:DDI A/PHY A] failed to retrieve link info, disabling eDP

Concluzia mea a fost că GDM (GNOME Display Manager) eșua repetat, probabil din cauza unei configurații GNOME incomplete după instalarea Omakub, sau a unor probleme cu driverul grafic Intel i915 sau un desktop environment parțial corup (era, totuși, prea târziu ca să am chef de investigații mai complexe).

Pasul 7: Instalarea LightDM ca alternativă la GDM

LightDM este un display manager mai simplu și mai stabil decât GDM, util pentru a eschiva problema:

# Instalează LightDM
sudo apt update
sudo apt install lightdm

Când sunteți întrebați „Default display manager?”, selectați lightdm (folosiți săgețile și Enter pentru confirmare).

# Dezactivați GDM
sudo systemctl disable gdm
sudo systemctl stop gdm

# Activați LightDM
sudo systemctl enable lightdm
sudo systemctl start lightdm

Rezultatul a fost că LightDM a pornit și a afișat ecranul de login, dar mesajul „Failed to start session” a persistat, iar login-ul eșua. Așadar, problema nu era display manager-ul GDM, ci desktop environment-ul (GNOME).

Pasul 8: Verificarea configurației user-ului

Am verificat dacă problema e specifică user-ului sau sistemului, uitându-mă în erorile de sesiune:

cat ~/.xsession-errors

Output-ul arăta normal, fără erori explicite, sesiunea pur și simplu se oprea:

Xsession: X session started for cls at Sat Oct 25 07:05:12 PM CEST 2025
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
dbus-update-activation-environment: setting DISPLAY=:0
dbus-update-activation-environment: setting XAUTHORITY=/home/cls/.Xauthority
localuser:cls being added to access control list
dbus-update-activation-environment: setting GTK_MODULES=gail:atk-bridge
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1

Analiza a fost că X server pornește corect, variabilele de environment se setează, dar GNOME Shell nu se încarcă. Verificări suplimentare în logurile GNOME sau serviciile systemd user nu au relevat cauza exactă.

journalctl --user -b | grep -i "gnome|shell" | tail -50

systemctl --user --failed

Pasul 9: Reinstalarea Ubuntu Desktop

După ce am încercat dezinstalarea SSSD (a deblocat boot-ul) și instalarea LightDM (nu a rezolvat sesiunea), soluția care a funcționat a fost reinstalarea completă a pachetelor Ubuntu Desktop.

sudo apt update

sudo apt install --reinstall ubuntu-desktop
sudo apt install --reinstall gnome-shell gnome-session
sudo apt install --reinstall gdm3

# Reconfigurează GDM (display manager-ul implicit Ubuntu)
sudo dpkg-reconfigure gdm3
# Selectați gdm3 când întreabă (dacă ați instalat LightDM anterior)

sudo reboot

Acest pas a reinstalat toate pachetele desktop environment-ului GNOME, a restabilit configurația implicită a GNOME Shell și GNOME Session, a reparat dependențele corupte și a reconfigurat GDM cu setările corecte.

Rezolvarea problemelor cu driverul Intel i915

Dacă aveți hardware Intel și continuă să apară erori grafice:

sudo nano /etc/default/grub

Modificați linia:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=1 i915.enable_psr=0 i9fbc=0"

Salvați (Ctrl+O, Enter, Ctrl+X) și apoi:

sudo update-grub
sudo reboot

De ce s-a întâmplat asta?

Cauza tehnică exactă pare a fi că Omakub instalează SSSD ca dependență, dar SSSD necesită configurare explicită prin /etc/sssd/sssd.conf. Fără configurare, socket-urile SSSD eșuează la boot, creând dependency failures în lanț care blochează autentificarea PAM, rezolvarea numelor și sudo. Boot-ul se oprește deoarece systemd așteaptă aceste dependențe critice.

După eliminarea SSSD, boot-ul funcționează, dar GNOME rămâne parțial corupt (conflicte de pachete, configurații dconf incompatibile, cache-uri corupte). Reinstalarea ubuntu-desktop restabilește o configurație curată.

De ce TTY-urile nu funcționau inițial?

TTY-urile sunt gestionate de systemd. Când systemd așteaptă dependențe critice eșuate (SSSD), întregul proces de boot se blochează înainte ca serviciile getty@ttyX.service să fie activate complet.

Concluzie

Problema „boot failure” după instalarea Omakub a fost cauzată de o configurație incompletă a SSSD, care a blocat complet sistemul la pornire. După deblocarea boot-ului prin eliminarea SSSD, a apărut o a doua problemă separată cu GNOME Desktop Environment.

Soluția în 2 pași:

1. Dezinstalare SSSD → deblochează boot-ul și accesul TTY.
2. Reinstalare ubuntu-desktop → repară GNOME și sesiunea grafică.

Scripturile complexe de setup pot instala dependențe neprevăzute care necesită configurare manuală, iar dezvoltatorul uită să menționeze asta. Când apar dependency failures critice la boot, elimină dependența problematică (dacă nu e necesară) în loc să încerci să o configurezi superficial.