Para empezar mencionare la historia de como sucedió el problema y luego como solucionarlo.
Mi equipo es un netbook Sony Vaio m120AL que tengo desde hace unos 3 años largos con un disco duro de 320 GB donde conviven Windows 7, Chakra , mi partición de trabajo con Xubuntu 12.04, la partición de swap, la partición /home y una partición adicional de información con la que comparto información con Windows.
Por estas razones mis particiones raíz en ambos sistemas son considerablemente pequeñas para los estándares de la mayoría (alrededor de 6GB cada una) pero que nunca me han dado problemas pues son más que suficientes para todos los paquetes que necesito.
Ahora bien entrando a la situación en concreto, hace unos días aplicando unas actualizaciones en Xubuntu (entre las cuales se incluía un nuevo Kernel) veo que el gestor de actualizaciones muestra un error diciendo que se esta tratando de instalar linux-image-3.2.0-51-generic pero que su dependencia linux-headers-3.2.0-51 no será instalada, reviso en detalle el error y me doy cuenta que dpkg se queja de que no hay espacio disponible.
El error decía al algo de este estilo, aunque no idéntico porque no lo anoté:
no se pudo crear `/usr/src/linux-headers-3.2.0-43/arch/xtensa/include/asm/coprocessor.h.dpkg-new' (mientras se procesaba `./usr/src/linux-headers-3.2.0-43/arch/xtensa/include/asm/coprocessor.h'): No queda espacio en el dispositivo
En alguna ocasión anterior me ha pasado lo mismo pero había sido por que había dejado acumular varios Kernel antiguos sin borrarlos , pero en esta ocasión reviso y tengo prácticamente 600 Mb disponibles según Conky por lo que no lo entiendo, pero para confirmar si puede ser un error en como lo había configurado o similar ejecuto un df -h:
Por lo que no me equivoco y ese es espacio más que suficiente para realizar la actualización (lo he hecho así ya muchas veces en el año largo ya que llevo con Xubuntu) de todas formas realizo un sudo apt-get clean para limpiar los paquetes que tenga descargados e intento de nuevo, pero con los mismos resultados.
Se me sigue haciendo extraño pero de todas formas intento mover fuera de / los temas de iconos que siempre uso y que he modificado mucho (Faenza y Awoken) para liberar más espacio, y así finalmente logro realizar la actualización, procediendo nuevamente a devolverlos a /.
Sin embargo me quedó en la cabeza la idea de que el asunto tenía que ir por otra parte pero no sabía cual. Algunas horas más tarde cuando intento instalar algunos paquetes extra sale de nuevo el susodicho error, y una vez más vez había espacio suficiente de sobra, por lo que me dedico a investigar.
Una búsqueda por Internet me lleva a varios hilos en los foros de ubuntu-es, pero la respuesta de algunos individuos allí siempre es al misma: no tienes suficiente espacio elimina archivos o amplia la partición raíz, pero me di cuenta de algo en común en los diferentes hilos que encontré, siempre la partición raíz que tenía espacio libre, pero era similar al mio (~600-900 Mb) y el tamaño de la partición nunca superaba los 10 Gb por lo que me termine de convencer que el problema debía ser otro, y es así como llegue al título del post gracias a esta página, el problema es que la partición raíz tenia el 100% de los inodos usados.
El uso de los inodos puede verse con el comando df -i:
Y ahora viene la explicación.
Los inodos son en palabra de Dennis Ritchie:
Un índice, debido a la estructura algo inusual de un sistema de ficheros que almacenaba la información del acceso a los archivos como una lista plana en disco, dejando al margen toda la información jerárquica de los directorios
y por tanto puede suceder que para un sistema de archivos determinado exista aún espacio libre para almacenar ficheros, pero no queden inodos disponibles para indexarlos porque existen muchos archivos en el sitema y por lo tanto no pueden crearse nuevos.
El asunto es que el número de inodos en una partición EXT4 no puede ser modificado (existen otros tipos de sistemas como JFX o XFS donde esto no es una limitante pues es dinámico) es un número fijo que se calcula cuando se crea la partición con mkfs.ext4 de acuerdo al tamaño de la misma con una relación de bytes por inodo según las preferencias ubicadas en /etc/mke2fs.conf.
Al instalar el sistema lo usual es que use las preferencias por defecto que incluye un relación inode = 16384, que para particiones pequeñas pude ser demasiado grande y no cree el número suficiente (como en mi caso). La única manera de cambiarla es creando/formateando la partición y específicandolo con la opción -i.
Sin embargo esto no era una opción para mi, como ya lo comenté los inodos están relacionados con el número de ficheros existentes, así que use el siguiente script en bash que se encuentra en stackoverflow y que esta enlazado en la página que antes menciones para encontrar cuales eran los directorios en la partición raíz con más ficheros:
#!/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_$$
Lo cual arroja el siguiente resultado:
El número que aparece a la izquierda indica la cantidad de archivos presentes y la ruta indica el directorio asociado, una línea más abajo sale el directorio /var/lib/dpkg/info pero como siempre elimino mis paquetes con purge aquí no hay nada que hacer.
Sin embargo si reconozco dos problemas, el primero y aunque en la catpura no sale de ahí hacia arriba varias entradas más incluyen a los iconos Awoken, por lo que debo moverlos si o si, además que eso explica por que cuando lo hice pude actualiza los paquetes, pues libere muchos inodos de la partición raíz cuando los moví, pero el problema volvió cuando los recoloque.
Y segundo el siguiente mayor número de entradas esta asociada a los headers de varios kernel viejos, y caigo en cuenta que el procedimiento que siempre uso para eliminar los kernel viejos no elimina los headers, lo que suelo usar es lo siguiente, en una terminal escribo:
dpkg --get-selections | grep linux-image
lo cual me muestra los kernel instalados y luego uso:
sudo apt-get purge paquete
Donde paquete es el nombre del kernel en cuestión, pero esto no remueve los headers asociados así que hago un:
dpkg --get-selections | grep linux
Y entonces procedo a eliminar los antiguos headers, con:
sudo apt-get purge linux-headers-3.2.0-41 linux-headers-3.2.0-44 linux-headers-3.2.0-45 linux-headers-3.2.0-48
Y voilà , pero claro estaba también el tema de lo iconos Awoken así que decido moverlos a ~/.icons y para que estén disponibles para todo el sistema simplemente hago un enlace simbólico en /usr/share/icons, el primer resultado de df -i es con la eliminación de los headers y el segundo después de haber movido lo iconos.
Con esto ya esta solucionado el problema, y puedo instalar/actualizar paquetes sin problema, espero que esta entrada le sea de ayuda a alguien, o sirva para futura referencia sobre instalaciones en particiones pequeñas y desmitifique el tema tan difundido por los foros de la falta de espacio.
Hola, utiliza ubuntu tweak ( http://ubuntu-tweak.com ) es como el tuneup para windows, te ayuda a sacar mucha basura y de paso desinstala los kernel viejos de manera segura, sin embargo, deja un antepenultimo kernel para arrancar, en alguna ocasion el ultimo kernel no me funciono y logre entrar al sistema gracias a que no los borre todos.
Si lo conozco de hace rato, pero siempre he preferido hacerlo a mi manera y entender la forma en que funcionan las cosas, de todas maneras aun sin el par de headers viejos que tenía el problema se hubiera presentado igual en más o menos tiempo por lo temas de iconos, y que al final como lo mencione NO es un problema de falta de espació sino de inodos usados.
Gracias por compartir esto. Hasta ahora no he tenido ese problema, ya que los disco que uso, estan todos en formato para linux, nada de windows, ya que no tengo ese sistema en mi equipo.
Asi que, esto lo tendre presente, por si algun dia me llegase a ver con este problema.
El problema no viene por tener particiones con Windows (es solo una particularidad de mi caso) sino por tener particiones raíz pequeñas, menores a 10Gb donde el instalador utiliza las opciones predeterminadas de mke2fs (que es el que da formato a las particiones) y te deja con un número pequeño de inodos para el tamaño de la misma, y que como suele ser casi norma, todas nuestras particiones están en EXT4 que fija este número cuando se crea y no es posible modificarlo después.
como pueden ver, este es el tipo de cosas que alejan a la gente de linux y terminan volviendo a windows, ¿como creen que un usuario comun frente a esta situacion pueda resolver el problema?
uno no tiene por que estar perdiendo el tiempo arreglando y configurando este tipo de cosas y perdiendo tiempo productivo.
tenia razon Miguel de Icaza con lo que decia y por eso decidio cambiarse a Mac porque ahi TODO FUNCIONA y punto.
Así mismo es. En OS X todo funciona bonito.. De nada vale explicar en este momento el por qué sucedió lo que el autor del post comenta, así que por favor, que nadie alimente este comentario. Terminará en flame.
En mi caso, Debian me funciona todo en mi PC y resulta que usando el DVD como repo adicional para actualizar de Squeeze a Wheezy. Así cualquiera puede actualizar.
pues entones, tienes la mente de un usuario windows.
GNU/Linux te quedo grande.
saludos
esto sí está interesante.
Este error es muy frecuente al instalar gentoo en discos chicos, tantos archivos fuente pequeños y se queda sin inodos la particion por mas que quede 60% de espacio libre. Por lo menos el handbook lo soluciona al escribir mke2fs -j -T small /dev/sdaX ,probablemente ande en ubuntu. Antes de estar tocando configuraciones extrañas 😛
Exactamente, como ya lo mencione antes puedes especificar una relación de bytes inodos con la opción -i , pero también esta la opción que mencionas -T utiliza uno de los modos predeterminados en el archivo de configuración que nombre /etc/mke2fs.conf , en este caso small aplicara un blocksize = 1024, tamaño de inodo de = 128 y una relación de bytes- inods = 4096.
Excelente!
Es el típico problema que te come la cabeza un rato largo hasta que te das cuenta por donde venía.
+10 por la explicación 😀
Tal cual lo dices, ¡me tuvo un buen tiempo matándome la cabeza!, muchas gracias por el comentario, viniendo de alguien que sabe tanto como tu es todo un honor!
Excelente !!, He aprendido algo mas, y me ha servido para recuperar 19Mb y pico al quitar un header antiguo, así como recuperar algunos inodos. Ahora tengo mas espacio para instalar. Como soy bastante novato con linux, si os parece bien os animo a que hagais algún post sobre como formatear para obtener el mayor número de inodos e indicación de si se puede realizar manteniendo la información del disco o no.
Un saludo y gracias
Como lo mencione en una indicación al inicio de la entrada es un problema muy poco común y esta asociado a particiones raíz de tamaño reducido (<10GB) como lo es mi caso, con otros tamaños es poco probable que ocurra. Ahora bien respecto al cambio del número de inodos, como también lo mencione en la entrada no es posible hacerlo sin formatear en particiones tipo EXT4 por lo que no podrías mantener la información en el disco sin haber hecho un respaldo previo, para cambiar la relación bytes inodos se usa la opción -i en el comando mke2fs o una de las opciones asociadas a -T (small, big , huge etc).
Excelente! La exposición del problema, la explicación del porque sucedio, sus fundamentos, y los pasos de la solución! A esto le llamo un excelente aporte! Gracias Rayonant!
Gracias por el artículo, me ayudó mucho. Había probado de todo para superar este error y al eliminar los headers viejos y sus dependencias con aptitude pude volver a instalar programas y a hacer las actualizaciones. Gracias!
Me ha pasado el mismo problema hace nada, y me ha traído de cabeza jajaja. En mi caso, la partición raíz tenía bastante memoria libre, ¡pero estaba con el 100% de inodos usados! La cuestión es que si llevas usando una misma distribución durante bastante tiempo y con el paso del tiempo no eliminas ningún kernel antiguo, la acumulación es terrible. En mi caso pude solucionar el problema de manera parecida a cómo lo pones, solo que el sudo apt-get remove o purge no me funcionaba y la clave para poder eliminar esos archivos de kernel en desuso fue utilizar sudo dpkg –remove y –purge, y uno a uno pude ir liberando inodos. Todo eso que se aprende. Ójala hubiera dado con esta entrada antes porque habría solucionado el asunto antes. Gracias por bosquejar un poco qué es eso de los inodos, que no tenía mucha idea.
¡gran blog, un saludo!
sos un groso y aunque es engorroso se entiende bastante bien. Hice todo al pie de la letra pero lo que no puedo hacer es eliminar los linux-headers anteriores, no me deja, me pone
E: se interrumpió la ejecución de dpkg, debe ejecutar manualmente «sudo dpkg –configure -a» para corregir el problema
ejecuto lo que me dice y me pone
Configurando openshot (1.4.0-1ubuntu1) …
Traceback (most recent call last):
File «/usr/sbin/update-python-modules», line 478, in
package.install(py_installed)
File «/usr/sbin/update-python-modules», line 112, in install
os.symlink(filename,destpath)
OSError: [Errno 2] No such file or directory
Error in sys.excepthook:
Traceback (most recent call last):
File «/usr/lib/python2.7/dist-packages/apport_python_hook.py», line 128, in apport_excepthook
os.O_WRONLY|os.O_CREAT|os.O_EXCL, 0o640), ‘w’)
OSError: [Errno 28] No space left on device: ‘/var/crash/_usr_sbin_update-python-modules.0.crash’
Original exception was:
Traceback (most recent call last):
File «/usr/sbin/update-python-modules», line 478, in
package.install(py_installed)
File «/usr/sbin/update-python-modules», line 112, in install
os.symlink(filename,destpath)
OSError: [Errno 2] No such file or directory
dpkg: error al procesar openshot (–configure):
el subproceso instalado el script post-installation devolvió el código de salida de error 1
dpkg: error: fallo al abrir `/var/lib/dpkg/status’ para escribir la base de datos status: No queda espacio en el dispositivo
La pregunta es, de que me disfrazo?
¡Muchas gracias! Me sirvió un montón este post.
Ole !!!
No solo resuelves un problema peliagudo, sino que aprendo (y disfruto) por el camino
Hola. En primer lugar, gracias por el post…
En segundo, lamentablemente no me sirvió. Llegué a él por un problema de un paquete roto, que el sistema no me deja resolver por falta de espacio, que en realidad por lo que acá se explicó era de los nodos i.
Entonces intenté purgar los kernels viejos, como se sugiere, pero el sistema no me deja:
juan@juan-P29G:~$ sudo apt-get purge linux-image-3.2.0-29-generic-pae
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Tal vez quiera ejecutar «apt-get -f install» para corregirlo:
Los siguientes paquetes tienen dependencias incumplidas:
tzdata-java : Depende: tzdata (= 2014i-0ubuntu0.12.04) pero 2014e-0ubuntu0.12.04 va a ser instalado
E: Dependencias incumplidas. Intente «apt-get -f install» sin paquetes (o especifique una solución).
Y cuando sigo el consejo del sistema:
juan@juan-P29G:~$ sudo apt-get -f install
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Corrigiendo dependencias… Listo
Se instalarán los siguientes paquetes extras:
tzdata
Se actualizarán los siguientes paquetes:
tzdata
1 actualizados, 0 se instalarán, 0 para eliminar y 23 no actualizados.
1 no instalados del todo o eliminados.
Se necesita descargar 0 B/461 kB de archivos.
Se liberarán 31,7 kB después de esta operación.
¿Desea continuar [S/n]? s
Preconfigurando paquetes …
(Leyendo la base de datos … 893468 ficheros o directorios instalados actualmente.)
Preparando para reemplazar tzdata 2014e-0ubuntu0.12.04 (usando …/tzdata_2014i-0ubuntu0.12.04_all.deb) …
Desempaquetando el reemplazo de tzdata …
dpkg: error al procesar /var/cache/apt/archives/tzdata_2014i-0ubuntu0.12.04_all.deb (–unpack):
no se puede respaldar enlace simbólico para `./usr/share/zoneinfo/posix/America/Santo_Domingo’: No queda espacio en el dispositivo
No se escribió un informe «apport» porque el mensaje de error indica que el error es de disco lleno
Se encontraron errores al procesar:
/var/cache/apt/archives/tzdata_2014i-0ubuntu0.12.04_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Un círculo vicioso… En fin, veré qué puedo hacer.
Saludos.
Hola de nuevo… ya sé cómo romper el círculo vicioso.
Eliminaré la imagen del más viejo de los kernels con este comando:
sudo dpkg –remove linux-image-3.2.0-29-generic-pae
Con eso gano 4389 nodos-i, suficientes para reparar el paquete roto, y luego elimino los encabezados del kernel más viejo según lo indicado en el post.
Y ahora recuperaré más nodos-i eliminando un montón de kernels viejos…
Gracias y saludos, Juan Carlos.
A mi no me dejaba borrar los headers
He tecleado
sudo nautilus
Y he ido a la carpeta /usr/src
Ahi he visto los ficheros «headers» y los he borrado
Con eso ya me ha dejado poner la orden autoremove
Gracias!! el post puede ser un poco viejo pero sigue siendo de gran utilidad, problema resuelto con los inodes
Rayonant: una explicación ejemplar.
Aunque, en mi caso, he debido ampliar la partición (con Gparted), tu post me he servido para entender el problema. Y después de seguir tu método, he pasado de un 90% de inodos ocupados (tras haber ampliado la partición), a tan solo el 28%.
Muchas gracias. Lo utilizaŕé en adelante para ir eliminando los viejos kernels (y los headers).
Gracias también a Juan Carlos (yo tenía el mismo problema).
Un abrazo.
Interesante post,
En mi caso he bajado de un 100% de uso a un 9%
root@pi:/home/pi# apt-get clean
root@pi:/home/pi# df -i
S.ficheros Nodos-i NUsados NLibres NUso% Montado en
/dev/root 1915424 1915288 136 100% /
después encontrar q los temporales de ntopng me estaban tocando las narices, los he eliminado y…
root@pi:/home/pi# rm -rf /var/tmp/ntopng/
¡¡¡tachán!!!
root@pi:/# df -i
S.ficheros Nodos-i NUsados NLibres NUso% Montado en
/dev/root 1915424 160408 1755016 9% /
Gracias 🙂