Alessandro Baggi ha scritto:

ho un problema che mi affligge da quando ho installato Debian 12 su
diversi host con installazione su raid mdadm. Il problema si manifesta
con uno 'shutdown -h now' o un 'reboot' o spegnendo da XFCE.

hai provato usando systemd?

# systemctl poweroff
o
# systemctl reboot

Non vorrei che le vecchie modalità non siano al 100% funzionanti in
tutte le casistiche.

Se i risultati sono gli stessi, allora hai provato usando un diverso
DE (Desktop Environment) e magari anche un diverso DM (Desktop Manager)?
Io proverei con gdm3 e Gnome, dato che sono quelli ufficiali Debian.

Per tagliare la testa al toro, ho installato due diverse distribuzioni e
le ho usate per qualche mese (AlmaLinux 9 e Fedora 40) e il problema non
si è mai manifestato. Non sono riuscito a provare Ubuntu LTS.

ma anche qui hai usato la stessa combinazione di DM+DE?

Ho cercato in rete per molto tempo non trovando nulla, fino ad oggi: https://lore.kernel.org/lkml/ad286d5c-fd60-682f-bd89-710a79a710a0@huaweicloud.com/T/

io aprirei un bug report, se già non c'è su Debian, e indicherei quanto
qui hai riportato, con anche quel thread su kernel.org
Se c'è già un bug aperto, allora rispondi e riporta anche la tua
esperienza.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Strano che non ci siano molti casi riportati quando io su 3 macchine e
una virtuale hanno tutte riportato il problema. Forse non sono molte le >persone che hanno la root su raid mdadm?

Io uso da qualche anno, a casa, una debian testing con la root su mdraid 1 (nvme+ssd), e non ho mai avuto problemi di cui mi sia accorto. È vero che raramente faccio un reboot (sta sempre accesa), ma ormai sono cinque anni che la uso.

E da molti anni uso, al lavoro, una debian testing con root raid1. Prima erano due hdd, ora sono due ssd, dove "ora" è cominciato almeno otto anni fa. Questa fa reboot ancora più di rado, ma problemi sul raid non ne ho visti mai, per quel che può
servire.

-- fp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ora nella macchina virtuale il resync l'ho forzato io ma negli altri
casi da cosa può essere causato? Avviene un resync del raid a mia
insaputa per qualche problema (che ignoro)? In quali casi un resync
viene forzato dal sistema mentre è in uso?

Che io sappia, solo quando c'è un errore sul device fisico, o comunque un errore a livello inferiore al raid, il quale rileva una discrepanza e va a correggerla. Ma, sempre che io sappia, la ricostruzione avviene localmente ed è molto veloce, a meno
che non scompaia l'intero device e debba ricostruire tutto il raid.

-- fp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il Mon, Mar 31, 2025 at 06:18:16PM +0200, Francesco Potortì ha scritto:

Strano che non ci siano molti casi riportati quando io su 3 macchine e
una virtuale hanno tutte riportato il problema. Forse non sono molte le >persone che hanno la root su raid mdadm?

Io uso da qualche anno, a casa, una debian testing con la root su
mdraid 1 (nvme+ssd), e non ho mai avuto problemi di cui mi sia accorto.
È vero che raramente faccio un reboot (sta sempre accesa), ma ormai sono cinque anni che la uso.

E da molti anni uso, al lavoro, una debian testing con root raid1.
Prima erano due hdd, ora sono due ssd, dove "ora" è cominciato almeno
otto anni fa. Questa fa reboot ancora più di rado, ma problemi sul raid
non ne ho visti mai, per quel che può servire.

Ciao Francesco, si il RAID software è molto stabile, mentre va.
Qui si parla di un kernel panic che:

1) non è detto che corrisponda realmente ad un problema, una volta se
non c'era il disco di root all'avvio c'era un kernel panic ma non
indicava un problema reale se non di configurazione.

2) avviene non durante il funzionamento ma solo durante lo shutdown. Considerato che il sistema abbia fatto un sync e flush dei buffer del
disco correttamente, uno in teoria (e anche in pratica) potrebbe anche
staccare l'alimentazione senza perdere un dato.

