Ubuntu crede în mod incorect 100% din „/” folosit, toate kernel-urile vechi și fișierele mari eliminate, nu va finaliza actualizarea sau nu va porni

În timpul unui upgrade, am primit un mesaj de eroare care spunea că mai am mai puțin de 1 GB pe partiția rădăcină... din păcate, a trebuit să-mi închid mașina înainte de a putea investiga.

Acum, am primit acest mesaj de eroare de la linia de comandă de salvare:

După câteva citite, mi-am șters toate nucleele vechi și fișierele mari găsite în „/” . Cu toate acestea, indiferent cât de mult șterg, primesc aceeași eroare de mai sus.

De ce Ubuntu nu recunoaște spațiul suplimentar eliberat pe care l-am creat? Am eliberat cu ușurință 2 giga de spațiu, dar primesc această solicitare constantă pentru 529M

chiar am alergat:
#sincronizare

Fără noroc

Informații suplimentare Sunt pe Ubuntu 20.04, mașină Acer Aspire 5 55g și după comentariile de mai jos:

Ei bine, aici este problema ta:

Filesystem Size Used Avail Use% Montat pe
/dev/nvme0n1p5 92G 87G 0 100% /

Ta / locatia este plina. 5G de stocare care pare neutilizat este rezervat de sistem pentru înregistrare și alte funcții de bază, ceea ce înseamnă că nu îl puteți folosi fără a schimba spațiul de rezervă pentru sistemul de fișiere... puternic descurajați când vorbiți despre /.

Va trebui să aflați unde este folosit tot spațiul de stocare și să mutați/ștergeți fișierele în consecință. Locul tipic pentru a începe să cauți este /var/log. Aici puteți (probabil) să mutați/ștergeți o parte din arhivate .gz fișiere. Asta ar putea elibera un pic de spațiu.

Alternativ, puteți utiliza du pentru a identifica unde utilizați cel mai mult spațiu de stocare:

sudo du / -h --max-depth=1

Acest lucru vă va oferi ceva care arată astfel:

8.0K/media
84K/rădăcină
4.0K /min
1,7 M / alergare
16K /pierdut+găsit
300K /acasa
201M /porționare
17G /var
8,1 milioane /etc
16K /dev
22M /opt
4.0K /cdrom
0 /sys
4.0K /srv
76K /tmp
2.2G/snap
0 /proc
65G/date
3.5G /usr
123G /

De aici, puteți edita / parte a du comandă pentru a identifica directoare specifice care pot folosi mult mai mult spațiu de stocare decât ați dori.

Am rezolvat problema, dar nu am răspuns la întrebare și am creat un nou mister.

1. Cum am rezolvat problema: Din shell-ul de salvare al kernel-ului meu implicit ubuntu 5.11~~ am rulat:

    # du / -h --max-depth=1
   

   Am observat că folderul meu /media cântărea la 36 GB, ceea ce ar trebui să fie imposibil deoarece nu aveam dispozitive externe (usb) conectate. În primul rând, am crezut că sunt monturi vechi blocate cumva pe loc și am încercat demontați /media/USB, dar mi s-a spus că nu au fost montate.. deoarece acestea sunt dispozitive externe și datele mele sunt în siguranță, am continuat și le-am eliminat.

    # rm -r /media/usb
   

   Acum mașina este fericită. Am putut să pornesc și să-mi completez actualizarea/actualizările.

2. Dar întrebarea mea inițială rămâne. Chiar și cu usb-ul montat „fantomă” prezent, am șters în continuare peste 2 giga de date, în timp ce ubuntu dorea doar 529 mb, ceea ce am șters ar fi trebuit să fie mai mult decât suficient pentru a finaliza actualizarea și a porni sistemul? De ce Ubuntu nu a recunoscut că ștergeam elemente?

   obisnuiam lsof | grep DEL și nu a returnat nicio valoare... așa că încă nu am o explicație pentru ce spațiul pe care l-am șters nu a fost recunoscut.

3. Și noul mister pe care se pare că l-am creat este „De ce monturile „fantomă” ale USB-ului meu consumau 36 GB de spațiu sub „/”? Chiar aș dori să știu asta. Ar putea folosirea TimeShift să creeze cumva monturile „fantomă” ?

În orice caz, răspunsul lui @matigo a fost parțial util, deși nu răspunde la întrebare.