Error al Actualizar/Instalar Paquetes – Problemas de espacio – Liberar Inodos

Antes que nada comentar que esto es un error particular debido a las características de mi partición raíz y  que no suele suceder en instalaciones típicas 

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:

df -h

¡Pero si aún tengo espacio en /!

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:

Inodos usados al 100%

Inodos usados al 100%

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:

importante saber que el script analiza el directorio desde donde se lo llame, es decir, como en mi caso me interesaba analizar / pues primero en la terminal debo moverme con cd / y luego si llamar al script
#!/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:

¡Y aquí están los culpables!

¡Y aquí están los culpables!

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

kernels-rec

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

headers antiguos

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.

¡Inodos liberados por montón!

¡Inodos liberados por montón!

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.


Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   Fernando Bautista dijo

    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.

    1.    Rayonant dijo

      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.

  2.   Mauricio dijo

    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.

    1.    Rayonant dijo

      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.

  3.   gerardo H dijo

    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.

    1.    elav dijo

      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.

      1.    eliotime3000 dijo

        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.

    2.    fabian dijo

      pues entones, tienes la mente de un usuario windows.
      GNU/Linux te quedo grande.
      saludos

  4.   sieg84 dijo

    esto sí está interesante.

  5.   Jorge dijo

    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 😛

    1.    Rayonant dijo

      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.

  6.   msx dijo

    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 😀

    1.    Rayonant dijo

      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!

  7.   Antonio dijo

    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

    1.    Rayonant dijo

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

  8.   Mario dijo

    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!

  9.   Diana Bedoya dijo

    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!

  10.   Jasco dijo

    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!

  11.   Leo dijo

    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?

  12.   Pablo dijo

    ¡Muchas gracias! Me sirvió un montón este post.

  13.   pang dijo

    Ole !!!

    No solo resuelves un problema peliagudo, sino que aprendo (y disfruto) por el camino

  14.   Juan Carlos dijo

    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.

  15.   Juan Carlos dijo

    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.

  16.   Anónimo dijo

    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

  17.   Anónimo dijo

    Gracias!! el post puede ser un poco viejo pero sigue siendo de gran utilidad, problema resuelto con los inodes

  18.   Luis dijo

    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.

  19.   Hilarius dijo

    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 🙂