la questione è che non è troppo "elegante" vedere quel KP in spegnimento, segno che l'ordine di spegnimento di qualcosa è sbagliato...

--

Amike,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il Mon, Mar 31, 2025 at 05:56:06PM +0200, Alessandro Baggi ha scritto:

Ciao Diego,
ho fatto qualche altro test con la macchina virtuale che ho usato per verificare il problema. Ho installato anche kdump-tools crash kexec-tools

Praticamente ho rimosso un disco del raid e l'ho reinserito sulla macchina virtuale e il resync è partito. A quel punto lancio lo shutdown -h now e ottengo il kernel panic.

Nel dmesg del coredump del crash viene riportato:

"md: md1: recovery interrupted"

quindi il problema sembrerebbe essere legato a quanto riportato nel link
dove si ha un kernel panic quando si interrompe un resync.

Ora nella macchina virtuale il resync l'ho forzato io ma negli altri casi da cosa può essere causato? Avviene un resync del raid a mia insaputa per qualche problema (che ignoro)? In quali casi un resync viene forzato dal sistema mentre è in uso?

Grazie.

Saluti, Alessandro.

Il resync periodico è mandatorio sul raid (altrimenti gli errori si rivelerebbero troppo tardi) per cui mi aspetto che di volta in volta
venga fatto partire. Dai un occhio a crontab per vedere ogni quanto
viene fatto partire. Le impostazioni del RAID permettono di metterlo a
bassa priorità e velocità in modo da non impattare troppo sul sistema. Inoltre il RAID software non "capisce" le partizioni quindi deve fare il
sync di tutto, anche dello spazio vuoto e quindi è abbastanza lento.
Diverso è se fai delle unità LVM2 in RAID che essendo più "intelligenti" fanno il sync sono dello spazio del volume e non dell'intero pool.

--

Amike,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Forse è il caso di provare la testing che è in freeze? È sconsigliato >usare una testing quando è in freeze?

Beh, testing vuol dire che non ha tutti i controlli di stabilità di una stable.

Freeze vuol dire che è quasi pronta per diventare stable e si aspettano correzioni su relativamente pochi pacchetti prima di farla diventare stabel. Abbastanza pochi che nel frattempo non si accettano aggiornamenti sugli altri.

