Re: Compilazione kernel con modulo binder_linux e waydroid.

2023-08-30 Per discussione Beppe Cantanna
Ciao,
non ho riportato tutti i passaggi, ma anche se l'ho fatto ormai un paio di
settimane fa, se non ricordo male anche io ho seguito più o meno quanto
descrivi, cioè la via maestra Debian Way, tant'è che nei vari test ho
prodotto i pacchetti linux-image*.deb che ho installato ma senza riuscire a
attivare il benedetto binder:

   - ho installato i pacchetti che servono per compilare. Ovviamente non mi
   sono inventato nulla, ma ho seguito le varie guide sul sito Debian che non
   riporto qui perché non ce l'ho sottomano.
   - ho scaricato il tar del sorgente.
   - ho decompresso il paccone ottenendo un path con tutti file.
   - ho copiato nel path dei sorgenti scaricati il file /boot/config*
   prendendo quello che stavo usando in quanto mi pareva andasse bene e non
   volevo crearne uno da zero.
   - ho eseguito il *make menuconfig* per abilitare le parti che non lo
   erano ... e qui il liquorix/zen mi ha fregato perché se per dire nel
   kernel-non-liquorixZen il modulo binder era in tristate, nel
   kernel-liquorixZen era in boolean e quindi accettava solo un SI o NO.
   - NON ho fatto i link alla cartella source perché non mi pareva ci fosse
   la necessità, in quanto stavo creando una versione personalizzata in un
   path totalmente separato che mi avrebbe prodotto dei *deb da installare con
   dpkg. Ma potrei sbagliarmi e invece i link servono.
   - NON ho eseguito lo script imposta_config.sh perché non saprei dove
   prenderlo o come popolarlo. Tutte le modifiche che vorrei fare mi aspetto
   di poterle eseguire o direttamente nel file config che poi è un file di
   testo, o via make menuconfig che dovrebbe essere più comodo.
   - ho usato impostazioni di compilazione che non prevedono la firma.
   Tant'è che ho anche generato dei file linux-image*.deb e li ho installati
   ma senza sto benedetto binder.
   non ho usato il *time make ...* perché non lo conoscevo e tutt'ora non
   so che fa ma dopo me lo guardo, mentre per evitare il passare delle ere
   geologiche da un test di compilazione all'altro ho poi scoperto la
   possibilità di impletemntare una chache.
   - quando la compilazione veniva completata, anche io ho installato i
   singoli pacchetti linux-image*.deb, linux-header*.deb, anche se non mi pare
   sia stato prodotto il linux-libc-dev*.deb


Per quanto riguarda il suggerimento di prendere il config di una versione
che voglio ricompilare, considera che in alcuni casi si trattava di kernel
che non metteva direttamente a disposizione il sorgente dal repository, ma
potevi scaricare il relativo tar da github.

Per esempio qui si vede la configurazione del repository:

bpxroot@hpebian:~/kernel-src/linux-source-6.4$ sudo grep -ri liquorix
/etc/apt/
grep: /etc/apt/keyrings/liquorix-keyring.gpg: binary file matches
/etc/apt/sources.list.d/liquorix.list:*deb* [arch=amd64
signed-by=/etc/apt/keyrings/liquorix-keyring.gpg]
https://liquorix.net/debian trixie main
/etc/apt/sources.list.d/liquorix.list:*deb-src* [arch=amd64
signed-by=/etc/apt/keyrings/liquorix-keyring.gpg]
https://liquorix.net/debian trixie main

ma se cerco il sorgente liquorix trovo nulla:

$ apt-cache search linux- | grep -i liquorix | grep -i linux-source
$

non è che non ci sono i pacchetti liquorix:

$ apt-cache search linux-  | grep -i liquorix
linux-headers-6.4.1-1-liquorix-amd64 - Header files for Linux
6.4.1-1-liquorix-amd64
linux-headers-6.4.1-2-liquorix-amd64 - Header files for Linux
6.4.1-2-liquorix-amd64
... lista lunga ...
linux-image-6.4.9-1-liquorix-amd64 - Linux 6.4 for 64-bit PCs
linux-image-liquorix-amd64 - Linux image for liquorix on 64-bit PCs

se cerco altri sorgenti:

$ apt-cache search linux-  | grep -i linux-source
linux-source - Linux kernel source (meta-package)
linux-source-6.4 - Linux kernel source for version 6.4 with Debian patches
linux-source-6.1 - Linux kernel source for version 6.1 with Debian patches


quindi se uno vuole i sorgenti di liquorix li cerca su github ma non è
detto siano esattamente quelli del pacchetto che ti mettono a disposizione,
d'altronde lo capisco, già ti danno i sorgenti di tutto quello che fanno
quindi se ti serve roba precedente te la prendi e in un paio di ore la
compili.


