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:

[root@localhost ~]# dnf system-upgrade reboot Errore: il sistema non è pronto per gli aggiornamenti [root@localhost ~]#

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:

[Aiace@localhost ~]$ 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:

[code][Aiace@localhost ~]$ 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[/code]

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

Voi cosa ne pensate? Grazie

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…

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).

© 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

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

grazie, dbfrank

[quote=dbfrank]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.[/quote]

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?

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:

[root@localhost ~]# 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…

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.

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

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 https://forum.mozillaitalia.org/index.php?board=32.0, 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

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).

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

[root@localhost ~]# 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:

[root@localhost ~]# 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?

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

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!

[quote=QuarkF]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:

[root@localhost ~]# 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:

[root@localhost .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 [root@localhost .cache]# cd / [root@localhost /]# 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…