Trovi lo stato del freeze di trixie (l'attuale testing) a https://release.debian.org/trixie/freeze_policy.html e trovi anche una lista dei pacchetti con release-critical bugs a https://udd.debian.org/bugs/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il Mon, Mar 31, 2025 at 10:54:56AM +0200, Alessandro Baggi ha scritto:

Ciao Davide e grazie per la tua risposta

hai provato usando systemd?

# systemctl poweroff
o
# systemctl reboot

Non vorrei che le vecchie modalità non siano al 100% funzionanti in
tutte le casistiche.

Lanciando ls -l /usr/sbin/shutdown mi dice che punta a /bin/systemctl quindi credo utilizzi gia systemctl di default o sbaglio?

Se i risultati sono gli stessi, allora hai provato usando un diverso
DE (Desktop Environment) e magari anche un diverso DM (Desktop Manager)?
Io proverei con gdm3 e Gnome, dato che sono quelli ufficiali Debian.

Per tagliare la testa al toro, ho installato due diverse distribuzioni e le ho usate per qualche mese (AlmaLinux 9 e Fedora 40) e il problema non si è mai manifestato. Non sono riuscito a provare Ubuntu LTS.

ma anche qui hai usato la stessa combinazione di DM+DE?

Accade sia da DE che da console. Su AlmaLinux e Fedora 40 (ora 41) cmq uso
la stessa configurazione (ligthdm + XFCE)

Ho cercato in rete per molto tempo non trovando nulla, fino ad oggi: https://lore.kernel.org/lkml/ad286d5c-fd60-682f-bd89-710a79a710a0@huaweicloud.com/T/

io aprirei un bug report, se già non c'è su Debian, e indicherei quanto qui hai riportato, con anche quel thread su kernel.org
Se c'è già un bug aperto, allora rispondi e riporta anche la tua esperienza.

Ok, cercherò se è gia presente un bugreport altrimento ne apro uno.

Quello che mi incuriosisce è che non c'è molto in rete su questo problema, quindi o quasi nessuno usa la root su device raid mdadm oppure non saprei.

Ma se la root non è sul LVM funziona?

--

Amike,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ho installato anche Debian Testing (13) ma è peggio di prima, ora ogni 2 >reboot uno va in panic e kdump non riesce a fare nulla, ovvero kexec
lancia il nuovo kernel ma restituisce diversi trace e si blocca.

Ultima prova che mi rimane da fare sulla Z890-F è quella di non usare >dischi nvme e usare due sata da 2.5 (anche se sulle altre il problema
rimane comunque)

Non so cosa altro fare....

Qualche idea di seguito. Le idee non vanno eseguite nell'ordine, fai prima quella che ti ispira di più

# Idea 1

Il sospetto è che questo avvenga durante un check automatico. Quindi disabilita i check prima di fermare la macchina:
# /usr/share/mdadm/checkarray -sa
# /usr/share/mdadm/checkarray -x --all
# /usr/share/mdadm/checkarray -sa
# halt

Il primo di dà lo stato attaule dei check. Il secondo dovrebbe cancellare un eventuale check in programma. Il terzo dovrebbe darti la certezza che non ne stanno girando al momento. Uso il condizionale perché penso di aver capito come funziona la
coda di comandi di mdadm, ma non ne ho completa certezza.

Se non cambia nulla, forse il problema non è quello.

# Idea 2

Siccome con la testing è peggio, proverei ad andare sia aventi che indietro. Installa una unstable. Nonostante il nome, generalmente funziona. E comunque stai facendo una prova, non può succedfere niente di grave. Poi prova con la oldstable. E con
la oldoldstable.

Dopo queste prove, se cambia qualcosa, bisognerebbe capire se il problema è nel pacchetto linux-image o nel pacchetto mdadm.


# Idea 3

Ora mdadm non usa cron, ma systemd. Questo probabilmente non è vero con la oldstable, e molto probabilmente non è vero con la oldoldstable.

Nel mio sistema vedo questi:

mdadm: /usr/lib/systemd/system/mdadm-grow-continue@.service
mdadm: /usr/lib/systemd/system/mdadm-last-resort@.service
mdadm: /usr/lib/systemd/system/mdadm-last-resort@.timer
mdadm: /usr/lib/systemd/system/mdcheck_continue.service
mdadm: /usr/lib/systemd/system/mdcheck_continue.timer
mdadm: /usr/lib/systemd/system/mdcheck_start.service
mdadm: /usr/lib/systemd/system/mdcheck_start.timer
mdadm: /usr/lib/systemd/system/mdmon@.service
mdadm: /usr/lib/systemd/system/mdmonitor-oneshot.service
mdadm: /usr/lib/systemd/system/mdmonitor-oneshot.timer
mdadm: /usr/lib/systemd/system/mdmonitor.service
mdadm: /usr/lib/systemd/system-shutdown/mdadm.shutdown

Cerca di capire cosa fanno. In particolare, l'ultimo contiene un comando che viene dato allo shutdown. Magari prova a disabilitarlo.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mdadm: /usr/lib/systemd/system/mdadm-grow-continue@.service
mdadm: /usr/lib/systemd/system/mdadm-last-resort@.service
mdadm: /usr/lib/systemd/system/mdadm-last-resort@.timer
mdadm: /usr/lib/systemd/system/mdcheck_continue.service
mdadm: /usr/lib/systemd/system/mdcheck_continue.timer
mdadm: /usr/lib/systemd/system/mdcheck_start.service
mdadm: /usr/lib/systemd/system/mdcheck_start.timer
mdadm: /usr/lib/systemd/system/mdmon@.service
mdadm: /usr/lib/systemd/system/mdmonitor-oneshot.service
mdadm: /usr/lib/systemd/system/mdmonitor-oneshot.timer
mdadm: /usr/lib/systemd/system/mdmonitor.service
mdadm: /usr/lib/systemd/system-shutdown/mdadm.shutdown

...

Ho anche io tutti gli stessi unit/timer (ps: con quale comando hai
ottenuto questa lista?).

$ dlocate mdadm | grep systemd

pacchetto dlocate, utile per sapere quali sono i file che hanno a che fare con un certo paccehtto e più ancora per trovare a quale pacchetto appartiene un dato file

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alessandro Baggi ha scritto:

Davide Prina ha scritto:

hai provato usando systemd?

# systemctl poweroff
o
# systemctl reboot

Non vorrei che le vecchie modalità non siano al 100% funzionanti in
tutte le casistiche.

Lanciando ls -l /usr/sbin/shutdown mi dice che punta a /bin/systemctl
quindi credo utilizzi gia systemctl di default o sbaglio?

qualcosa mi sfugge:

1) se non ricordo male shutdown usa il parametro -h per indicare quando
quindi shutdown -h now
ma systemctl usa -h per l'help

