Fedora Online Forum

Il forum della comunità italiana di Fedora

#1 27-07-2019 16:31:12

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

sistema non pronto per aggiornamento

salve,
oggi pomeriggio ho provato a fare l'aggiornamento dalla 29 alla 30.
Ci sono 61 pacchetti da installare, 2499 da aggiornare e 1 da riportare a versione precedente.
Utilizzo soltanto i dieci repo ufficiali (Modular, Updates, Free e Nonfree).
Alla fine della transazione, cioè dopo aver scaricato tutto l'occorrente, dice:

[[email protected] ~]# dnf system-upgrade reboot
Errore: il sistema non è pronto per gli aggiornamenti
[[email protected] ~]# 

Come faccio a capire il motivo di questo problema?

Le ultime righe leggibili quando è comparso il messaggio per la prima volta indicavano la quantità di megabyte necessari a installare il pacchetto Taldeitali; risalendo indietro nell'elenco, la quantità diminuiva, cioè come se al primo pacchetto il sistema iniziasse a contare lo spazio occorrente e alla fine desse il totale, che è di ca. 2,9 GB.
Penso che di spazio ce ne sia a sufficienza:

[[email protected] ~]$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  29,8G  0 disk 
├─sda1   8:1    0     1G  0 part /boot
├─sda2   8:2    0  24,8G  0 part /
└─sda3   8:3    0     4G  0 part [SWAP]
sdb      8:16   0 465,8G  0 disk 
├─sdb1   8:17   0   953M  0 part 
├─sdb2   8:18   0 423,9G  0 part /home/Aiace/dati
├─sdb3   8:19   0  37,3G  0 part 
├─sdb4   8:20   0     1K  0 part 
└─sdb5   8:21   0   3,7G  0 part 
sdc      8:32   0   2,7T  0 disk 
├─sdc1   8:33   0   939G  0 part 
└─sdc2   8:34   0   1,8T  0 part 
sdd      8:48   0  55,9G  0 disk 
├─sdd1   8:49   0   499M  0 part 
├─sdd2   8:50   0   100M  0 part 
├─sdd3   8:51   0    16M  0 part 
└─sdd4   8:52   0  55,3G  0 part 

dove sda è un SSD di 30 GB dedicato ai files di sistema di Fedora, sdb è un hard disk da mezzo Tera per i dati (cioè le varie cartelle Documenti, Immagini, Scaricati ecc.), sdc è un hard disk da tre Tera dedicato al backup (a cui non riesco più ad accedere, ma questo è un problema completamente diverso), infine sdd è un SSD di 60 GB dedicato a Windows 10 (affinché non faccia casini p.es. sul Grub in condivisione con Fedora, e che carico al boot della macchina unicamente le poche volte di cui ne ho veramente bisogno).

Forse così è più chiaro:

[[email protected] ~]$ su -c'fdisk -l'
Password: 
Disk /dev/sda: 29,8 GiB, 32017047552 bytes, 62533296 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf989adce

Dispositivo Avvio    Start     Fine  Settori  Size Id Tipo
/dev/sda1   *         2048  2099199  2097152    1G 83 Linux
/dev/sda2          2099200 54142975 52043776 24,8G 83 Linux
/dev/sda3         54142976 62531583  8388608    4G 82 Linux swap / Solaris


Disk /dev/sdb: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x17e204aa

Dispositivo Avvio     Start      Fine   Settori   Size Id Tipo
/dev/sdb1   *          2048   1953791   1951744   953M 83 Linux
/dev/sdb2           1953792 890836991 888883200 423,9G 83 Linux
/dev/sdb3         890836992 968959999  78123008  37,3G 83 Linux
/dev/sdb4         968960000 976773119   7813120   3,7G  5 Esteso
/dev/sdb5         968964096 976773119   7809024   3,7G 82 Linux swap / Solaris


Disk /dev/sdc: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x4a08bb44

