Ciao, non cosa fa il tuo pc, d'altronde ho scritto cosa faccio io, non cosa succede sul tuo pc e sono anche sicuro che tu prima di fare un'affermazione tanto netta come un anatema tipo "*Se fai eject non lo vedrai mai*" sicuramente l'hai verificata. Sui tuoi pc.
Però quello che ho riportato nella precedente mail non è frutto di ipotesi ma è il risultato di comandi dati e output riportato così come è uscito. E ti dico che sia sul mio HP ProBook 450 G4, sia sul Compaq 610, entrambi con Debian trixie, se hai una chiavetta usb con queste caratteristiche "ID 0951:1624 Kingston Technology DataTraveler G2" vista come /dev/*sdX* dove X è la lettera identificativa del device a blocchi, in questo caso /dev/sdc e 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*. Riporto nuovamente il test. Elenco dei dispositivi visti sul bus usb: :~$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 04f2:b595 Chicony Electronics Co., Ltd HP HD Camera *Bus 001 Device 007: ID 0951:1624 Kingston Technology DataTraveler G2* Bus 001 Device 002: ID 03f0:134a HP, Inc Optical Mouse Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Qui il disco */dev/sdc* si vede: :~$ fdisk -l | grep ^Disk\ /dev/sd Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors Disk /dev/sdb: 465,76 GiB, 500107862016 bytes, 976773168 sectors *Disk /dev/sdc: 3,73 GiB, 4008706048 bytes, 7829504 sectors* eseguo il comando eject /dev/sdc: :~$ eject /dev/sdc :~$ e il disco /dev/sdc non si vede più: :~$ fdisk -l | grep ^Disk\ /dev/sd | grep sdc :~$ ma il bus usb vede ancora il dispositivo: :~$ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 8087:0a2a Intel Corp. Bluetooth wireless interface Bus 001 Device 003: ID 04f2:b595 Chicony Electronics Co., Ltd HP HD Camera Bus 001 Device 007: *ID 0951:1624 Kingston Technology DataTraveler G2* Bus 001 Device 002: ID 03f0:134a HP, Inc Optical Mouse Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub A questo punto se voglio riagganciarlo vedo che posso fare così: :~$ eject -t /dev/sdc :~$ e funziona, succede proprio quello che ho scritto, il disco torna visibile: :~$ fdisk -l | grep ^Disk\ /dev/sd | grep sdc Disk /dev/sdc: 3,73 GiB, 4008706048 bytes, 7829504 sectors Fenomeno che poco si sposa con la tua frase "*Se fai eject non lo vedrai mai*". E invece si vede di nuovo.Succede sempre. Su due pc diversi con due dischi usb diversi. Magari sui grandi numeri può anche succedere che "non si vedrà mai" ma al momento la mia esperienza dice che si vede. Come avrai osservato questi comandi sono stati dati senza l'utilizzo del sudo, come se operassi da ambiente grafico pur essendo su un terminale in ssh. Secondo me è abbastanza interessante saperlo perché può capitare che magari da una sessione vnc per sbaglio sganci il disco usb e poi non sai come riagganciarlo senza andare direttamente in loco. Inoltre come è noto, il comando umount, che oltretutto richiede un profilo amministrativo, semplicemente sgancia il dispositivo dal mount point sul filesystem, senza variare minimamente la possibilità di gestirlo con il tool fdisk. In altre parole, se fai umount continui a vedere ancora /dev/sdc. umount e eject, anche se forse non sembra fanno cose diverse. Quindi, so che devo fare così se voglio rimuovere il disco dall'elenco dei device /dev/sdX, almeno sui miei pc. Sui tuoi non lo so. E dato che a me funziona, ho pensato di condividere la cosa, che poi non è tanto strana, infatti se guardiamo il relativo help di ject vediamo: ~$ eject -h | grep ^\ -t -t, --trayclose close tray Che evidentemente riferito a un lettore ottico vuol dire che prova a chiudere il cassettino, mentre applicato a un dispositivo a blocchi come una chiavetta usb evidentemente corrisponderà a riattivarlo. Ti confesso che non ho letto il sorgente di eject, ma ho visto che qui funziona così. Tra l'altro questa chiavetta avrà almeno 10 anni e non credo implementi tecnologie sperimentali. Ma comunque la mia mail voleva dare un contributo nel rispondere alla domanda iniziale fatta da fran...@modula.net, in quanto mettendomi in una condizione simile al suo *caso A)* ho potuto far comparire il device in /dev/disk/by-uuid senza che nessuno facesse il login nell'ambiente grafico, ricadendo quindi nella situazione simile al *caso B)*, ottenendo il controllo del disco usb e il mount automatico da ssh variando le impostazioni del file /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy senza che nessuno accedesse sul DE con una sessione locale. L'unico dubbio che mi resta è relativo al device da puntare con il comando ejec -t /dev/sdX, ma probabilmente dmesg potrebbe dare indizi in merito. Ciao Il giorno gio 24 ago 2023 alle ore 19:38 Paolo Redaelli < paolo.redae...@gmail.com> ha scritto: > Se fai eject non lo vedrai mai. In alcuni casi la periferica viene anche > disalimentata. > Devi fare un umount semplice. > Dopo un eject l'unico modo per rivedere la periferica è scollegarla e > ricollegarla fisicamente > -- > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. > -- *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.Utilizzate alternativamente documenti in formato OpenDocument.* http://en.wikipedia.org/wiki/OpenDocument <http://en.wikipedia.org/wiki/OpenDocument> http://it.wikipedia.org/wiki/OpenDocument **http://www.documentfoundation.org/ * *https://it.libreoffice.org/