2) systemctl può essere invocato anche come systemctl halt che non spegne
la macchina

ma
$ man shutdown
[...]
-h
The same as --poweroff, but does not override the action to take if it
is "halt". E.g. shutdown --reboot -h means "poweroff", but
shutdown --halt -h means "halt".
[...]

$ man systemctl
[...]
-h, --help
Print a short help text and exit.
[...]

Ed effettivamente
$ ls -l /usr/sbin/shutdown
lrwxrwxrwx /usr/sbin/shutdown -> ../bin/systemctl

probabilmente in systemctl c'è un wrapper che guarda se il comando eseguito
è showtdown allora trasforma quanto passato...

ora non ho voglia di provare... odio riavviare o spegnere e riaccendere

Bho, io proverei ad usare systemctl

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alessandro Baggi ha scritto:

Forse è il caso di provare la testing che è in freeze? È sconsigliato usare una testing quando è in freeze?

ci sono varie fasi di freeze.
Però quando la testing entra in freeze potrebbero essere tolti dei
pacchetti temporaneamente e quindi fare un'installazione in tale
periodo potrebbe non essere l'ideale perché potresti non riuscire
ad installare quanto vuoi.

Inoltre, se non ricordo male, da un certo punto anche Sid sarà
impattata perché non si potranno caricare nuovi pacchetti neanche
qui.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alessandro Baggi ha scritto:

Il problema non accade al primo reboot ma in maniera random quando
effettuo uno shutdown o un reboot. Accade ogni N giorni. Per replicarlo sulle macchine che ho elencato mi sono messo a manina a riavviare finche
non usciva l'errore.

questo mi fa pensare ad un problema che ho riscontrato ieri e di cui ho
postato qui poco fa. È solo una sensazione, ma visto che è un cambiamento proprio di questi giorni...
L'uso di tmpfiles.d

prova a vedere cosa contiene
$ cat /etc/tmpfiles.d/tmp.conf

e guarda se in una di quelle directory c'è qualcosa che potrebbe influire
a tale funzionamento.

Io proverei a contare il numero di riavvii necessari e verificare se
questo equivale a quanto specificato qui.

Con tmpfiles.d puoi far fare determinate operazioni ogni X riavvii o giorni o...

Potresti anche modificare la regola per farla accadere ad ogni riavvio,
così per accertarti che sia quello il colpevole.

Potrebbe essere che quando deve accedere fa qualcosa che causa il kernel
panic perché, ad esempio, non trova più un file che è necessario per lo spegnimento/reboot della macchina.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il Sun, Apr 06, 2025 at 12:01:52PM +0200, Alessandro Baggi ha scritto:

Buongiorno Davide e grazie per la risposta.

Il 06/04/25 10:54, Davide Prina ha scritto:

Alessandro Baggi ha scritto:

Davide Prina ha scritto:

hai provato usando systemd?

# systemctl poweroff
o
# systemctl reboot

Non vorrei che le vecchie modalità non siano al 100% funzionanti in tutte le casistiche.

Lanciando ls -l /usr/sbin/shutdown mi dice che punta a /bin/systemctl quindi credo utilizzi gia systemctl di default o sbaglio?

qualcosa mi sfugge:

