apt upgrade hibaüzenettel leáll

 ( freeroute | 2018. november 18., vasárnap - 0:25 )

Segítség jól jönne most.
Hardver: Rasberry Pi 3
OS: Debian base distro.

A gondom az, hogy az "apt update && apt upgrade" parancsot kiadva a csomagok ugyan letöltésre kerülnek, de a telepítés leáll "Nincs elég lemezterület" hibával.
Van elég hely a telepítésre. Valamikor az év elején került telepítésre az operációs rendszer, eddig ilyennel nem találkoztam.

df -lh kimenete:

root@Helium-XR09:~# df -lh
Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
/dev/root 30G 14G 15G 50% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 463M 38M 426M 9% /dev/shm
tmpfs 463M 13M 451M 3% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
tmpfs 93M 16K 93M 1% /run/user/0

uname -a
Linux Helium-XR09 4.4.50-v7 #1 SMP Fri Apr 21 01:18:29 CDT 2017 armv7l GNU/Linux

Amit észrevettem még, hogy "fdisk -l" 16 db /dev/ramx-et mutat.

Van ötletetek, mi lehet a hiba oka?
Ujraindítás nem segített.

Köszönöm előre is.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem lehet, hogy az inode-ok fogytak el?

df -i

mit mond?

Ami még eszembe jutott, hogy ha esetleg az apt valamit, ami sok, a /tmp-be tesz, ami tmpfs, azaz RAM+swap, akkor az könnyen elfogyhat.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

root@Helium-XR09:~# df -i
Fájlrendszer Inode-ok IFogl ISzab. IFo.% Csatol. pont
/dev/root 1923040 1923034 6 100% /
devtmpfs 117368 372 116996 1% /dev
tmpfs 118452 21 118431 1% /dev/shm
tmpfs 118452 497 117955 1% /run
tmpfs 118452 4 118448 1% /run/lock
tmpfs 118452 15 118437 1% /sys/fs/cgroup
tmpfs 118452 21 118431 1% /run/user/0

"apt-get upgrade"-re: 822 MB lenne csak.

420 frissített, 0 újonnan telepített, 0 eltávolítandó és 82 nem frissített.
Letöltendő adatmennyiség: 822 MB/835 MB.
A művelet után 10,4 MB lemezterület kerül felhasználásra.

Telepíti?
I/n

Ezt kapom(részlet):
Nem lehet megnyitni a(z) /var/cache/apt/archives/partial/libqt5designer5_5.11.2-4_armhf.deb fájlt - open (28: Nincs több hely a lemezen) [IP: xxx]
Hiba:35 http://kali.download/kali kali-rolling/main armhf libqt5sql5 armhf 5.11.2+dfsg-4
Nem lehet megnyitni a(z) /var/cache/apt/archives/partial/libqt5sql5_5.11.2+dfsg-4_armhf.deb fájlt - open (28: Nincs több hely a lemezen) [IP: xxx]

Jo volt a tipp, elfogyott az inode...

+1

A df -i kimenetét el is kell ám olvasni! ;) Gondolom, sok apró file van, s már nincs hova bejegyezni a nyilvántartásba az újabbakat. Van ugyan hely a háttértáron, csak a nyilvántartásban fogytak el a bejegyzési lehetőségek. Több inode-ra kell formázni a filerendszert.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egyébként a tune2fs -I paramétere a barátod, de nem tudom, online, felcsatolt filerendszernél lehet-e csinálni. Ha nem, akkor egy másik linuxos gépen kell alkalmaznod. A leírás szerint csak rendben lévő fs-en szabad elindítani, tehát előbb kell egy e2fsck is.

Amit olvasnod kell:

man tune2fs


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszönöm. Valóban figyelmetlen voltam, a "df -i" kimenetét elnéztem. Időközben utána olvastam.

Újraformázni csak legvégső esetben szeretnék.
Megpróbálom megtalálni mi az ami teleszemetelte a log file-okat (én erre gyanakszom).

Ezt találtam:
https://www.ivankuznetsov.com/2010/02/no-space-left-on-device-running-out-of-inodes.html
https://www.ctrl.blog/entry/how-to-all-out-of-inodes

Ayértén megnézném azt is, hogy miért van majd 2 milliónyi file azon a 30Gs filerendszeren... Akárhogy is nézem, ez szerintem jóval több mint aminek ott kéne lennie. Esetleg valami nem szemeteli a /tmp-t 0 byte-os fileokkal?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

"for i in /var/cache/*; do echo $i; find $i |wc -l; done" kimenete 1.5 millió file-t adott ki.

"rm -rf *" parancs output: "Argument list too long." volt a válasz.

"find . -type f -delete" parancs talán megoldja. Most törlöm épp a file-okat.

Mi generálhatta ezt a rengeteg file-t? Van ötletetek?

Mondjuk törlés ELŐTT belenézhettél volna...

Mondjuk konkrét adatok nélkül nehéz.. Mit futtatsz azon a Raspin? Meg a /var/cache alatt melyik mappában volt(ak) a legtöbb file(ok)?
Látatlanba tipp: Ha van Apache akkor nézd meg, hogy a mod_cache_disk is be van e rántva, mert az tud ilyet..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A /var/cache/fontconfig/ mappa volt tele file-okkal. Innen töröltem a file-okat. A /var/cache/ alatti többi könyvtárhoz nem nyúltam. Apache2 server fut rajta. Köszönöm ellenőrzöm.

Akkor ott valami X-et használó progi lesz a ludas.. Ne Apache körül nézelődj..
Talán egy lsof /var/cache/fontconfig/ tud iránymutatást adni, hogy mi használ ennyi fontot
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Fontconfig-nak volt egy bug-ja mostanában...
Asszem ez volt:
* debian/patches/do_not_remove_uuid.patch: Revert the cleanup of the .uuid
files, this is causing multiple issues and it's not even fixing #897040,
from upstream (Closes: #909728,#909841,#909818)

--
Debian Linux rulez... :D
RIP Ian Murdock