Re: Stranezza dischi Usb
>> Se fai eject non lo vedrai mai. In alcuni casi la periferica viene >> anche disalimentata. in effetti eject -t potrebbe non funzionare $ man eject [...] -t, --trayclose With this option the drive is given a CD-ROM tray close command. Not all devices support this command. [...] Sì ho letto anche la parte "Not all devices support this command" che comunque è inerente al ripristiono del device. In ogni caso è una strada che si può ipotizzare di seguire considerando che su due USB vecchiotti funziona. Certo non ho statistiche sviluppate su vasta scala. > dai il comando "eject /dev/sdc" il device non viene più visto, > pur essendo ancora elencato da lsusb, ma comunque successivamente > puoi riagganciarlo dando il comando eject -t /dev/sdc. interessante, anche interessanti le prove che hai fatto con il login. Però, secondo me, il disco USB non dovrebbe essere caricato prima del login dell'utente. Se si collega qualcuno in SSH dovrebbe essere lui a compiere l'operazione, se ne ha i permessi. Sicuramente è una situazione spuria. Però se sei in remoto non è detto che hai modo di raggiungere fisicamente il sistema. Poi evidentemente si tratta di casi specifici. Anche se hai attivato vnc e puoi fare il login grafico, magari hai dei dischi usb a cui vuoi accedere e se non sbaglio questo mount viene fatto su un path di proprietà dell'utente. > il comando umount, che oltretutto richiede un profilo amministrativo, non è detto, se non erro attualmente l'utente principale non amministratore ha il privilegio per fare il mount/unmount Se non erro dovrebbe essere installato il pacchetto pmount che permette proprio di fare questa operazione La cosa figa del comando "eject -t" è che se funziona, lavora come quando inseerisci il disco e ti viene fatto il mount automatico, senza dovergli specificare il punto di mount e altre cose che decide il sistema. Per esempio, qui si vede che viene messo nel path /media dell'utente. bpxroot@hpebian:~$ findmnt /dev/sdc1 TARGET SOURCEFSTYPE OPTIONS /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro Aggiungo un'altra informazione interessante. Visto che ora c'è systemd si possono usare anche i comandi: per smontare il disco: $ udisksctl unmount -b /dev/sdc1 per togliergli l'alimentazione $ udisksctl power-off -b /dev/sdc Poi non so se sia possibile rifornire l'alimentazione o bisogni toglierlo e rimettere la penna USB. Ho provato anche con udisksctl ma c'è qualcosa che non gli piace :( anche con sudo. bpxroot@hpebian:~$ /usr/bin/udisksctl unmount -b /dev/sdc Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem. bpxroot@hpebian:~$ sudo /usr/bin/udisksctl unmount -b /dev/sdc [sudo] password for bpxroot: Object /org/freedesktop/UDisks2/block_devices/sdc is not a mountable filesystem. 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) bpxroot@hpebian:~$ /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) Continua a esserci: bpxroot@hpebian:~$ findmnt /dev/sdc1 TARGET SOURCEFSTYPE OPTIONS /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro Boh, magari è un problema di questo sistema, ma usando eject tutto il giro funziona, senza dare sudo e usando anche un'altra chiavetta. bpxroot@hpebian:~$ eject /dev/sdc bpxroot@hpebian:~$ bpxroot@hpebian:~$ fdisk -l | grep Disk\ /dev/sdc bpxroot@hpebian:~$ bpxroot@hpebian:~$ findmnt /dev/sdc1 bpxroot@hpebian:~$ bpxroot@hpebian:~$ eject -t /dev/sdc bpxroot@hpebian:~$ bpxroot@hpebian:~$ fdisk -l | grep Disk\ /dev/sdc Disk /dev/sdc: 7,46 GiB, 8004829184 bytes, 15634432 sectors bpxroot@hpebian:~$ findmnt /dev/sdc1 TARGET SOURCEFSTYPE OPTIONS /media/bpxroot/CCCOMA_X64F /dev/sdc1 vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro Ciao Il giorno mar 29 ago 2023 alle ore 23:48 Davide Prina ha scritto: > Beppe Cantanna ha scritto: > > > Paolo Redaelli ha scritto: > > >> Se fai eject non lo vedrai mai. In alcuni casi la periferica viene > >> anche disalimentata. > > in effetti eject -t potrebbe non funzionare > $ man eject > [...] > -t, --trayclose >With this option the drive is given a CD-ROM tray close >command. Not all devices support this command. > [...] > > > > dai il comando "eject /dev/sdc" il device non viene più visto, > > pur essendo ancora elencato da lsusb, ma comunque successivamente > > puoi
Re: Stranezza dischi Usb
Beppe Cantanna ha scritto: > Paolo Redaelli ha scritto: >> Se fai eject non lo vedrai mai. In alcuni casi la periferica viene >> anche disalimentata. in effetti eject -t potrebbe non funzionare $ man eject [...] -t, --trayclose With this option the drive is given a CD-ROM tray close command. Not all devices support this command. [...] > dai il comando "eject /dev/sdc" il device non viene più visto, > pur essendo ancora elencato da lsusb, ma comunque successivamente > puoi riagganciarlo dando il comando eject -t /dev/sdc. interessante, anche interessanti le prove che hai fatto con il login. Però, secondo me, il disco USB non dovrebbe essere caricato prima del login dell'utente. Se si collega qualcuno in SSH dovrebbe essere lui a compiere l'operazione, se ne ha i permessi. > il comando umount, che oltretutto richiede un profilo amministrativo, non è detto, se non erro attualmente l'utente principale non amministratore ha il privilegio per fare il mount/unmount Se non erro dovrebbe essere installato il pacchetto pmount che permette proprio di fare questa operazione Aggiungo un'altra informazione interessante. Visto che ora c'è systemd si possono usare anche i comandi: per smontare il disco: $ udisksctl unmount -b /dev/sdc1 per togliergli l'alimentazione $ udisksctl power-off -b /dev/sdc Poi non so se sia possibile rifornire l'alimentazione o bisogni toglierlo e rimettere la penna USB. 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 distribuite 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: Compilazione kernel con modulo binder_linux e waydroid.
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 qualche parametro e rispondere alle domande per impostazione dei parametri nuovi. ti faccio un riassunto di quello che faccio io per compilare una nuova versione di Linux prendendo il .config Debian della stessa versione compilata ed applicando le mie impostazioni personalizzate contenute in imposta_config.sh $ cd ~/src # apt install build-essential fakeroot rsync git # apt build-dep linux $ mv linux-source linux-sourceold <- se serve $ tar Jxvf /usr/src/linux-source-... <- se serve (se non è cambiata versione rispetto ultima compilazione) $ ln -sf ~/src/linux-source-... linux <- se serve (se è cambiata versione rispetto ultima compilazione) $ cd linux $ cp /boot/config-... .config $ ../imposta_config.sh $ time make -j 5 bindeb-pkg # cd ~/src # apt install ./linux-image... ./linux-header... ./linux-libc-dev... il file imposta_config.sh contiene righe come le seguenti: # disabilita le informazioni di debug scripts/config --disable DEBUG_INFO scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT scripts/config --disable DEBUG_INFO_BTF scripts/config --disable DEBUG_INFO_BTF_MODULES # disabilita la firma di Linux (altrimenti solo un certificato valido permette la sua compilazione) #scripts/config --disable MODULE_SIG scripts/config --set-str SYSTEM_TRUSTED_KEYS "" # imposta il postfisso al Linux compilato scripts/config --set-str LOCALVERSION "-dp-$(date +%Y%m%d)" [...] se usi questa modalità e copi il .config della versione da cui vuoi partire dovresti ottenere una versione Linux eseguibile. Il mio consiglio è però prendere il .config Debian della versione che vuoi ricompilarti e applicare le tue modifiche... è meglio se ti crei un file .sh come ho fatto io che fa le impostazioni in automatico ogni volta che vuoi ricompilarti una nuova versione di Linux 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 distribuite 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: telecamere ip
Un'alternativa è utilizzare telecamere yi (xiaomi) con il firmware open source yi-hack. Sono solo WiFi purtroppo ma puoi sbloccare un sacco di opzioni cloudless, hanno una buona visione notturna e sono nel budget. Andrea Il lun 28 ago 2023, 15:01 Giuliano Curti ha scritto: > Chiedo scusa per la fretta, sbagliato destinatario :-( > > Approfitto per aggiungere: > > 1) motion e motionPlus di motion-project > > 2) non necessitano di accessori per la connessioni, basta un cavo ethernet > e l'alimentazione; se le prendi POE (non costano di più) basta il cavo > > 3) anch'io mi riferivo a telecamere esterne. > > > -- Forwarded message - > Da: Giuliano Curti > Date: lun 28 ago 2023, 14:55 > Subject: Re: telecamere ip > To: Luca Sighinolfi > > > Il lun 28 ago 2023, 14:23 Luca Sighinolfi ha > scritto: > >> Buongiorno a tutti, >> > > Ciao Luca, > > forse sono un po' OT. >> Nel caso mi perdonerete e magari potete scrivermi in privato. >> > > Rispondo qui, nel caso ci bannano in due :-) > > Ho un banale impiantino di video sorveglianza con 3 telecamere ip, che >> registrano su un desktop con Debian. >> E' giunto il momento, dopo 9 anni, di cambiare le telecamere e quindi >> chiederei un consiglio a riguardo. >> > > Non sono consigli i miei, solo condivisione di esperienze. > > In particolare non vorrei fare l'errore di acquistare telecamere che >> sono accessibili solo da IE, come quelle attuali. >> > > Io ho preso 4 telecamere di produttori diversi e da rivenditori diversi, > tutte di rete; le ultime le ho prese POE: semplifica di molto il cablaggio. > > Tutte gestibili da Linux (Raspberry Pi OS); l'unico problema è individuare > l'URL di connessione; al riguardo si è rivelato molto utile il sito > ispyconnect.com? .org? (Se non lo individui guardo meglio). > > E non vorrei nemmeno acquistare un DVR. >> Avendo un PC sempre acceso mi appoggerei a quello, con semplici script >> per la registrazione dei video (zoneminder a suo tempo non sono riuscito >> a farlo andare...). >> > > Io sto usando motion; ho ancora qualche difficoltà a gestire gli alarm, > troppi falsi positivi, ma il sistema sembra funzionare. > > Volevo provare la nuova versione motionPlus, ma banali problemi di > configurazione della rete locale (problemi che non ho ancora capito e > risolto, magari vi romperò l'anima) me lo hanno impedito; dovrebbe avere il > vantaggio di impiegare una sola porta per tutto e non 1 porta + 1 per > camera. > > Chiaramente il budget non è infinito, ma neppure chiedo che costino meno >> di 50€ ciascuna. >> > > Prezzi da €30 a €65 (se vuoi ti posso dire in pvt marche e modelli). > > Grazie per i suggerimenti >> Ciao >> -- >> Luca Sighinolfi >> > > Ciao, se metti in circolo qui o anche in pvt le tue esperienze mi fa > piacere, > Giuliano > > >
Re: Errore in dmesg di "task kworker"
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.
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').
--
L'unico metodo naturale per arrestare la caduta dei capelli
e` il pavimento. (Marco d'Itri)
Re: Connection refused
Hai provato a vedere se il server è in ascolto su quella porta o se la medesima viene utilizzata e nel caso da chi? Per questo io uso lsof ma si può fare anche con altri programmi -- Giancarlo Martini http://www.giancarlomartini.it http://www.linkedin.com/in/giancarlo-martini Il mar 29 ago 2023, 14:29 Piviul ha scritto: > Ciao a tutti, è da un po' di tempo che improvvisamente su un server di > sviluppo postgres ha smesso di rispondere dall'esterno. In locale ci > accedo tranquillamente. Quando si tenta di connettersi restituisce: > > psql: error: connection to server at "server" (192.168.64.22), port 5432 > failed: Connection refused > Is the server running on that host and accepting TCP/IP connections? > > Ovviamente ho controllato e ricontrollato il pg_hba.conf ma in effetti > non dovrebbe centrare, i messaggi restituiti in quel caso sono altri: > https://www.postgresql.org/docs/current/client-authentication-problems.html > > Sembra che ci sia un qualche blocco prima di postgres, come un firewall > che non mi risulta però sia installato: > > # iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > > Non so, a qualcuno viene in mente qualcosa per debuggare la cosa? > > Piviul > > >
Re: Connection refused
Controll;ato che il firewall non sia lato client ? On Tue, 29 Aug 2023, Piviul wrote: Ciao a tutti, è da un po' di tempo che improvvisamente su un server di sviluppo postgres ha smesso di rispondere dall'esterno. In locale ci accedo tranquillamente. Quando si tenta di connettersi restituisce: psql: error: connection to server at "server" (192.168.64.22), port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? Ovviamente ho controllato e ricontrollato il pg_hba.conf ma in effetti non dovrebbe centrare, i messaggi restituiti in quel caso sono altri: https://www.postgresql.org/docs/current/client-authentication-problems.html Sembra che ci sia un qualche blocco prima di postgres, come un firewall che non mi risulta però sia installato: # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Non so, a qualcuno viene in mente qualcosa per debuggare la cosa? Piviul -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it tel:+393287329225
Re: samba e vecchi client
Mi permetto una soluzione ardita: taglia la testa al toro e prova https://github.com/winfsp/sshfs-win
Re: Connection refused
scusate, ho trovato, mi ero dimenticato che tempo fa avevo cambiato l'ip del server e andava quindi aggiornato il listen_address in postgresql.conf :( Piviul On 8/29/23 14:30, Leonardo Boselli wrote: Controll;ato che il firewall non sia lato client ? On Tue, 29 Aug 2023, Piviul wrote: Ciao a tutti, è da un po' di tempo che improvvisamente su un server di sviluppo postgres ha smesso di rispondere dall'esterno. In locale ci accedo tranquillamente. Quando si tenta di connettersi restituisce: psql: error: connection to server at "server" (192.168.64.22), port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? Ovviamente ho controllato e ricontrollato il pg_hba.conf ma in effetti non dovrebbe centrare, i messaggi restituiti in quel caso sono altri: https://www.postgresql.org/docs/current/client-authentication-problems.html Sembra che ci sia un qualche blocco prima di postgres, come un firewall che non mi risulta però sia installato: # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Non so, a qualcuno viene in mente qualcosa per debuggare la cosa? Piviul -- Leonardo Boselli Firenze, Toscana, Europa http://i.trail.it tel:+393287329225
Connection refused
Ciao a tutti, è da un po' di tempo che improvvisamente su un server di sviluppo postgres ha smesso di rispondere dall'esterno. In locale ci accedo tranquillamente. Quando si tenta di connettersi restituisce: psql: error: connection to server at "server" (192.168.64.22), port 5432 failed: Connection refused Is the server running on that host and accepting TCP/IP connections? Ovviamente ho controllato e ricontrollato il pg_hba.conf ma in effetti non dovrebbe centrare, i messaggi restituiti in quel caso sono altri: https://www.postgresql.org/docs/current/client-authentication-problems.html Sembra che ci sia un qualche blocco prima di postgres, come un firewall che non mi risulta però sia installato: # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Non so, a qualcuno viene in mente qualcosa per debuggare la cosa? Piviul
Re: Errore in dmesg di "task kworker"
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. 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? -- Giancarlo Martini http://www.giancarlomartini.it http://www.linkedin.com/in/giancarlo-martini Il lun 28 ago 2023, 21:33 Leandro Noferini ha scritto: > Giancarlo Martini writes: > > > sei riuscito a vedere a chi appartengono ? > > pid:32752 ppid:2 > > No, è un server remoto e non ce l'ho sotto mano se non da remoto per > l'appunto. > > [...] > > Non sarà che si sta scassando la SD? > > Comunque per ora non vedo più niente del genere. > > -- > Ciao > leandro > >
Re: samba e vecchi client
Alla fine mi sono arreso, ai client xp si accede con utente locale, non li ho rimossi dal dominio e per potersi connettere come utente locale mi sono inventato un mezzo accrocchio... Grazie a tutti Piviul
