Először megemlítem a probléma történelmének történetét, majd a megoldásának módját.
A csapatom a Sony Vaio m120AL netbook hogy körülbelül 3 hosszú évem van egy 320 GB-os merevlemezzel, ahol együtt élnek A windows 7, Chakra , a munkám partíciója Xubuntu 12.04, a cserepartíció, a / home partíció és egy további információs partíció, amellyel információkat osztok meg Windows-t.
Ezen okokból kifolyólag mindkét rendszerem gyökérpartíciói a legtöbb szabvány szerint meglehetõsen kicsi (egyenként kb. 6 GB), de soha nem okoztak problémát, mivel elegendõek az összes szükséges csomaghoz.
Most, belépve a konkrét helyzetbe, néhány nappal ezelőtt néhány frissítést alkalmazva Xubuntu (amely tartalmazott egy új kernelt) Úgy látom, hogy a frissítéskezelő hibát mutat, mondván, hogy megpróbálja telepíteni a linux-image-3.2.0-51-generic programot, de függősége a linux-headers-3.2.0-51 nem lesz telepítve, részletesen átnézem a hibát és észreveszem, hogy a dpkg panaszkodik, hogy nincs szabad hely.
A hiba mondott valamit erről a stílusról, bár nem azonos, mert nem írtam le:
nem sikerült létrehozni a /usr/src/linux-headers-3.2.0-43/arch/xtensa/include/asm/coprocessor.h.dpkg-new 'fájlt (feldolgozás közben.) -3.2.0-43 / arch / xtensa / include / asm / coprocessor.h '): Nincs hely az eszközön
Egy korábbi alkalommal ugyanez történt velem, de azért történt, mert több régi kernelt hagytam felhalmozni anélkül, hogy törölném őket, de ezúttal megnézem, és gyakorlatilag 600 Mb áll rendelkezésemre a Conky abból, amit nem értek, de meg kell erősítenem, hogy lehet-e hiba abban, hogyan konfiguráltam, vagy hasonló futtatom a df-h:
Tehát nem tévedek, és ez több, mint elegendő hely a frissítés végrehajtására (a Xubuntuval való együttlétem óta eltelt hosszú évben sokszor így tettem), egyébként csinálok egy sudót apt-tiszta a letöltött csomagok megtisztításához és próbálkozzon újra, de ugyanazokkal az eredményekkel.
Még mindig furcsának tartom, de különben is megpróbálok kimozdulni a / általam használt ikontémákból, amelyeket mindig is módosítottam (Faenza y Felébresztett), hogy több helyet szabadítson fel, és így végre sikerül elvégeznie a frissítést, folytatva újra a / helyre való visszatérést.
Azonban az a gondolat maradt a fejemben, hogy az ügynek máshová kell mennie, de nem tudom, melyik. Néhány órával később, amikor megpróbálok néhány extra csomagot telepíteni, újra előjön a fent említett hiba, és ismét volt elég hely a tartaléknak, ezért kutatom.
Egy internetes keresés több témához vezet a fórumokon ubuntu-is, de egyes egyének válasza mindig ugyanaz: nincs elegendő hely fájlok törléséhez vagy a gyökérpartíció kibővítéséhez, de észrevettem valami közöset a megtalált különböző szálakban, mindig a gyökérpartíciónak volt szabad helye, de Hasonló volt az enyémhez (~ 600-900 Mb), és a partíció mérete soha nem haladta meg a 10 Gb-ot, így végül meggyőztem magam arról, hogy a problémának másnak kell lennie, és így jutottam el a bejegyzés címéig ezt oldalon, a probléma az, hogy a gyökérpartíció az inódok 100% -át használta.
Az inodes használata a paranccsal látható df -i:
És most jön a magyarázat.
Az inódok Dennis Ritchie szavai:
Tárgymutató, a fájlrendszer kissé szokatlan felépítése miatt, amely a fájlokhoz való hozzáférés információt lapos listaként tárolta a lemezre, eltekintve a könyvtárak összes hierarchikus információjától
és ezért előfordulhat, hogy egy adott fájlrendszer számára még van szabad hely a fájlok tárolására, de az indexeléshez nincsenek inode-ok, mert sok fájl van a rendszerben, ezért újak nem hozhatók létre.
A lényeg az, hogy az inódok száma egy partícióban EXT4 nem módosítható (vannak más típusú rendszerek is, mint pl JFX o XFS ahol ez nem korlátozás, mert dinamikus), akkor ez egy rögzített szám, amelyet akkor számolunk ki, amikor a partíciót az mkfs.ext4 alkalmazással hozzák létre, méretének megfelelően, inode-onként bájtok arányával, a /etc/mke2fs.conf.
A rendszer telepítésekor általában az alapértelmezett beállításokat kell használni, amelyek tartalmaznak egy inode = 16384 relációt, amely kis partíciók esetén túl nagy lehet, és nem hozhat létre eléggé (mint az én esetemben). A változtatás egyetlen módja a partíció létrehozása / formázása és az opcióval történő megadása -i.
Ez azonban nem volt lehetőség számomra, mivel már említettem, hogy az inodes a meglévő fájlok számához kapcsolódik, ezért használja a következő bash parancsfájlt: stackoverflow és hogy az Ön által korábban említett oldalon van összekapcsolva, hogy megtalálja, mely könyvtárak voltak a gyökérpartícióban további fájlokkal:
#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$
Ez a következő eredményt adja:
A bal oldalon megjelenő szám jelzi a fájlok számát, az útvonal pedig a hozzá tartozó könyvtárat, az egyik sor alatt pedig a / var / lib / dpkg / info könyvtár jelenik meg, de mint mindig itt is kitisztítom a csomagjaimat, nincs mit tenni .
Ha azonban két problémát felismerek, az elsőt és bár a catpura nem onnan jön elő, még több bejegyzés tartalmazza az ikonokat Felébresztett, tehát igen vagy igen kell mozgatnom őket, ez is magyarázza, hogy mikor tettem, frissíthettem a csomagokat, mivel sok inódot felszabadítottam a gyökérpartícióból, amikor áthelyeztem őket, de a probléma visszatért, amikor áthelyeztem őket.
Másodszor, a következő nagyobb számú bejegyzés több régi kernel fejlécéhez kapcsolódik, és tisztában vagyok azzal, hogy az az eljárás, amelyet mindig a régi kernelek megszüntetésére használok, nem szünteti meg a fejléceket, amit általában a következők használok, egy terminálban, amelyet írok :
dpkg --get-selections | grep linux-image
amely megmutatja a telepített kerneleket, majd használom:
sudo apt-get purge csomag
Ahol a csomag a kérdéses kernel neve, de ez nem távolítja el a társított fejléceket, ezért a következőket tenném:
dpkg --get-selections | grep linux
Aztán eltávolítom a régi fejléceket, a következőkkel:
sudo apt-get purge linux-fejlécek-3.2.0-41 linux-fejlécek-3.2.0-44 linux-fejlécek-3.2.0-45 linux-fejlécek-3.2.0-48
És voilà, de természetesen ott volt az ikonok kérdése is Felébresztett ezért úgy döntök, hogy áthelyezem őket a ~ / .icons fájlba, és elérhetővé teszem az egész rendszer számára, csak szimbolikus linket hozok létre a / usr / share / icons könyvtárban, az első eredmény df -i A fejlécek törlésével, a második pedig az ikonok áthelyezése után történik.
Ezzel a probléma megoldódott, és problémamentesen telepíthetem / frissíthetem a csomagokat, remélem, hogy ez a bejegyzés valakinek segítséget nyújt, vagy a kis partíciók telepítéseinek későbbi felhasználására szolgál, és demisztizálja a hiány fórumai által annyira elterjedt témát Az űrből.
Szia, használd az ubuntu csíptet ( http://ubuntu-tweak.com ) olyan, mint a Windows hangolása, segít eltávolítani a sok szemetet, és közben biztonságosan eltávolítja a régi kerneleket, azonban egy korábbi kernelt indít, néhány esetben az utolsó kern nem működött nálam, és köszönöm, hogy sikerült belépnem a rendszerbe hogy ne törölje mindet.
Régóta ismerem, de mindig is inkább a magam módján tettem, és megértettem a dolgok működését, mindenesetre, még a régi fejlécpár nélkül is, akinek problémája volt, ugyanezt többé-kevésbé idő alatt bemutatta volna. Ikon témák, és hogy végül, mint említettem, NEM a helyhiány, hanem a használt inódok problémája.
Köszönjük, hogy megosztotta ezt. Eddig nem volt ilyen problémám, mivel az általam használt lemezek mind Linux formátumúak, nincsenek ablakok, mivel nincs ilyen rendszer a számítógépemen.
Tehát ezt szem előtt kell tartanom, hátha egyszer megláttam ezt a problémát.
A probléma nem abból adódik, hogy partíciókat telepítünk a Windows rendszerrel (ez csak az én esetem sajátossága), hanem abból, hogy kicsi gyökérpartíciók vannak, kevesebb mint 10 GB, ahol a telepítő az mke2fs alapértelmezett beállításait használja (ez formázza a partíciókat), és Ön kis számú inóddal távozik a méretétől, és mint általában szinte a szokás, az összes partíciónk az EXT4-ben található, amely létrehozásakor ezt a számot állítja be, és később nem lehet módosítani.
Amint láthatja, ez az a fajta dolog, amely távol tartja az embereket a linuxtól, és végül visszamennek az ablakokhoz. Mit gondol, hogyan oldhatja meg a problémát egy ilyen felhasználó egy ilyen helyzetben?
nem kell pazarolnia az időt az ilyen dolgok javításával és konfigurálásával, valamint a termelékeny idő elpazarlásával.
Miguel de Icazának igaza volt abban, amit mondott, és ezért döntött úgy, hogy Mac-re vált, mert MINDEN ott működik, pont.
Ez az. Az OS X-ben minden gyönyörűen működik. Hiába magyarázzuk meg, miért történt a bejegyzés írója, kérem, ne táplálja ezt a megjegyzést. Láng lesz a vége.
Esetemben a Debian mindent elvégez a PC-n, és kiderült, hogy a DVD-t további repóként használtam a Squeeze-ről Wheezy-re frissítésre. Így bárki frissíthet.
Nos, akkor van egy Windows-felhasználó elméje.
A GNU / Linux nagy az Ön számára.
tekintetében
ez érdekes.
Ez a hiba nagyon gyakori, amikor a gentoo-t kis lemezekre telepíti, így sok kicsi forrásfájl és a partíció elfogy az inódokból, még akkor is, ha 60% szabad hely maradt. Legalább a kézikönyv az mke2fs -j -T small / dev / sdaX beírásával javítja, valószínűleg az ubuntun fut. Mielőtt furcsa beállításokat játszanék 😛
Pontosan, ahogy korábban említettem, megadhat egy inode bájt arányt az -i opcióval, de van olyan lehetőség is, amelyet megemlít -T használja az alapértelmezett módok egyikét a /etc/mke2fs.conf nevű konfigurációs fájlban, ebben az esetben a kicsi egy blocksize = 1024, inode méret = 128 és byte-inods arány = 4096.
Kiváló!
Ez a tipikus probléma, amely sokáig eszi a fejed, amíg rájössz, honnan jött.
+10 a magyarázatért 😀
Ahogy mondod, jól érezted magad, hogy megölted a fejem! Nagyon köszönöm a megjegyzést, aki olyan embertől származik, aki annyit tud, mint te, megtiszteltetés!
Kiváló !!, mást tanultam, és ez segített nekem helyreállítani körülbelül 19 MB-ot egy régi fejléc eltávolításával, valamint néhány inode helyreállításával. Most több helyem van a telepítésre. Mivel meglehetősen újonc vagyok a Linux számára, ha úgy gondolja, hogy ez rendben van, javasolom, hogy tegyen egy bejegyzést arról, hogyan lehet a legtöbb inode-ot formázni, és hogy a lemezinformációk megőrzése mellett meg lehet-e csinálni.
Üdvözlettel és köszönet
Amint azt a bejegyzés elején egy utalásban említettem, ez nagyon ritka probléma, és kis gyökérpartíciókkal (<10 GB) társul, ahogyan én is, más méretekkel valószínűtlen, hogy előfordulna. Az inódok számának megváltoztatásával kapcsolatban, amint azt a bejegyzésben is említettem, nem lehet megtenni az EXT4 típusú partíciók formázása nélkül, így nem tudta megőrizni az adatokat a lemezen anélkül, hogy korábbi biztonsági másolatot készített volna, a bájt arányának megváltoztatásához Az inodes az -i opciót használja az mke2fs parancsban, vagy a -T opciók egyikét (kicsi, nagy, hatalmas stb.).
Kiváló! A probléma kifejtése, annak magyarázata, miért történt, annak alapjai és a megoldás lépései! Ezt kiváló hozzájárulásnak nevezem! Köszönöm Rayonant!
Köszönöm a cikket, nekem nagyon sokat segített. Mindent megpróbáltam leküzdeni ezt a hibát, és a régi fejléceket és függőségeiket alkalmassággal eltávolítva képes voltam újratelepíteni a programokat és frissíteni. Köszönöm!
Ugyanez a probléma történt velem, semmi sem történt, és ez fordított fejjel lefelé hahaha. Esetemben a gyökérpartíciónak meglehetősen sok szabad memóriája volt, de 100% -ban használt inódokkal volt! A lényeg az, hogy ha régóta ugyanazt a disztribúciót használja, és az idő múlásával nem távolít el egyetlen régi kernelt sem, akkor a lemaradás szörnyű. Az én esetemben hasonló módon tudtam megoldani a problémát, mint ahogy te fogalmaztál, csak az a sudo apt-get remove vagy purge nem működött nálam, és a használaton kívüli kernelfájlok eltávolításának kulcsa a sudo használata volt. dpkg –távolítsa el és –purge, és egyesével képes voltam kiadni az inódokat. Mindazt, amit megtanulsz. Bárcsak korábban megtaláltam volna ezt a bejegyzést, mert hamarabb megoldotta volna a kérdést. Köszönöm, hogy egy kicsit felvázoltad, mi az inodes, nem sok ötletem volt.
Remek blog, üdvözlet!
Ön nagylelkű, és bár nehézkes, elég jól megértik. Mindent megtettem a betű szerint, de amit nem tehetek, az az, hogy eltávolítom az előző linux-fejléceket, ez nem engedi, hanem
E: A dpkg megszakadt, manuálisan kell futtatnia a "sudo dpkg –configure -a" fájlt a probléma kijavításához
Azt hajtom végre, amit mond nekem, és arra késztet
A nyitókép beállítása (1.4.0-1ubuntu1) ...
Traceback (a legutóbbi hívás utoljára):
A "/ usr / sbin / update-python-modules" fájl 478. sora
package.install (py_installed)
"/ Usr / sbin / update-python-modules" fájl, 112. sor, telepítve
os.symlink (fájlnév, útvonal)
OSError: [2. hiba] Nincs ilyen fájl vagy könyvtár
Hiba a sys.excepthook fájlban:
Traceback (a legutóbbi hívás utoljára):
Fájl "/usr/lib/python2.7/dist-packages/apport_python_hook.py" 128. sor az apport_excepthook fájlban
os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o640), 'w')
OSError: [Errno 28] Nincs hely az eszközön: '/var/crash/_usr_sbin_update-python-modules.0.crash'
Eredeti kivétel:
Traceback (a legutóbbi hívás utoljára):
A "/ usr / sbin / update-python-modules" fájl 478. sora
package.install (py_installed)
"/ Usr / sbin / update-python-modules" fájl, 112. sor, telepítve
os.symlink (fájlnév, útvonal)
OSError: [2. hiba] Nincs ilyen fájl vagy könyvtár
dpkg: hiba az openshot feldolgozásakor (–configure):
a telepítés utáni szkript telepítette a szálat a 1. kilépési hibával tér vissza
dpkg: hiba: nem sikerült megnyitni a / var / lib / dpkg / status fájlt az adatbázis állapotának megírásához: Nincs hely az eszközön
A kérdés az, hogy mit viselek?
Nagyon szépen köszönjük! Ez a bejegyzés sokat segített nekem.
Ole!!!
Nem csak egy trükkös problémát old meg, hanem útközben megtanulom (és élvezem)
Szia. Először is köszönöm a bejegyzést ...
Másodszor, sajnos ez nem segített rajtam. Egy elromlott csomag problémája miatt kerültem hozzá, amelyet a rendszer helyhiány miatt nem enged meg megoldani, ami a valóságban az itt kifejtettekből az i csomópontok voltak.
Tehát megpróbáltam megtisztítani a régi magokat, a javaslat szerint, de a rendszer nem engedi:
juan @ juan-P29G: ~ $ sudo apt-get purge linux-image-3.2.0-29-generic-pae
Csomaglista olvasása ... Kész
Függőségfa létrehozása
Az állapotinformációk olvasása ... Kész
A javításhoz érdemes futtatni az "apt-get -f install" fájlt:
A következő csomagok teljesítetlen függőségekkel rendelkeznek:
tzdata-java: Attól függ: tzdata (= 2014i-0ubuntu0.12.04), de a 2014e-0ubuntu0.12.04 telepítésre kerül
E: A függőségek nem teljesülnek. Próbálja meg az "apt-get -f install" csomagok nélkül (vagy adjon meg megoldást).
És amikor követem a rendszer tanácsát:
juan @ juan-P29G: ~ $ sudo apt-get -f install
Csomaglista olvasása ... Kész
Függőségfa létrehozása
Az állapotinformációk olvasása ... Kész
A függőségek kijavítása ... Kész
A következő extra csomagok kerülnek telepítésre:
tzdata
A következő csomagok frissülnek:
tzdata
1 frissítve, 0 telepítésre kerül, 0 eltávolításra és 23 nincs frissítve.
1 nincs teljesen telepítve vagy eltávolítva.
0 B / 461 kB fájl letöltése szükséges.
A művelet után 31,7 kB szabadul fel.
Folytatja [I / N]? s
Csomagok előkonfigurálása ...
(Az adatbázis olvasása ... Jelenleg telepített 893468 fájl vagy könyvtár.)
Felkészülés a tzdata 2014e-0ubuntu0.12.04 cseréjére (a / tzdata_2014i-0ubuntu0.12.04_all.deb használatával)…
A tzdata csere kicsomagolása ...
dpkg: hiba feldolgozása /var/cache/apt/archives/tzdata_2014i-0ubuntu0.12.04_all.deb (–unpack):
nem lehet biztonsági másolatot készíteni a "./usr/share/zoneinfo/posix/America/Santo_Domingo" hivatkozásról: Nincs hely az eszközön
Nem írtak "apport" jelentést, mert a hibaüzenet azt jelzi, hogy a hiba lemezzel tele van
A feldolgozás során hibák léptek fel:
/var/cache/apt/archives/tzdata_2014i-0ubuntu0.12.04_all.deb
E: Sub-process / usr / bin / dpkg adott vissza hibakódot (1)
Ördögi kör ... Egyébként meglátom, mit tehetek.
Üdvözlet.
Még egyszer szia ... tudom, hogyan lehet megtörni az ördögi kört.
Ezzel a paranccsal távolítom el a legrégebbi kernek képét:
sudo dpkg – távolítsa el a linux-image-3.2.0-29-generic-pae
Ezzel 4389 i-csomópontot szerzek, ami elég a meghibásodott csomag kijavításához, majd eltávolítom a fejléceket a régebbi kernelből, amint az a bejegyzésben szerepel.
És most helyrehozok még több i-csomópontot egy csomó régi kernel eltávolításával ...
Köszönet és üdvözlet, Juan Carlos.
Nem engedte, hogy töröljem a fejléceket
Gépeltem
sudo nautilus
És elmentem az / usr / src mappába
Ott láttam a "fejléc" fájlokat, és töröltem őket
Ezzel már hagyta, hogy leadjam az automatikus eltávolítási rendelést
Köszönöm!! lehet, hogy a hozzászólás egy kicsit régi, de még mindig nagyon hasznos, problémát megoldott inodes
Rayonant: példaértékű magyarázat.
Bár az én esetemben ki kellett terjesztenem a partíciót (a Gparteddel), a hozzászólásod segített megérteni a problémát. És miután követtem a módszeredet, az elfoglalt inódok 90% -áról (a partíció kibővítése után) csak 28% -ra léptem.
Nagyon szépen köszönjük. Mostantól a régi kernelek (és fejlécek) kiküszöbölésére használom.
Köszönet illeti Juan Carlost is (nekem is ugyanaz volt a problémám).
Egy ölelés.
Érdekes bejegyzés,
Az én esetemben a 100% -ról 9% -ra csökkentem
root @ pi: / home / pi # apt-get clean
@ pi gyökér: / home / pi # df -i
S. fájlok Nodes-i NUsados NLibres NUso% Mounted on
/ dev / root 1915424 1915288 136 100% /
később rájöttem, hogy a nem viharos viharok megérintik az orromat, megszüntettem őket és ...
root @ pi: / home / pi # rm -rf / var / tmp / ntopng /
Tachán !!!
gyökér @ pi: / # df -i
S. fájlok Nodes-i NUsados NLibres NUso% Mounted on
/ dev / root 1915424 160408 1755016 9% /
Köszönöm