1) se non ricordo male shutdown usa il parametro -h per indicare quando
quindi shutdown -h now
ma systemctl usa -h per l'help

2) systemctl può essere invocato anche come systemctl halt che non spegne
la macchina

ma
$ man shutdown
[...]
-h
The same as --poweroff, but does not override the action to take if it
is "halt". E.g. shutdown --reboot -h means "poweroff", but
shutdown --halt -h means "halt".
[...]

$ man systemctl
[...]
-h, --help
Print a short help text and exit.
[...]

Ed effettivamente
$ ls -l /usr/sbin/shutdown
lrwxrwxrwx /usr/sbin/shutdown -> ../bin/systemctl

probabilmente in systemctl c'è un wrapper che guarda se il comando eseguito
è showtdown allora trasforma quanto passato...

ora non ho voglia di provare... odio riavviare o spegnere e riaccendere

Non dirlo a me, sto diventando scemo a forza di accendere/spegnere/riavviare

Bho, io proverei ad usare systemctl

Non mi resta che provare e verificare ulteriormente.

Grazie.

Saluti, Alessandro.

Hai provato ad usare poweroff?

which shutdown
/usr/sbin/shutdown
$ ls -l /usr/sbin/shutdown
lrwxrwxrwx 1 root root 16 feb 21 22:18 /usr/sbin/shutdown -> ../bin/systemctl
$ which poweroff
/usr/sbin/poweroff
$ ls -l /usr/sbin/poweroff
lrwxrwxrwx 1 root root 16 feb 21 22:18 /usr/sbin/poweroff -> ../bin/systemctl

--

Amike,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ho ricevuto un aggiornamento da un bug in cui mi è stato detto che c'è
una race condition nei moduli del kernel relativi ad md.

Inoltre mi è stato chiesto di compilare un kernel mainline (6.14 credo),
di applicare la patch e testare.

Ho compilato, installato l'immagine e i moduli, lanciato
update-initramfs -c -k 6.14.0-1-amd64, lanciato update-grub senza
ricevere errori ma al riavvio in un primo momento ottenevo:

"unable to mount rootfs on /dev/md1 or unknown-block.."

e successivamente:

mdadm: No devices listed in conf file were found
mdadm: error opening /dev/md?*: No such file or directory

e poi lancia busybox.

Vado a memoria, mi potrei sbagliare, ma c'è da qualche parte nel kernel l'opzione di fare un autodetect dei raid (che credo sia il modo normale oggi) oppure affidarsi a mdadm.conf.

Forse il problema è che non c'è un mdadm.conf nell'initramfs e non fa autodetect. E l'autodetect credo sia necessario se si ha /boot su raid. Ma di nuovo, vado a memoria di cose configurate anni fa, lo dico solo perché magari ti potrebbe mettere in
qualche modo sulla strada giusta

-- fp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il Thu, Apr 10, 2025 at 08:48:19AM +0200, Alessandro Baggi ha scritto:

Il 08/04/25 16:43, Alessandro Baggi ha scritto:

Tornando al problema del kernel panic, ho fatto le diverse prove per verificare che la patch funzionasse.

Prima ho riprodotto il problema con il kernel 6.1 e al terzo reboot
è andato in panic.

Poi ho avviato il kernel 6.14 con la patch applicata e dopo 50
reboot non ha riportato nessun panic. Ora 50 reboot sono pochini per
dire che è fixato, ma nei prossimi giorni faro altri testi con altro hardware.

Questo è il link del bug per chi volesse approfondire.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086175

Saluti, Alessandro

Buonasera,
a quanto pare il bug è stato chiuso e se non ho letto male è disponibile in experimental. Questo significa che la Stable e LTS non vedranno la correzione? E riguardo a testing?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086175

Saluti, Alessandro.

Salve a tutti,
per chi fosse interessato, un piccolo aggiornamento riguardo questo
problema. I pacchetti sono stati rilasciati per unstable ed experimental. Su debian testing il backport dovrebbe essere gia attivo mentre per la stable con 6.1.x ci vuole qualche aggiustamento per avere la patch funzionante.

Saluti, Alessandro.

Complimenti. Un ringraziamento da parte mia ma penso da parte di tutti
per la costanza...

