Sé un poco sobre sistemas de archivos pero no mucho. Sólo tengo una idea general de qué son los LVM, aunque aparentemente eso es lo que estoy usando como partición raíz.
Tengo un único disco duro de 1TB en mi computadora. Ejecuto Ubuntu 14.04.
Fui a instalar algunas actualizaciones hoy y me informaron que no tengo suficiente espacio por /bootpartición.
Fui a liberar algo de espacio con la gpartedGUI desde un CD en vivo, pero noté que mi sistema de archivos raíz se muestra lleno:
Según dfsin embargo:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 954367812 10720604 895145040 2% /
none 4 0 4 0% /sys/fs/cgroup
udev 2995912 12 2995900 1% /dev
tmpfs 608016 1312 606704 1% /run
none 5120 0 5120 0% /run/lock
none 3040072 17312 3022760 1% /run/shm
none 102400 52 102348 1% /run/user
/dev/sda2 241965 118221 111252 52% /boot
/dev/sda1 523248 3428 519820 1% /boot/efi
tmpfs 3040072 4 3040068 1% /var/lib/polkit-1/localauthority/90-mandatory.d
¿Qué pasa con esto? ¿Por qué gpartedcreo que mi partición está llena?
También tengo una pregunta adicional. ¿Alguien sabe cuál es la diferencia entre las /boot/efiparticiones /booty si necesito ambas?
Respuesta1
Entre ellos, AFH y Romeo Ninov básicamente tienen la respuesta, pero es necesario agruparla.
Su /bootpartición está separada porque es esencialmente necesaria para el uso de LVM (que no es un sistema de archivos, sino un contenedor para volúmenes lógicos, que a su vez contienen sistemas de archivos). Se puede cambiar el tamaño de una partición LVM; veraquípara obtener un resumen de lo que se requiere. Aunque no estoy seguro de ir allí...
Usted informa que su proceso de actualización se queja de espacio insuficiente en su /bootpartición de 244 MiB, pero esa partición actualmente solo se utiliza en un 52%. Las distribuciones que rutinariamente crean /bootparticiones separadas generalmente las hacen aproximadamente el doble de grandes que las suyas, pero sigue siendo extraño que sus actualizaciones intenten casi duplicar la cantidad de espacio utilizado allí. La instalación de Ubuntu 14.04 en la que estoy escribiendo esto usa solo 80 MiB en /boot. Por lo tanto, es posible que desees comprobar qué hay allí. Tipo ls -lh /boot. Esto es lo que veo en mi sistema:
$ ls -lh /boot
total 70M
-rw-r--r-- 1 root root 1.2M Feb 14 17:06 abi-3.13.0-45-generic
-rw-r--r-- 1 root root 1.2M May 4 01:09 abi-3.13.0-52-generic
-rw-r--r-- 1 root root 162K Feb 14 17:06 config-3.13.0-45-generic
-rw-r--r-- 1 root root 162K May 4 01:09 config-3.13.0-52-generic
drwxr-xr-x 10 root root 4.0K Dec 31 1969 efi
drwxr-xr-x 3 root root 1.0K May 7 11:30 extlinux
drwxr-xr-x 5 root root 1.0K Mar 12 20:08 grub
drwxr-xr-x 2 root root 1.0K Feb 14 17:06 grub.bak
-rw-r--r-- 1 root root 20M Feb 26 18:39 initrd.img-3.13.0-45-generic
-rw-r--r-- 1 root root 20M May 7 11:28 initrd.img-3.13.0-52-generic
drwx------ 2 root root 12K Feb 14 17:05 lost+found
-rw-r--r-- 1 root root 173K Feb 14 17:06 memtest86+.bin
-rw-r--r-- 1 root root 174K Feb 14 17:06 memtest86+.elf
-rw-r--r-- 1 root root 175K Feb 14 17:06 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 227 Feb 14 17:06 refind_linux.conf
-rw------- 1 root root 3.3M Feb 14 17:06 System.map-3.13.0-45-generic
-rw------- 1 root root 3.3M May 4 01:09 System.map-3.13.0-52-generic
-rw------- 1 root root 5.6M Feb 14 17:06 vmlinuz-3.13.0-45-generic
-rw-r--r-- 1 root root 5.6M Feb 19 21:38 vmlinuz-3.13.0-45-generic.efi.signed
-rw------- 1 root root 5.6M May 4 01:09 vmlinuz-3.13.0-52-generic
-rw-r--r-- 1 root root 5.6M May 10 21:36 vmlinuz-3.13.0-52-generic.efi.signed
Eso es bastante típico (aunque con un poco más de lo que tendrían algunos sistemas). Si ve más archivos de diferentes tipos de los que he mostrado aquí, es posible que algo haya agregado algo nuevo y extraño, y dichos archivos podrían ser candidatos para eliminarse, pero si no los comprende, pida consejo antes. eliminándolos.
Otra cosa que hay que comprobar son los núcleos extraños. Estos son los archivos con nombres que comienzan con vmlinuz. (Están emparejados con initrd.imgarchivos que AFH le pidió que buscara). Mi propio ejemplo muestra cuatro archivos del kernel, pero en realidad son versiones firmadas y sin firmar de solo dos kernels. Si ve más de tres versiones del kernel (cada una de las cuales puede estar disponible en formato firmado y sin firmar), pruebe el siguiente comando:
sudo apt-get autoremove
Este comando debería eliminar todos los kernels excepto el original y los dos más recientes de su sistema, lo que debería liberar algo de espacio.
Si tiene que cambiar el tamaño de las particiones, podría ser más seguro reducir su partición del sistema EFI (ESP; /dev/sda1en su caso) y expandirse /boota ese espacio que alterar su configuración LVM. No recomendaría cambiar el tamaño en más de 200 MiB, y deberíasdefinitivamenterespaldoambas particionesen un medio extraíble antes de continuar, porque ambas particiones son críticas para el arranque, por lo que si algo sale mal, estará en serios problemas. Además, tenga en cuenta que algunos EFI pueden ser quisquillosos con los sistemas de archivos FAT en sus ESP. Algunos (en su mayoría EFI más antiguos, anteriores a 2012) reaccionarán mal a un ESP FAT32 de menos de 512 MiB. Por lo tanto, si intenta cambiar el tamaño de esta manera, comience reduciendo el ESP y luego realice un arranque de prueba. Si puede iniciar, expanda /bootel espacio liberado e intente iniciar nuevamente. Si tiene problemas después de encoger el ESP, utilice un sistema de emergencia para expandirlo a su tamaño original.
Respuesta2
Encuentro que los resultados gparteddifieren df, pero no hasta este punto: sospecho gpartedque está malinterpretando su lvm2contenido.
Su problema es que /bootestá montado en una unidad separada de 0,25 GB y esto es lo que se está quedando sin espacio. No estoy seguro de cómo llegó a este estado o cómo salir de él: tal vez grubno arranca muy bien desde lvm2los sistemas de archivos.
Lo más sencillo es eliminar todos los kernels excepto el actual y el anterior (nunca necesitarás más de un kernel de respaldo). Tipo:
ls -l /boot/initrd*
uname -a
Esto mostrará todas las versiones del kernel instaladas y su kernel en ejecución. Luego debes eliminar todos menos los dos últimos. Prefiero usar synapticpara esto: seleccione Installedy en el cuadro de búsqueda establezca a su vez la parte numérica de cada una de las versiones que desea eliminar, luego escriba Ctrl-apara seleccionar todas, y haga clic derecho y seleccione Mark for Complete Removal(asegurándose absolutamente de no eliminar tu lanzamiento actual!). Después de revisar cada uno de los núcleos que se eliminarán, haga clic en Apply.
En Ubuntu 15.04 con dos núcleos instalados, mi /bootdirectorio tiene un tamaño de poco más de 120 MB, por lo que debería tener espacio para dos versiones mientras instala una tercera en su /dev/sda2(y recuerde eliminar la versión más antigua cada vez que haga esto).
Si esto no resuelve su problema, tiene dos opciones: -
- Aumente el tamaño de
/dev/sda2moviendo el límite entre él y/dev/sda3. - Busque en Internet
grub lvm2y siga los consejos que allí se encuentran.
Para responder a su pregunta auxiliar, /bootes donde residen los archivos de arranque del kernel, y normalmente está dentro del mismo sistema de archivos que /, pero grubes necesario identificar dónde residen los archivos de arranque EFI, y esto se hace montando la partición de arranque EFI en /boot/efi. En otras palabras, /boot/efies el punto de montaje para un sistema de archivos independiente, pero es inusual que /bootsea un punto de montaje en sí mismo. Necesita ambos, a menos que esté iniciando con un BIOS heredado.
Respuesta3
Porque en la pantalla ves PV (volumen físico), no sistema de archivos. Y todo el pv se asigna a vg. ejecutando
df
Verás el estado del sistema de archivos.