Debian Bullseye poweroff

[dea]

Buongiorno lista,

mi vergogno a scrivere dopo tantissimo tempo, leggo sempre quello che
scrivete ma da tanto, troppo tempo, non partecipo attivamente e ora sono
qui a chiedere a voi un parere...

Ho aggiornato un portatile Lenovo X1 passando da stable a Bullseye con
zero problemi se non uno piccolo, piccolissimo... terminata la procedura
di shutdown la macchina non si spegne.

Ammetto di avere già giocato un po' con ACPI, passato vari parametri a
GRUB relativi all'ACPI... aggiornato il firmware di macchina... senza
risultati.

Qualche consiglio ?

Grazie mille

Luca

[Federico Di Gregorio]

Ciao Andrea,

quale versione dell'X1? Ce ne sono tante.

federico

[Marco Ippolito]

> Ho aggiornato un portatile Lenovo X1

Anch'io su X1 in questo momento: ThinkPad X1 Carbon 6th.

Tu che versione?

$ sudo apt-get install inxi; inxi --color 0 --machine

(Taglia l'extra dall'output).

Anch'io su Stable. Vorrei evitare lo stesso problema.

Se mi capita e risolvo però.. torno qui e condivido la soluzione.

[Marco Ippolito]

> Io uso un X1 gen 4, giusto ieri ho aggiornato all'ultimo firmware per
> puro scrupolo ma non č cambiato nulla.

Figuriamoci.. se gen 4 ha problemi, gen 6 potrebbe averne di piů.

Anch'io ho aggiornato firmware.

Ritardo upgrade. :(

[Marco Ippolito]

> (Taglia l'extra dall'output).

Per comodità, questo comando con RegEx look-ahead fa il taglio:

inxi --color 0 --machine |
grep --only-matching --perl-regexp 'ThinkPad X1.*?(?=serial)'

[dea]

Il 06/04/21 11:05, Marco Ippolito ha scritto:

Io uso un X1 gen 4, giusto ieri ho aggiornato all'ultimo firmware per

puro scrupolo ma non è cambiato nulla.

Il kernel 5.10 funziona molto bene, ma non ho capito se manca qualche
"forzatura" che permetta il poweroff ... come da precedente mail,
segnalo che ho già giocato con Grub e con vari settaggi di ACPI senza
ottenere risultati.

Ciao

Luca

[dea]

Il 06/04/21 11:17, Marco Ippolito ha scritto:

>> Io uso un X1 gen 4, giusto ieri ho aggiornato all'ultimo firmware per

>> puro scrupolo ma non è cambiato nulla.
> Figuriamoci.. se gen 4 ha problemi, gen 6 potrebbe averne di più.

>
> Anch'io ho aggiornato firmware.
>
> Ritardo upgrade. :(
>

Bhe... penso che i problemi veri siano altri... il fatto che non si
spenga e che richieda di tenere il pulsante power premuto per 5 secondi
lo trovo solo un fastidio...

Ma mi piacerebbe risolverlo.

:)

Luca

[Davide Prina]

On 06/04/21 10:08, dea wrote:

> Ho aggiornato un portatile Lenovo X1 passando da stable a Bullseye

> terminata la procedura di shutdown la macchina non si spegne.

ma dai log non vedi nulla?

se esegui in un terminale:
$ journalctl -f

e poi da altro terminale prova con i seguenti:

# systemctl halt
# systemctl poweroff
# systemctl --force halt
# systemctl --force poweroff

i seguenti potrebbero farti perdere dei dati, vedi "$ man systemctl" per
dettagli

# systemctl --force --force halt
# systemctl --force --force poweroff

mentre esegui i comandi sopra prova a verificare se nel terminale dove
hai eseguito il comando "$ journalctl -f" appare qualche scritta con
errori/warning

Inoltre potrebbe essere interessante vedere il risultato del seguente
comando prima dell'esecuzione di ognuno dei precedenti:
$ systemctl is-system-running

Nota: halt non esegue uno shutdown, ma può essere interessante capire se
eventuali messaggi di warning/errore appaiono anche all'esecuzione di
questo o con solo poweroff

Ciao
Davide
--
Sistema operativo: http://www.debian.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

[Mattia Rizzolo]

Ciao!

On Tue, Apr 06, 2021 at 08:52:01PM +0200, Davide Prina wrote:
> On 06/04/21 10:08, dea wrote:
> > Ho aggiornato un portatile Lenovo X1 passando da stable a Bullseye
> > terminata la procedura di shutdown la macchina non si spegne.

Solo per dire che ho lo stesso problema, sempre un un X1 4th gen.
Sinceramente sono rimasto sorpreso non poco dal fatto che sembravo
l'unica cui succede, nonostrante gli X1 siano quantomeno comuni.

E non è solo lo spegnimento, a me anche la sospensione è "rotta".
É una regression presente da un paio d'anni, iniziata ad agosto 2019: se
ti tiri giù il kernel versione 5.2.7-1 da snapshot (IIRC quella è
l'ultima versione funzionante) dovrebbe andarti tutto (ti serve anche un
vecchio gcc-X-base e altra roba nel caso ti servano gli headers per
dkms).
Ho provato a compilarmi linux da me (intendo, quello upstream) è non mi
da alcun problema, quindi suppongo sia o una qualche patch o una qualche
opzione specifica del pacchetto Debian, ma la mia voglia di debuggare si
è fermata lì e devo ancora andare oltre per ora.

> ma dai log non vedi nulla?
>
> se esegui in un terminale:
> $ journalctl -f
>
> e poi da altro terminale prova con i seguenti:
>
> # systemctl halt
> # systemctl poweroff
> # systemctl --force halt
> # systemctl --force poweroff

Non ho provato ora, ma quando feci le mie prove all'epoca (non ho mai
provato `halt` perl) il log era semplicemente perfetto. Nel caso del
shutdown semplicemente arriva a "System halted" o equivalenti e poi si
freeza lì (come se fosse un vecchio computer senza ACPI che devi premere
il tasto per spegnerlo :P) e nel caso della sospensione uguale, solo che
da lì non è più recuperabile.

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