Dispositivo Avvio      Start       Fine    Settori  Size Id Tipo
/dev/sdc1             194560 1969332223 1969137664  939G 83 Linux
/dev/sdc2         1969332224 5860532223 3891200000  1,8T 83 Linux


Disk /dev/sdd: 55,9 GiB, 60022480896 bytes, 117231408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 72A7BD73-7F3C-4E86-89D1-691EA23E027B

Dispositivo   Start      Fine   Settori  Size Tipo
/dev/sdd1      2048   1023999   1021952  499M Windows recovery environment
/dev/sdd2   1024000   1228799    204800  100M EFI System
/dev/sdd3   1228800   1261567     32768   16M Microsoft reserved
/dev/sdd4   1261568 117229567 115968000 55,3G Microsoft basic data

In ogni caso se non ho indizi per intervenire non saprei davvero da che parte cominciare.

Voi cosa ne pensate? Grazie

Ultima modifica di aiace (27-07-2019 16:40:47)


linuxbox # 408490
Linux user # 479702

Non in linea

#2 28-07-2019 18:03:13

d68qdq8dq
Pinguino avanzato
Registrato: 03-07-2014
Messaggi: 378

Re: sistema non pronto per aggiornamento

Forse ti posso aiutare. Dovresti indicarci la quantità di GB del hard disk come "/" ( root). Ti spiego perchè: quando il sistema deve essere aggiornato ad una versione maggiore è necessario che ci sia abbastanza spazio libero equivalente al numero dei pacchetti da installare. Facciamo un esempio: ammettiamo che abbia circa 8 GB di pacchetti da aggiornare. Devi avere l'equivalente con un certo margine nella partizione root. Il comando dnf system-upgrade può aver scaricato le versioni aggiornate dei pacchetti, ma manca lo spazio libero per proseguire. C'è una soluzione però: rimuovere quel tanto dei pacchetti installati, eccetto quelli necessari al funzionamento del sistema, in modo tale da permettere l'installazione. Lo so, sembra strano, ma funziona. Poi nulla ti vieta di re-installare i programmi che hai rimosso precedentemente con dnf remove...

Non in linea

#3 29-07-2019 00:21:55

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

grazie, d68qdq8dq

Attualmente la directory / (root) risiede sull'SSD da 30 GB (dev/sda), e tramite Gparted ho scoperto che ne sono occupati 22,83 GB su 24,82, cioè risultano liberi poco meno di 2 GB. Pensavo fossero meno, non li avevo mai contati, ma questo risulta.
Perciò è molto probabile che tu abbia ragione.
Inoltre da ieri compare ogni tanto anche un avviso da parte di Dropbox, che segnala l'impossibilità di sintonizzare l'applicazione causa mancanza di spazio sul disco. Quindi anche questo si potrebbe ricondurre a quel problema, ma siccome per me Dropbox è poco importante, non mi ero preoccupato.
In tal caso, non c'è molto da fare. Infatti non saprei né quali pacchetti eliminare, né SOPRATTUTTO QUANTI prima di avere abbastanza spazio libero per procedere all'aggiornamento.

Intravedo tre soluzioni.

(A) Installo ex novo Fedora 30 sull'SSD, piallando tutto quello che contiene. A scanso di equivoci: adesso ci sono boot (1 giga) e swap (4 giga), oltre a root. Come già specificato, i dati stanno su un'altra unità logica (un hard disk SATA da 500 GB), quindi dovrei riuscire a NON fare casini.
Una possibile controindicazione è che al prossimo passaggio di versione, si ripeta il medesimo inconveniente. Questo mi porterebbe a scegliere la soluzione (B):

(B) Compro un SSD da 60 o 120 GB (da sostituire a quello attuale da 30) e ci installo Fedora 30 da zero, senza toccare gli altri dischi. Come quello attuale da 30, che verrebbe rimpiazzato da questo, anch'esso sarebbe dedicato ESCLUSIVAMENTE ai files di sistema (appunto: boot, root e swap).