--

Amike,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alessandro Baggi ha scritto:

a quanto pare il bug è stato chiuso e se non ho letto male è disponibile in experimental. Questo significa che la Stable e LTS non vedranno la correzione?

per problemi di questo tipo le patch prima o poi vengono portate fino a
tutte le stable, old-stable, ... fino a quando sono supportate.

E riguardo a testing?

anche in testing viene portato, dopo aver soggiornato in Sid per un po'
di giorni... anche nelle parti di freeze più avanzate i bug di questo
genere solitamente vengono fatti passare manualmente

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alessandro Baggi ha scritto:

In pratica sono riuscito a risolvere il problema usando il comando:

# make -j12 bindeb-pkg

ok quello è un pezzetto per compilarsi Linux, ma prima bisogna eseguire
questi (è quello che facevo fino a poco tempo fa... ora uso le versioni presenti in Debian senza ricompilare):

# apt update
# apt -u upgrade; apt -u dist-upgrade

per amd64 installare i pacchetti (per altre architetture hardware
dovrebbero essercene altri simili):
# apt install linux-headers-amd64 linux-image-amd64

qui se si compila da sorgente presente in Debian, se si prende una
versione da altra parte questo può essere saltato
# apt install linux-source

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

$ mkdir ~/src
$ cd ~/src

questo qui sotto deve essere saltato se si prende i sorgenti fuori da
Debian
$ tar Jxvf /usr/src/linux-source-$(uname -r | cut -d '.' -f 1-2).tar.xz

questo va adattato se si usa un sorgente diverso da quello presente in
Debian
$ ln -sf ~/src/linux-source-$(uname -r | \
sed "s/\([0-9]*\.[0-9]*\)\..*/\1/") ~/src/linux

$ cd linux

...ora se si deve/vuole si deve modificare la configurazione...
si può partire dalla configurazione della versione di Linux in esecuzione:
$ cp /boot/config-$(uname -r) .config

Disabilitazione delle informazioni di debug (se servono, allora si può lasciare abilitato)
$ scripts/config --disable DEBUG_INFO

Disabilitazione della firma di Linux, altrimenti non compila se non si
ha una chiave valida
$ 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)"

Se si vuole modificare la configurazione di Linux... è utile eseguirlo
per completare la configurazione: tutto ciò che non è presente nel
file di configurazione verrà chiesto
$ make nconfig

ATTENZIONE: in ogni caso bisogna entrare e
1) modificare CONFIG_SYSTEM_TRUSTED_KEYS che indica di firmare il
pacchetto con la chiave di un DD
in alternativa si può disabilitare il modulo signing:
$ scripts/config --set-str SYSTEM_TRUSTED_KEYS ""
2) mettere una stringa che identifichi la propria compilazione in
LOCALVERSION
in alternativa si può impostare con
$ scripts/config --set-str LOCALVERSION "-xx-$(date +%Y%m%d)"

ed infine si fa partire la configurazione
$ time make -j 5 deb-pkg

dove il valore dopo j è il numero di processori + 1
Per vedere quanti processori si ha si può eseguire
$ echo $(($(cat /proc/cpuinfo | grep processor | wc -l)+1))

si otterranno i .deb sotto ~/src.
Io installo, con dpkg -i <elenco pacchetti>:
* linux-image
* linux-header
* linux-libc-dev

e poi ho installato con dpkg -i *.deb

ok, se non hai disabilitato la compilazione del pacchetto debug, allora
quello potresti non installarlo.

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Il 13/04/25 10:32, Davide Prina ha scritto:

anche in testing viene portato, dopo aver soggiornato in Sid per un po'
di giorni... anche nelle parti di freeze più avanzate i bug di questo
genere solitamente vengono fatti passare manualmente

Quindi leggendo da qui >https://salsa.debian.org/kernel-team/linux/-/merge_requests/1451 il
kernel backport dovrebbe avere già la patch pronta?

Da quanto leggo, la pezza è stata applicata a debian/latest, che presumo sia l'attuale stable (12, bookworm). Non vedo riferimenti a testing (trixie).

-- fp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)