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:
¡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 quedo 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%
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!
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.
¡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.
Continúar leyendo...
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:
¡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 quedo 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%
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!
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.
¡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.
Continúar leyendo...