* Giuseppe Ferruzzi ha scritto: > * Giuseppe Ferruzzi ha scritto: > > * Davide Prina ha scritto: > > > On 08/11/18 00:41, Giuseppe Ferruzzi wrote: > > > > > > > login da console e avviato > > > > la sessione X mediante startx. > > > > > > > Nel mio sistema è presente una sola alternativa nel gruppo > > > > x-session-manager che è openbox-session. > > > > > > cosa intendi? questo? > > > $ update-alternatives --list x-session-manager > > > > > > Che sappia io ha il default display manager indicato qui (il tuo dovrebbe > > > essere vuoto): > > > $ cat /etc/X11/default-display-manager > > > > > > e il default desktop environment è qui > > > $ ls -l /etc/alternatives/x-session-manager > > > > > > e il default windows manager è qui > > > $ ls -l /etc/alternatives/x-window-manager > > > > confermo > > > > > > quando invio startx > > > > in console il comando viene eseguito ma la sessione di openbox > > > > non si avvia più da se, debbo dargli un "aiutino" muovendo il > > > > mouse :| > > > > > > strano, non avevo mai sentito nulla del genere > > > > > > > Se invece creo il file ~/.xinitrc con exec /usr/bin/x-session-manager, > > > > > > ma cosa contiene il file > > > $ cat /etc/X11/xinit/xinitrc > > > > > > che viene eseguito quando ~/.xinitrc non esiste? > > > > > > dovrebbe contenere: > > > . /etc/X11/Xsession > > > > confermo > > > > > e guardando quel file dovresti avere un punto dove richiama tutti i file > > > presenti nella directory /etc/X11/Xsession.d > > > > > > if [ ! -d "$SYSSESSIONDIR" ]; then > > > errormsg "no \"$SYSSESSIONDIR\" directory found; aborting." > > > fi > > > > > > e qui dovresti averne almeno uno che richiama > > > /usr/bin/x-session-manager > > > > > > che dovrebbe essere un link simbolico al tuo desktop environment (come > > > indicato sopra) > > > > confermo > > > > > > Avete qualche idea? > > > > > > ma hai provato a fare un tail -f dei file di log (magari da un altro PC in > > > ssh o altrimenti da altra console) > > > /var/log/syslog > > > /var/log/Xorg.0.log > > > > > > e vedere se prima di bloccarsi c'è stampato qualcosa... e se stampa > > > qualcosa > > > quando muovi il mouse? > > > > > > o se nel file /var/log/Xorg.0.log trovi qualcosa di strano > > > > Di sospetto ho trovato solo quanto segue ma non mi sembra importante > > $ cat .local/share/xorg/Xorg.0.log | grep failed > > [ 72.142] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > > permitted) > > > > Credo che ormai non ci sia più niente dove non abbia già cercato. > > > > > In alternativa prova con debsums a verificare se i pacchetti di X e del > > > tuo > > > desktop enviroment hanno qualcosa di strano (controlla anche i file di > > > configurazione) > > > > Grazie Davide per la risposta. > > > > Nel frattempo farò qualche altro test, ma potrebbe anche risolversi > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > da se con gli upgrade. > ^^^^^^^^^^^^^^^^^^^^^ > > Ho sistemato prima di quanto pensassi... > Il nuovo linux kernel 4.19-rc7 mi ha risolto il problema :)
A titolo informativo di condivisione, ritorno su questo thread per un aggiornamento e soluzione definitiva. Non soddisfatto dell’utilizzo del kernel del ramo experimental e di non aver capito dove fosse stato il problema, ho reinstallato il kernel precedente 4.18.0-2-amd64, attualmente nel ramo testing/unstable. Mi sono accorto allora che dopo lo startx mi era apparso questa volta sulla console, qualche istante prima dello stallo con schermo nero sull’avvio di X e prima di dover muovere necessariamente il mouse come "aiutino" per far partire openbox, il seguente warning: random: CRNG INIT DONE random: 7 urandom warning(s) missed due to ratelimiting. Siccome era l’ultimo messaggio ricevuto dalla console, ho eseguito il seguente comando: # dmesg|grep random [ 0.000000] random: get_random_bytes called from start_kernel+0x94/0x52e with crng_init=0 [ 3.072335] random: fast init done [ 7.362429] random: systemd: uninitialized urandom read (16 bytes read) [ 7.405673] random: systemd: uninitialized urandom read (16 bytes read) [ 7.449896] random: systemd: uninitialized urandom read (16 bytes read) [ 16.650049] random: crng init done [ 16.650335] random: 7 urandom warning(s) missed due to ratelimiting # ho poi cercato cosa fosse random in linux e ho scoperto che è una device, quindi ho cercato quale compito svolgesse /dev/random e google mi ha portato su wikipedia https://it.wikipedia.org/wiki//dev/random Sinceramente però non sapevo cosa fare e se era veramente importante per il mio caso, allora sono andato di nuovo a googlare e ho trovato questo link risolutivo: https://www.linuxquestions.org/questions/debian-26/debian-hangs-at-boot-with-random-crng-init-done-4175613405/ Qui ho trovato HAVEGED e sono andato a leggerne la Descrizione che comodamente riporto: “Fonte di entropia per Linux che usa l'algoritmo HAVEGE haveged è un demone per entropia in spazio utente che non dipende dai meccanismi standard per la raccolta di casualità dal pool di entropia del sistema. Ciò è importante in sistemi con alte necessità di entropia o con limitata interazione dell'utente (es. server senza display)”. Poteva essere anche il mio caso in quanto uso un sistema di avvio di X in console con startx, senza l’ausilio di un DM. “Il demone haveged usa HAVEGE (HArdware Volatile Entropy Gathering and Expansion) per mantenere un pool di 1 M di byte casuali usati per riempire /dev/random ogni volta che la riserva di bit casuali in /dev/random scende sotto la soglia limite inferiore del dispositivo.” Nel link suddetto si afferma che all'avvio di X, il kernel attende i movimenti del mouse per inizializzare il generatore di numeri casuali e se questi sono in difetto l’avvio va in stallo. Allora haveged, il demone di entropia userspace, indipendente dai meccanismi standard, entra in gioco per incrementare l'entropia del sistema. Quindi senza indugio ho eseguito con convinzione: sudo apt install haveged sudo systemctl enable haveged e... ho risolto definitivamente il problema di cui in oggetto :) Per scrupolo ho verificato la ripetitività della situazione, disinstallando haveged il problema si ripresenta, reinstallando haveged il problema scompare. A differenza invece, sempre limitatamente al mio caso, l'attuale kernel 4.19-rc7 non ha bisogno di haveged. Un saluto a tutti. -- Giuseppe Ferruzzi