[Marco Ippolito]

Ieri ho provato Bullseye con tutti i flussi di lavoro che uso su X1 6th e ho
dovuto reinstallare e ricopiare i dati da backup. Piccole anomalie, ma si
accumulano. È giusto che Testing non corra 100% liscio. Per il computer di
produttività, preferisco Buster per ora.

[Davide Prina]

On 08/04/21 09:28, Mattia Rizzolo wrote:
> Ciao!
>
> On Tue, Apr 06, 2021 at 08:52:01PM +0200, Davide Prina wrote:
>> On 06/04/21 10:08, dea wrote:
>>> Ho aggiornato un portatile Lenovo X1 passando da stable a Bullseye
>>> terminata la procedura di shutdown la macchina non si spegne.

> É una regression presente da un paio d'anni, iniziata ad agosto 2019:
se
> ti tiri giù il kernel versione 5.2.7-1 da snapshot (IIRC quella è
> l'ultima versione funzionante) dovrebbe andarti tutto

> Ho provato a compilarmi linux da me (intendo, quello upstream) è non mi
> da alcun problema

mai hai aperto un bug report?

ma nella compilazione hai usato il .config di Debian o hai lasciato
quello upstream?

Se hai lasciato quello upstream, magari è una configurazione, sarebbe
interessante fare

1) ricompilare Linux upstream con il .config di Debian e se non funziona
lo spegnimento fare anche i punti seguenti

2) il diff tra i due file per capire cosa c'è di diverso.

3) si potrebbe riprendere il .config del 5.2.7-1 per vedere le
configurazioni tolte

4) se i precedente non hanno dato informazioni utili si potrebbe cercare
nelle patch se c'è qualcosa che potrebbe interessare quel processore

Secondo me se ci sono questi problemi sarebbe meglio cercare di farli
risolvere prima del rilascio della nuova stable...

[Mattia Rizzolo]

On Sun, Apr 11, 2021 at 08:49:46PM +0200, Davide Prina wrote:
> mai hai aperto un bug report?

Ho un vago ricordo di aver aperto un bug contro src:linux, ma non sarei
sicurissimo: una veloce ricerca tra le mie email non mi ha dato nulla.
Qualcosa di cui sono sicuro, però, è di aver menzionato il problem a bwh
all'ultimo Fosdem del 2020, ma dopo che lo ha guardato per qualche
minuto mi ha detto semplicemente di debuggarmelo...

> ma nella compilazione hai usato il .config di Debian o hai lasciato quello
> upstream?

Non ricordo, son passati troppi mesi :)
Me penso che tra le varie prove di aver anche provato ad usare il
.config di debian.

> Secondo me se ci sono questi problemi sarebbe meglio cercare di farli
> risolvere prima del rilascio della nuova stable...

Nella teoria hai ragione, ma sinceramente ho raramente avuto successo a
convincere il Release Team di fare qualcosa, e sono anche convinto che
un bug come questo sarebbe ignorato e sorvolato.

[dea]