(C) Copio la root in uso (dev/sda2) su una root che usavo prima di installare l'SSD da 30 GB nella macchina. Questa mi sembra un'operazione più delicata, perché va eseguita su quel disco SATA con i dati.
In dettaglio i 500 GB sono organizzati così:
/dev/sdb1: boot da 1 giga (non più usato)
/dev/sdb2: dati (285,12 GB occupati su 423,85, liberi ancora 138,73 GB) - tuttora in uso
/dev/sdb3: root (18,65 GB usati su un totale di 37,25, ancora liberi 18,61 GB) - non più usato
/dev/sdb4: swap da 3,72 GB giga (non più usato).

Per stare sicuro, potrei azzerare le partizioni 1 e 4 (non più in uso ma rimaste lì inutilmente) e "attaccarle" alla 2, in maniera da ampliarla fino a 42 giga, poi lancio qualcosa come

# cp -r /dev/sda2/ -t /dev/sdb3/

Problema: adesso la root è automaticamente settata su /dev/sda2, è possibile invece fare in modo che il sistema si orienti su /dev/sdb3 ? E come, senza dover reinstallare tutto, che sarebbe la soluzione (A) ?

Insomma: quale pensate sia la soluzione migliore, o meno problematica (tenendo conto che non sono un genio dell'informatica) ?
Grazie a tutti


linuxbox # 408490
Linux user # 479702

Non in linea

#4 29-07-2019 11:37:44

dbfrank
Pinguino avanzato
Da Vittorio V.
Registrato: 03-11-2006
Messaggi: 358

Re: sistema non pronto per aggiornamento

Non so se puo' essere sufficiente, ma ci sarebbe anche la possibilita' di eliminare
/dev/sda3 (swap) ed ampliare /dev/sda2 (root) visto che sono attigue ed hai altra swap
in /dev/sdb5. Modifichi ovviamente /etc/fstab per la nuova situazione.

Ciao Franco

Non in linea

#5 29-07-2019 12:21:50

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

grazie, dbfrank

dbfrank ha scritto:

Non so se puo' essere sufficiente, ma ci sarebbe anche la possibilita' di eliminare
/dev/sda3 (swap) ed ampliare /dev/sda2 (root) visto che sono attigue ed hai altra swap
in /dev/sdb5. Modifichi ovviamente /etc/fstab per la nuova situazione.

in effetti non avevo pensato a modificare /etc/fstab: qualunque sia la strada che prenderò, occorre eseguire il comando

blkid

per ottenere l'UUID delle singole partizioni, riportare nel file quelle eventualmente modificate e subito dopo

systemctl daemon-reload

per renderle effettive.
Questo mi dovrebbe consentire anche di "pilotare" la nuova root, che sia il risultato di un'operazione di copiatura (opzione C) oppure dell'installazione di una nuova scheda SSD, più capiente dell'attuale (opzione B).
Invece nel caso della soluzione (A) rimarrebbe tutto invariato, a meno di cambiare la sede della swap.

Aggiungo soltanto che l'operazione di allargamento della root attuale tramite la swap andrebbe fatta dall'esterno, tramite una live o simile, perché altrimenti il sistema risulterebbe in uso.

E' giusto sin qui il mio ragionamento?

E voi, quale opinione vi siete fatti delle tre opzioni avanzate nel post #3?


linuxbox # 408490
Linux user # 479702

Non in linea

#6 29-07-2019 12:37:24

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

mi rispondo da solo...
ho seguito il consiglio di dbfrank (post #5), anche senza troppe cautele, ma il risultato non è cambiato, poiché mi dice ancora che il sistema non è pronto per gli aggiornamenti.
In effetti 4 giga non era molto, servirà più spazio:

[[email protected] ~]# df -h
File system     Dim. Usati Dispon. Uso% Montato su
devtmpfs        3,9G     0    3,9G   0% /dev
tmpfs           3,9G     0    3,9G   0% /dev/shm
tmpfs           3,9G  1,4M    3,9G   1% /run
tmpfs           3,9G     0    3,9G   0% /sys/fs/cgroup
/dev/sda2        29G   20G    7,6G  72% /
tmpfs           3,9G   15M    3,9G   1% /tmp
/dev/sda1       976M  212M    698M  24% /boot
/dev/sdb2       418G  279G    118G  71% /home/Aiace/dati
tmpfs           792M   16K    792M   1% /run/user/1000

Intanto ho eliminato i pacchetti già scaricati: per quando risolverò, magari ce ne saranno altri più nuovi e potrebbe crearsi qualche confusione.
Attendo con fiducia...

Ultima modifica di aiace (29-07-2019 12:45:44)


linuxbox # 408490
Linux user # 479702

Non in linea

#7 08-08-2019 15:27:56

bebo_sudo
Collaboratore
Da Trento+Trieste
Registrato: 28-02-2011
Messaggi: 2'013
Sito web

Re: sistema non pronto per aggiornamento

Se e' un problema di spazio mancante, potresti rimuovere gli rpm piu' pesanti prima dell'upgrade, e reinstallarli dopo (e' la procedura che faccio anch'io, non avendo tanto spazio sul mio trattorino).
Puoi trovare gli rpm piu' "grossi" con:

# rpm -qa --queryformat '%{size} %{name}\n' | sort -rn |head -n 10

ovviamente se rimuovendone uno ti volesse disinstallare mezzo computer, fermati e chiedi.


devzero.tk - github.com/bebosudo
Quando posti del codice, mettilo nel tag code! (senza spazi)            [ code]così[/ code]

Non in linea

#8 08-08-2019 23:38:57

rossano
Appena sbarcato sul forum
Registrato: 09-10-2013
Messaggi: 84

Re: sistema non pronto per aggiornamento

Prova anche a dare un'occhiata nella directory .thumbnail all'interno della/delle home, non so se è cambiato qualcosa a livello di sistema ma un po' di tempo fa mi occupava qualche GB.
ciao
rossano

Ultima modifica di rossano (08-08-2019 23:40:27)

Non in linea

#9 09-08-2019 12:41:49

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

grazie dei suggerimenti, ma poiché avevo anche altri problemi con F29, ho preferito installare ex novo una F30 a partire da una chiavetta KDE-Live sull'SSD da 60 giga (dove c'era Windows 10).
Se non fosse stato a ridosso di Ferragosto, avrei postato i vari problemucci che ho (e non è escluso che lo faccia a settembre, almeno per quelli più "strani"), ma poiché ho bisogno di utilizzare il PC per lavoro anche in questo periodo "caliente", non potevo rimanere appeso in attesa di soluzioni che avrebbero potuto anche non arrivare.
Adesso l'SSD da 30 giga rimane in secondo piano per quei files e impostazioni che riporterò un po' per volta nella nuova installazione.

@rossano
no, ho controllato anche la cartella nascosta .thumbnail ma è di appena qualche megabyte.
Già che c'ero, ho dato un'occhiata nella /~ anche a quelle di altri programmi che utilizzo di più (del resto non faccio grafica) e mi pare che quella più piena sia quella del programma di posta (Thunderbird).
Questo ha un senso, dato che ci sono archiviati i messaggi ricevuti e inviati da almeno 5-6 anni, ma in tutti i casi si tratta di meno di due giga.
Non credo che il mancato aggiornamento si possa risolvere liberando così poco spazio (che comunque dovrò trasferire sul nuovo SSD, seguendo le specifiche istruzioni fornite sul forum di Mozilla, come feci già in passato con successo).

Riflessione finale: probabilmente anche Fedora (almeno le varianti più affermate, come Gnome e KDE) prende parecchio più spazio su disco rigido di quello che occupava sino a qualche anno fa.
Del resto, ci sono anche spin più leggere e forse meno avide di risorse (Xfce, LXQt ecc.) per chi abbia esigenze diverse.

Buon proseguimento a tutti e grazie ancora


linuxbox # 408490
Linux user # 479702

Non in linea

#10 09-08-2019 13:07:31

QuarkF
Pinguino avanzato
Registrato: 01-04-2013
Messaggi: 270

Re: sistema non pronto per aggiornamento

Una cosa che si potrebbe fare è dare un'occhiata all'output di

# du -h --max-depth 1 /var | sort -h

per vedere quali cartelle occupano più spazio (per esempio, /var/log e /var/cache). Ovviamente, non tutto potrebbe essere impunemente cancellato per fare spazio, ma non è escluso che esistano file non più necessari che possano essere rimossi.
Altra cartella che potrebbe occupare spazio per file temporanei cancellabili è, nella home utente, ~/.cache (a me ~/.cache/mozilla occupa, da sola, mezzo gigabyte).

Ultima modifica di QuarkF (09-08-2019 13:08:35)


Al mondo ci sono 10 tipi di persone: quelle che conoscono la numerazione binaria e quelle che non la capiscono.

Non in linea

#11 15-08-2019 12:56:19

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

grazie molte, rispondo in ritardo perché sono stato fuori,
Adesso ecco l'output:

[[email protected] ~]# du -h --max-depth 1 /var | sort -h
4,0K    /var/account
4,0K    /var/adm
4,0K    /var/crash
4,0K    /var/ftp
4,0K    /var/games
4,0K    /var/gopher
4,0K    /var/local
4,0K    /var/nis
4,0K    /var/opt
4,0K    /var/preserve
4,0K    /var/yp
8,0K    /var/empty
12K     /var/db
12K     /var/kerberos
12K     /var/www
236M    /var/tmp
238M    /var/lib
523M    /var/cache
763M    /var/spool
1,2G    /var/log
2,9G    /var

In effetti c'è qualcosa, ma non saprei bene cosa disinstallare senza combinare casini.
Peraltro, ritengo che il problema sta nel secondo suggerimento che mi hai fornito: infatti la cartella ~/.cache occupa la bellezza di 12,6 GB!
Il responsabile non è solamente Mozilla, sebbene da solo occupi un giga, quindi dovrò fare un lavoro accurato.
Aggiungo che ci saranno pure sottocartelle di programmi disinstallati e che posso tranquillamente cestinare. Ma questo è un lavoro semplice...

Intanto ho provato ad applicare il comando suggerito a questa cartella e ottengo questo output:

[[email protected] ~]# du -h --max-depth 1 /home/Aiace/.cache | sort -h
4,0K    /home/Aiace/.cache/digikam
4,0K    /home/Aiace/.cache/pdfmod
8,0K    /home/Aiace/.cache/abrt
8,0K    /home/Aiace/.cache/akonadi_ical_resource_0
8,0K    /home/Aiace/.cache/calibre
8,0K    /home/Aiace/.cache/gegl-0.4
8,0K    /home/Aiace/.cache/gimp
8,0K    /home/Aiace/.cache/pocl
16K     /home/Aiace/.cache/babl
20K     /home/Aiace/.cache/xreader
20K     /home/Aiace/.cache/yelp
24K     /home/Aiace/.cache/darktable
24K     /home/Aiace/.cache/favicons
32K     /home/Aiace/.cache/ksplashqml
56K     /home/Aiace/.cache/dolphin
72K     /home/Aiace/.cache/spectacle
80K     /home/Aiace/.cache/calligraplan
80K     /home/Aiace/.cache/showfoto
100K    /home/Aiace/.cache/kcmshell5
144K    /home/Aiace/.cache/kwin
188K    /home/Aiace/.cache/ksmserver-logout-greeter
208K    /home/Aiace/.cache/falkon
300K    /home/Aiace/.cache/RawTherapee
304K    /home/Aiace/.cache/qtshadercache
452K    /home/Aiace/.cache/fedoraproject.org
464K    /home/Aiace/.cache/gstreamer-1.0
476K    /home/Aiace/.cache/kscreenlocker_greet
484K    /home/Aiace/.cache/fontconfig
2,6M    /home/Aiace/.cache/mesa_shader_cache
3,1M    /home/Aiace/.cache/kio_http
4,7M    /home/Aiace/.cache/simple-scan
6,9M    /home/Aiace/.cache/kioexec
8,9M    /home/Aiace/.cache/khelpcenter
27M     /home/Aiace/.cache/systemsettings
35M     /home/Aiace/.cache/discover
39M     /home/Aiace/.cache/thunderbird
67M     /home/Aiace/.cache/krunner
80M     /home/Aiace/.cache/plasmashell
237M    /home/Aiace/.cache/chromium
721M    /home/Aiace/.cache/thumbnails
743M    /home/Aiace/.cache/mozilla
2,0G    /home/Aiace/.cache

che mi lascia perplesso: dove sono finiti tutti gli altri giga che mi segnala quando clicco col destro sulla voce "Proprietà" in Dolphin?

Ultima modifica di aiace (15-08-2019 12:57:42)


linuxbox # 408490
Linux user # 479702

Non in linea

#12 15-08-2019 16:08:43

QuarkF
Pinguino avanzato
Registrato: 01-04-2013
Messaggi: 270

Re: sistema non pronto per aggiornamento

Secondo me il contenuto della cartella /home/Aiace/.cache (il contenuto, non la cartella) può essere cancellato senza particolari problemi. Al massimo, quando userai firefox, dovrai ricaricare pagine i cui contenuti erano stati precedentemente memorizzate in cache. Suppongo che altrettanto valga per gli altri programmi. Per quanto riguarda la /var/log, sicuramente si possono cancellare i vecchi files di log, ma per capire quali sono (e quanto spazio occupano), si dovrebbe vedere l'output di

# ls -l /var/log

Ultima modifica di QuarkF (15-08-2019 16:09:31)


Al mondo ci sono 10 tipi di persone: quelle che conoscono la numerazione binaria e quelle che non la capiscono.

Non in linea

#13 15-08-2019 19:57:00

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

grazie!
Riaprirò il thread quando avrò un po' di tempo, dato che questi giorni sono un po' itinerante tra casa e fuori.
Ho anche pensato che le cartelle o i files della cui cancellazione 'indolore' non sono CERTO, posso anche lasciarli, controllando via via se lo spazio occupato diminuisce e alla fine riprovare col passaggio alla nuova versione.
Buon ferragosto, intanto!


linuxbox # 408490
Linux user # 479702

Non in linea

#14 18-08-2019 17:51:49

aiace
Fedora nel sangue
Da Roma
Registrato: 03-11-2005
Messaggi: 1'529
Sito web

Re: sistema non pronto per aggiornamento

QuarkF ha scritto:

Secondo me il contenuto della cartella /home/Aiace/.cache (il contenuto, non la cartella) può essere cancellato senza particolari problemi. Al massimo, quando userai firefox, dovrai ricaricare pagine i cui contenuti erano stati precedentemente memorizzate in cache. Suppongo che altrettanto valga per gli altri programmi. Per quanto riguarda la /var/log, sicuramente si possono cancellare i vecchi files di log, ma per capire quali sono (e quanto spazio occupano), si dovrebbe vedere l'output di

# ls -l /var/log

il mistero si infittisce, dato che problema non sta neanche qui:

[[email protected] ~]# ls -lh /var/log                    
totale 36M
drwxrwxr-x. 2 root   root            4,0K 15 feb  2019 anaconda
drwx------. 2 root   root            4,0K 10 giu 22.39 audit
drwxr-xr-x. 2 root   root            4,0K 31 lug 12.25 blivet-gui
-rw-------. 1 root   root            1,1M 18 ago 18.15 boot.log
-rw-rw----. 1 root   utmp             768 18 ago 18.25 btmp
-rw-rw----. 1 root   utmp            4,0K 21 lug 14.01 btmp-20190806
drwxr-xr-x. 2 chrony chrony          4,0K 19 set  2018 chrony
-rw-------. 1 root   root            1,8K 18 ago 18.15 cron
-rw-------. 1 root   root             24K 24 lug 13.01 cron-20190724
-rw-------. 1 root   root            7,9K 28 lug 03.01 cron-20190728
-rw-------. 1 root   root             12K  6 ago 03.01 cron-20190806
-rw-------. 1 root   root            6,8K 15 ago 12.01 cron-20190815
drwxr-xr-x. 2 lp     sys             4,0K 23 feb 12.47 cups
-rw-------. 1 root   root             295 15 ago 12.53 dnf.librepo.log
-rw-------. 1 root   root            6,4M 24 lug 13.05 dnf.librepo.log-20190724
-rw-------. 1 root   root            6,4M 28 lug 03.25 dnf.librepo.log-20190728
-rw-------. 1 root   root            3,0M  6 ago 02.43 dnf.librepo.log-20190806
-rw-------. 1 root   root            2,2M 15 ago 11.53 dnf.librepo.log-20190815
-rw-------. 1 root   root             35K 18 ago 18.24 dnf.log
-rw-------. 1 root   root            409K 24 lug 13.05 dnf.log-20190724
-rw-------. 1 root   root            2,8M 28 lug 03.25 dnf.log-20190728
-rw-------. 1 root   root            228K  6 ago 02.43 dnf.log-20190806
-rw-------. 1 root   root            100K 15 ago 11.53 dnf.log-20190815
-rw-------. 1 root   root             524 18 ago 18.24 dnf.rpm.log
-rw-------. 1 root   root            4,9K 24 lug 13.05 dnf.rpm.log-20190724
-rw-------. 1 root   root            6,4K 28 lug 03.25 dnf.rpm.log-20190728
-rw-------. 1 root   root            4,0K  6 ago 02.43 dnf.rpm.log-20190806
-rw-------. 1 root   root            1,1K 15 ago 11.53 dnf.rpm.log-20190815
-rw-r-----. 1 root   root               0 15 feb  2019 firewalld
-rw-------. 1 root   root             41K 15 ago 13.20 grubby
-rw-------. 1 root   root             255 18 ago 18.24 hawkey.log
-rw-------. 1 root   root            153K 24 lug 13.05 hawkey.log-20190724
-rw-------. 1 root   root             57K 28 lug 03.25 hawkey.log-20190728
-rw-------. 1 root   root             72K  6 ago 01.12 hawkey.log-20190806
-rw-------. 1 root   root             51K 15 ago 11.53 hawkey.log-20190815
drwx------. 2 root   root            4,0K 17 apr 10.56 httpd
drwxr-sr-x+ 3 root   systemd-journal 4,0K 15 feb  2019 journal
-rw-rw-r--. 1 root   utmp            287K 18 ago 18.27 lastlog
-rw-------. 1 root   root               0 15 ago 12.13 maillog
-rw-------. 1 root   root               0 14 lug 12.26 maillog-20190724
-rw-------. 1 root   root               0 24 lug 13.07 maillog-20190728
-rw-------. 1 root   root               0 28 lug 03.48 maillog-20190806
-rw-------. 1 root   root               0  6 ago 03.24 maillog-20190815
drwxr-x---. 2 mysql  mysql           4,0K  1 ago 22.55 mariadb
-rw-------. 1 root   root            557K 18 ago 18.29 messages
-rw-------. 1 root   root            4,4M 24 lug 13.05 messages-20190724
-rw-------. 1 root   root            1,3M 28 lug 03.34 messages-20190728
-rw-------. 1 root   root            3,0M  6 ago 03.23 messages-20190806
-rw-------. 1 root   root            2,2M 15 ago 12.11 messages-20190815
drwxrwx---. 2 apache root            4,0K 30 lug 13.14 php-fpm
drwx------. 3 root   root            4,0K 10 giu 19.56 pluto
drwx------. 2 root   root            4,0K 20 nov  2018 ppp
drwx------. 2 root   root            4,0K 25 ott  2018 private
-rw-r--r--. 1 root   root            1,1K 21 lug 11.23 README
drwxrwx---. 2 root   apache          4,0K  1 apr 14.52 roundcubemail
drwx------. 3 root   root            4,0K  4 lug 12.01 samba
-rw-------. 1 root   root            3,3K 18 ago 18.27 secure
-rw-------. 1 root   root             30K 24 lug 12.55 secure-20190724
-rw-------. 1 root   root            9,4K 27 lug 17.27 secure-20190728
-rw-------. 1 root   root            9,3K  6 ago 01.12 secure-20190806
-rw-------. 1 root   root             20K 15 ago 11.44 secure-20190815
drwx------. 2 root   root            4,0K 23 giu 11.48 speech-dispatcher
-rw-------. 1 root   root               0 15 ago 12.13 spooler
-rw-------. 1 root   root               0 14 lug 12.26 spooler-20190724
-rw-------. 1 root   root               0 24 lug 13.07 spooler-20190728
-rw-------. 1 root   root               0 28 lug 03.48 spooler-20190806
-rw-------. 1 root   root               0  6 ago 03.24 spooler-20190815
drwxr-x---. 2 root   root            4,0K 15 ago 12.13 sssd
-rw-------. 1 root   root             63K 22 giu 14.46 tallylog
-rw-rw-r--. 1 root   utmp            228K 18 ago 18.25 wtmp
-rw-r--r--. 1 root   root             43K 18 ago 18.20 Xorg.0.log
-rw-r--r--. 1 root   root             43K 15 ago 11.44 Xorg.0.log.old
-rw-r--r--. 1 root   root            2,8K 26 mar 02.48 Xorg.1.log
-rw-r--r--. 1 root   root             38K 15 feb  2019 Xorg.9.log

Tornando al post #12, dentro la cartella nascosta ~/.cache ci sono sottocartelle per ogni programma (Darktable, Thunderbird e così via).
Devo cancellare il contenuto di ognuna di queste, in pratica lasciandole vuote, oppure posso piallare tutto senza incappare in problemi, lasciando semplicemente la cartella generale ~/.cache ?
E comunque ribadisco che anche così facendo, se la matematica non è un'opinione, libero poco più di due giga.

Intanto ho eseguito il comando suggerito da bebo_sudo al post #7:

[[email protected] .cache]# rpm -qa --queryformat '%{size} %{name}\n' | sort -rn |head -n 10
322739677 chromium-libs
290498895 libreoffice-core
226435415 firefox
223451906 thunderbird
217752640 glibc-all-langpacks
192678787 linux-firmware
191643539 java-latest-openjdk-headless
172120428 google-noto-serif-cjk-ttc-fonts
172083132 java-11-openjdk-headless
155896036 digikam
[[email protected] .cache]# cd /
[[email protected] /]# rpm -qa --queryformat '%{size} %{name}\n' | sort -rn |head -n 10
322739677 chromium-libs
290498895 libreoffice-core
226435415 firefox
223451906 thunderbird
217752640 glibc-all-langpacks
192678787 linux-firmware
191643539 java-latest-openjdk-headless
172120428 google-noto-serif-cjk-ttc-fonts
172083132 java-11-openjdk-headless
155896036 digikam

Mi pare che il comando ordini i numeri di bites impegnati dal più grande al più piccolo (e magare c'è pure la possibilità di renderli più leggibili... in K, mega, giga ecc.), comunque ecco qui numeri davvero consistenti...!
Allora seguendo il consiglio di d68qdq8dq (post #2), ad esempio potrei disinstallare Chromium, Libre Office, Firefox e Java, dopodiché provare a fare il passaggio alla versione 30, mella quale reinstallare detti programmi come se nulla fosse...

Ultima modifica di aiace (18-08-2019 18:13:20)


linuxbox # 408490
Linux user # 479702

Non in linea

Piè di pagina