Nei fatti il mio dubbio era specificatamente in merito alle differenti
impostazioni possibili relative al modulo binder e a quelle che a me
sembrano essere delle pe rme incomprensibili incompatibilità.

Cmq grazie per le indicazioni.









Il giorno mar 29 ago 2023 alle ore 23:14 Davide Prina 
ha scritto:

> Beppe Cantanna ha scritto:
>
> > Perché i kernel linux-image-6.4.0-2-amd64 e
> linux-image-6.4.11-x64v3-xanmod1
> > sono compilati con il modulo binder attivo, ma se cerco di riportare le
> stesse
> > impostazioni sul sorgente di linux-image-6.4.11-2-liquorix-amd64 la
> > compilazione fallisce?
>
> ma da quanto scrivi non mi sembra che compili usando al Debian way.
> Quando usi un file di configurazione di un una versione versione precedente
> devi far fare il check per vedere se manca 

Re: Stranezza dischi Usb

2023-08-30 Per discussione Beppe Cantanna
> bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
> Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable
filesystem.

dovevi indicare sdc1 o la partizione montanta se diversa da 1

> bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
> Error powering off drive: The drive in use: Device /dev/sdc1 is mounted
(udisks-error-quark, 14)

infatti qui ti da l'errore dicendoti che sdc1 è montata

sì, errore che non si ha usando eject nelle stesse condizioni, senza
profilo amministrativo, esattamente come se operassi da DE. Successivamente
posso ripristinare il disco con *eject -t **/dev/sdc*, senza dover sfilare
fisicamente la chiavetta usb.



Il giorno mer 30 ago 2023 alle ore 18:28 Davide Prina 
ha scritto:

> Beppe Cantanna ha scritto:
>
> > bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
> > Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable
> filesystem.
>
> dovevi indicare sdc1 o la partizione montanta se diversa da 1
>
> > bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
> > Error powering off drive: The drive in use: Device /dev/sdc1 is mounted
> (udisks-error-quark, 14)
>
> infatti qui ti da l'errore dicendoti che sdc1 è montata
>
> 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
>
>

-- 
*CANTANNA Giuseppe*
cel. +39 349 1998700
giuseppe.canta...@glugto.org
canta...@glugto.org
canta...@gmail.com

bproot.bc - Linux user n. 502620 registered on http://counter.li.org/
*Nodo NINUX: *broot*.*


*Per favore non inviatemi allegati in formato MS
Office.​​Utilizza​te​ alternativamente documenti in formato OpenDocument.*
​
http://en.wikipedia.org/wiki/OpenDocument

​ ​
http://it.wikipedia.org/wiki/OpenDocument


*​*http://www.documentfoundation.org/
* ​ *https://it.libreoffice.org/
​ ​


Re: flash player

2023-08-30 Per discussione Davide Prina
Christian Surchi ha scritto:

> Il 30/08/2023 17:14 Davide Prina ha scritto:

>> https://snapshot.debian.org/binary/flashplugin-nonfree/
> 
> Questi erano tutti degli installer che andavano a recuperare il plugin 
> dal sito di adobe, ma adobe ha smesso da anni di rilasciarlo. EOL e 
> quindi la vedo complicata.

quindi bisogna trovarsi un vecchio PC o una VM su cui sia ancora installato
e vedere dal pacchetto flashplugin-nonfree dove andava a mettere i file
per recuperarli...

So che ci sono progetti che permettono ancora di avere flash, alcuni sono
a pagamento, altri no... però non so quanto siano affidabili e se
funzionino su Debian.

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



Re: Stranezza dischi Usb

2023-08-30 Per discussione Davide Prina
Beppe Cantanna ha scritto:

> bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc
> Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable 
> filesystem.

dovevi indicare sdc1 o la partizione montanta se diversa da 1

> bpxroot@hpebian:~$ sudo /usr/bin/udisksctl power-off -b /dev/sdc
> Error powering off drive: The drive in use: Device /dev/sdc1 is mounted 
> (udisks-error-quark, 14)

infatti qui ti da l'errore dicendoti che sdc1 è montata 

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



Re: Connection refused

2023-08-30 Per discussione Davide Prina
Piviul ha scritto:

> è da un po' di tempo che improvvisamente su un server di 
> sviluppo postgres ha smesso di rispondere dall'esterno.

verifica che sia in ascolto il listner sul server:

# netstat -putan

se c'è, allora prova con telnet dal client