Buonasera lista,

solo per segnalare che ho risolto il problema.

Avevo letto che sui kernel 5.x tra la 5.4 e la 5.7 (ma posso sbagliarmi)
c'era un problema su alcuni sistemi quando attiva l'accelerazione
Intel-VTd, semplicemente la macchina non si spegneva.

Pensavo che con un 5.10 fosse stato risolto, invece no.

Disattivando da bios l'accelerazione Intel-VTd la macchina si spegne
correttamente.


Ora, a seconda di come si usa la macchina può essere accettabile o meno,
nel mio caso lo è (è pur sempre un portatile e non faccio
virtualizzazione se non occasionalmente), quindi... volevo solo
segnalarvelo.


Ciao

Luca

[Davide Prina]

On 17/04/21 20:47, dea wrote:

> Disattivando da bios l'accelerazione Intel-VTd la macchina si spegne
> correttamente.

Questa cosa andrebbe segnalata, prova a vedere se c'è già un bug aperto
per il mancato spegnimento e aggiungi questa info, se non già presente.

Altrimenti apri un nuovo bug report e indica questo workaround per
risolvere il problema.

Come indicava Mattia il problema non si presenta su Linux upstream.

Se vuoi fare delle prove per capire come risolvere quel problema senza
intervenire sul BIOS puoi:

1) scaricarti i sorgenti di Linux upstream e ricompilare[¹] quelli,
verificando che si spegne

2) confrontare i .config usati dalla versione upstream e Debian per
cercare qualche parametro inerente alla virtualizzazione, magari è
sufficiente abilitare/disabilitare qualcosa

3) se non ha funzionato il punto precedente si potrebbe guardare nelle
patch Debian e provare a togliere quelle inerenti alla
virtualizzazione... se poi funziona, provare a toglierne solo alcune...
fino ad individuare il file modificato che causa le problematiche

Una volta individuato il problema segnalarlo nel bug report.

Ciao
Davide

[¹]
La compilazione di Linux, alla Debian way, impiega tempo uomo pochi
secondi/minuti (dipende se l'avete già fatto o è la prima volta), tempo
macchina dipende dal proprio PC, se non è troppo vecchiotto dovrebbe
essere sotto l'ora, se è recente e ben potente, probabilmente pochi minuti.

Per ricompilare alla Debian way Linux dei repository Debian (per quello
upstream dovrebbe bastare scompattare i sorgenti al posto di usare
linux-source) :

# apt install build-essential fakeroot rsync git linux-source
# apt build-dep linux

$ MIO_SORGENTE="~/src"
$ mkdir $MIO_SORGENTE
$ cd $MIO_SORGENTE

se avevi già installato una sotto-versione dei sorgenti di linux
precedente, allora bisogna spostare o cancellare la directory "vecchia"
prima di scompattare quella nuova:
$ mv linux-source.... linux-source....old

$ tar Jxvf /usr/src/linux-source-...
$ ln -sf ~/src/linux-source-... linux
$ cd linux

a questo punto si prende il .config dell'ultima versione di Linux Debian
(per l'upstream si può usare invece quella upstream, che ponso sia già

nel posto corretto)
$ cp /boot/config-... .config

ora si può usare "$ make oldconfig" eseguire a mano un minimo di
comandi[²] o crearsi uno script in "$MIO_SORGENTE/imposta_config.sh"
contenente questi comandi
$ ../imposta_config.sh

usare il numero di core disponibili +1 per velocizzare la compilazione,
nell'esempio qui sotto è per una macchina con 4 core (4+1=5)
$ time make -j 5 deb-pkg

# cd /home/davide/src
# apt install ./linux-image... ./linux-header... ./linux-libc-dev...

[²]
i comandi minimi sono:
Disabilitazione delle informazioni di debug (se servono, allora si può
lasciare abilitato)
$ scripts/config --disable DEBUG_INFO

Disabilitazione della firma di Linux (altrimenti non potendo firmare
Linux compilato viene generato un errore e si interrompe la compilazione)
$ scripts/config --set-str SYSTEM_TRUSTED_KEYS ""

Impostare la LOCALVERSION con la data attuale (al posto di xx si possono
mettere le proprie iniziali):
$ scripts/config --set-str LOCALVERSION "-xx-$(date +%Y%m%d)"
Questo fa in modo che i compilati abbiano un nome diverso da quello
Debian e tale diversità è visibile anche usando il comando uname

--
What happened in 2013 couldn't have happened without free software
(He credited free software for his ability to help disclose the U.S.
government's far-reaching surveillance projects).
Edward Snowden