Se il listner è esposto cifrato, allora potrebbe essere
dovuto al fatto che è stato aggiornato il server e non
accetta connessioni con chiper ora deprecati. Se è
questo il problema dovresti aggiornare il client

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




Re: flash player

2023-08-30 Per discussione Christian Surchi

Il 30/08/2023 17:14 Davide Prina ha scritto:

Paride Desimone ha scritto:


Qualcuno sa dove poter trovare una vecchia versione di flash player


https://snapshot.debian.org/binary/flashplugin-nonfree/


Questi erano tutti degli installer che andavano a recuperare il plugin 
dal sito di adobe, ma adobe ha smesso da anni di rilasciarlo. EOL e 
quindi la vedo complicata.







Re: flash player

2023-08-30 Per discussione Davide Prina
Paride Desimone ha scritto:

> Qualcuno sa dove poter trovare una vecchia versione di flash player

https://snapshot.debian.org/binary/flashplugin-nonfree/

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




Re: Schermo bianco

2023-08-30 Per discussione Davide Prina
Franco Peci

> Da una decina di giorni a volte mi capita che quando accendo il pc o 
> dopo la sospensione il video (Samsung syncmaster serie 5 TB550) appaia 
> tutto bianco. Se con il telecomando lo spengo e lo riaccendo torna a 
> funzionare.

prima di tutto guarda nei log per cercare qualche indizio al problema:
$ journalctl -b 0

se vuoi vedere solo gli errori con una certa gravità puoi usare anche
il parametro -p con il numero di gravità (es: 3, 4, ... più è alto il
numero e più log vengono mostrati)

Poi volevo chiederti se hai più monitor.

Ho notato in questi giorni che con Gnome se attacco un secondo monitor,
ogni tanto all'avvio mi prende come monitor primario il secondo, anche
se è spento, e quindi sembra che il monitor primario non funzioni o GDM
non mi mostri l'elenco degli utenti.

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



Re: Errore in dmesg di "task kworker"

2023-08-30 Per discussione Alessandro Rubini
Riparto dal messaggio originale. E` un po' che non metto mano in queste
cose quindi non volevo dire bestialita`, ma ho visto degli errori in
alcune altre risposte.

Prima di tutto, no, questa volta non dico sia colpa di systemd :)

> [3730483.156140]

Questo e` il tempo dall'accensione, in secondi. 43.17 giorni.  Il
sistema internamente non usa il tempo esterno perche` non e`
affidabile (se l'utente o ntp cambia l'ora che succede?)


> INFO: task kworker/0:2:32752 blocked for more than 120 seconds.

Dopo dice "task:kworker/0:2" a conferma che 32752 e` il pid
di kworker/0:2 . Quindi fare "ps" e` inutile.

Non e` "andato in timeout", espressione che indica il fallimento di
qualcosa. Ci ha messo piu` di 120 secondi a fare quello che doveva
fare. Se il messaggio e` per 120 secondi, e non 120ms, vuol dire che
e` abbastanza normale che ci metta un po'.

> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Cercherei in rete o nei sorgenti "hung_task_timeout_secs", sapendo che
la prima fonte e` piena di falsi. Sono fuori sede e non ho un
linux.git sotto mano, ma prima o poi ci guardo per curiosita` mia.

> [3730483.156210] Workqueue: events_freezable mmc_rescan

Questa e` la coda di cose da fare per questo processo. Quindi immagino
stia facendo mmc_rescan, che potrebbe essere un'operazione lunga, in
particolare se la memoria e` in uso (quindi l'I/O di rescan va
intercalato con gli altri I/O). Ma non so cosa sia mmc_rescan, va
controllato.

> [3730483.156233] Call trace:
> [3730483.156237]  __switch_to+0xf8/0x1e0
> [3730483.156252]  __schedule+0x2a8/0x830
> [3730483.156260]  schedule+0x60/0x100

Qui si vede che il messaggio avviene durante un cambio di contesto
(switch_to, schedule), quindi non e` detto che quanto sta nello stack
trace sia significativo. Su un'altra macchina mi capita spesso e lo
stack trace non ha relazione col baco che genera il ritardo.

> [3730483.156269]  __mmc_claim_host+0xbc/0x208
> [3730483.156276]  mmc_get_card+0x3c/0x50
> [3730483.156283]  mmc_sd_detect+0x28/0x98
> [3730483.156290]  mmc_rescan+0xa0/0x2c8
> [3730483.156297]  process_one_work+0x208/0x480
> [3730483.156307]  worker_thread+0x50/0x428

In realta` sembra che la cosa sia significativa. Il processo che
subisce schedulazione sta facendo mmc_rescan (e non ha schedulato per
piu` di 120 secondi: non ci dice quanto perche` non e` ancora
successo). Andrebbe verificato cosa sia questa cosa. Non e` che la macchina
ha un secondo slot sd, non popolato, che viene erronemaente rilevato
per un bogone sul segnale di presenza ("card inserted")?

Comunque non e` nulla di fatale, tanto che si puo` disabilitare il
messaggio. Certo, la sdcard non e` eterna, in particolare se ci si
scrive molto.

> Mi dovrei preoccupare?

Il giusto, non di piu` non di meno.



Re: Errore in dmesg di "task kworker"

2023-08-30 Per discussione Alessandro Rubini
> le SD non hanno alcun sistema di monitoraggio ala-SMART, quindi
> muoiono di botto e basta.

In realta` alcuni vendo qualcosa offrono. Ho un cliente che usa una
libreria del vendor sulle eMMC dei suoi impianti sul territorio.
Ovviamente roba del vendor, fatta male e secretata.  Non ne so altro
per ora, e quando lo sapro` non portro` piu` parlarne.

Comunque la memoria a stato solido e` una brutta bestia, una volta il
cliente imputava un baco nel mio buildroot, mesi dopo e` uscito che
era un baco firmware nella chiavetta usb. C'e` un processore la`
sotto, e non sappiamo quello che fa.



Re: Errore in dmesg di "task kworker"

2023-08-30 Per discussione Leandro Noferini


Marco Gaiarin  writes:

> Mandi! Leandro Noferini
>   In chel di` si favelave...
>
>> Non sarà che si sta scassando la SD?
>
> AFAIk no, gli errori sono diversi; anche se mi par di ricordare che le SD
> non hanno alcun sistema di monitoraggio ala-SMART, quindi muoiono di botto e
> basta.

Non me lo dire

:)

> Gli errori che vedi sono segnalazioni del kernel che è 'piantato' a fare
> qualcosa che ci mette molto più del tempo necessario e normale; possono
> essere benigni, se hai uno storage lento o con bassi IOPS ('che fa poche
> cose per volta').

Sicuramente ne fa poche.

Speriamo sia quello.

--
Ciao
leandro



Re: Errore in dmesg di "task kworker"

2023-08-30 Per discussione Leandro Noferini


Giancarlo Martini  writes:

> A leggere l'errore mi sembrava di aver capito che un processo è andato
> in timeout dopo 120 sec. I problemi che ho avuto con le sd si
> manifestavano subito con errori palesi dei programmi che provavano a
> scrivere o a leggere.

Capito.

> Scusa Leandro, forse ho capito male io il senso del messaggio, ma se
> puoi dare il comando dmesg, da remoto, non puoi dare il comando ps aux
> |grep 32752?

Hai ragione, mi sono spiegato male: il fatto è che non controllo
continuamente il server in oggetto e quindi quando sono andato a
controllare il dmesg e quindi a cercare il programma che era indicato
questo era già finito perché il comando che dici te non mi ha riportato
niente.

Grazie un monte!

--
Ciao
leandro



Re: Stranezza dischi Usb

2023-08-30 Per discussione Felipe Salvador
On Mon, Aug 21, 2023 at 04:59:02PM +0200, fran...@modula.net wrote:
> Salve a tutti.
> 
> Rilevo questo stranezza quando collego dischi Usb:
> 
> Caso A)
> Sul monitor Vga del server  è presente la videata di login di Gnome e
> l'operatore, senza fare login, collega un disco esterno Usb formattato
> Ext4.
> Mi collego al server con Ssh e non vedo alcun disco esterno connesso.
> Ovvero, non lo vedo listato in /dev/disk/by-uuid né in
> /dev/disk/by-id.
> 
> Caso B)
> Sul monitor Vga del server è presente la videata di login a caratteri
> e l'operatore, senza fare login, collega lo stesso disco esterno sulla
> stessa porta Usb.
> Mi collego al server con Ssh e vedo che il disco esterno Usb è
> connesso. Ovvero, lo vedo listato sia in /dev/disk/by-uuid che in
> /dev/disk/by-id.
> 
> Non ho pieno controllo sul server remoto: mi devo fidare di quello che
> mi dice l'operatore e quindi ci potrebbero essere anche altre cause.
> 
> Qualcuno si è mai imbattuto in qualcosa di simile?
> 
> Luciano

Buongiorno,
la mia ipotesi è che questo comportamento sia "cortesia" di systemd e
affiliati. Tutto il software che si occupa di gestire le periferiche,
negli anni è cambiato, per cui ora è vincolato all'ambiente in uso e
agli utenti che sono o non sono loggati. Per questo secondo me hai due
comportamenti diversi fra il DE e il terminale.

Saluti

-- 

Felipe Salvador