He estado ejecutando Pop!_OS por un tiempo y decidí instalar Kubuntu. Arranqué la unidad USB de Kubuntu para probarlo primero y decidí preparar la partición para la instalación con KDE Partition Manager.
Este SSD ya tenía 4 particiones: sda1
(instalación antigua de Windows), sda2
(datos), sda3
(Pop!_OS) y sda4
(intercambio). Para hacer espacio para una nueva partición para Kubuntu, reduje el final sda2
en 30 Gb, pero no pude formatear este espacio no asignado porque ya había 4 particiones primarias. Así que decidí eliminar sda1
, mover el espacio no asignado a la derecha sda2
y agregar ese espacio sda2
. Al aplicar las acciones hubo un error (algo sobre una discrepancia de tamaño) y se canceló.
Al volver a arrancar en Pop!_OS, puedo ver que los 30 Gb de espacio no asignado tomados sda2
están allí, y eso sda1
no se tocó, pero no puedo montar sda2
:
Esto es lo que GParted muestra ahora:
Aquí está la información para sda2
:
Y la salida de fdisk -l
:
(Las entradas de la tabla de particiones no están en el orden del disco).
Como parece que podría haber varios problemas, decidí no tocarlo por ahora y recibir un consejo, realmente me gustaría recuperar los datos de esa partición. Si se necesita más información, estaré encantado de proporcionársela. Perdón por el hilo tan largo y muchas gracias por tu tiempo.
ACTUALIZAR:
Mientras espero comentarios, intenté arreglar el orden de las entradas de la tabla de particiones usando fdisk. Después de realizar el procedimiento (y tener que arreglar GRUB para poder reiniciar), fdisk no los informa como fuera de servicio.
Otra cosa que hice fue usar check
la opción de gparted en esa partición, que devolvió información más interesante:
GParted 0.32.0 --enable-libparted-dmraid --enable-online-resize
Libparted 3.2
Check and repair file system (ext4) on /dev/sda2 00:00:00 ( ERROR )
calibrate /dev/sda2 00:00:00 ( SUCCESS )
path: /dev/sda2 (partition)
start: 275396608
end: 782370815
size: 506974208 (241.74 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them 00:00:00 ( ERROR )
e2fsck -f -y -v -C 0 '/dev/sda2' 00:00:00 ( ERROR )
The filesystem size (according to the superblock) is 71051776 blocks
The physical size of the device is 63371776 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes
e2fsck 1.45.3 (14-Jul-2019)
Ese es el error que inició todo esto, simplemente no logré guardar esa información. Me parece que la partición simplemente no sabe su tamaño real. Comenzó con más de 270 GB, luego eliminé 30 GB para una nueva partición. Thunar informa que tiene 260 GB, Dolphin, GParted y fdisk informan que tiene 240 GB, lo cual tiene sentido. Ahora bien, ¿cómo podría solucionarlo sin empeorar las cosas? Muchas gracias de nuevo a cualquiera que lea.
Respuesta1
Parece que olvidó cambiar el tamaño del sistema de archivos después de reducir la partición. Debe usarlo resize2fs
para reducir el sistema de archivos para que sea más pequeño que la partición. No puedes tener particiones que sean más pequeñas que los sistemas de archivos.
resize2fs /dev/sda2 239G
Esto debería darle un giga de espacio para garantizar que el sistema de archivos sea más pequeño que la partición misma.
Respuesta2
Este consejo se dasin ninguna garantía, especialmente considerando que no podemos saber qué pasó exactamente con sus particiones/sistemas de archivos.
Antes de realizar cambios en sus particiones y/o sistemas de archivos, debe hacer una copia de seguridad de los datos sin procesar, por ejemplo, arrancando desde un CD/DVD/USB en vivo y copiando todo el disco en una ubicación segura. Guardarlo como un archivo normal comprimido (para ahorrar espacio) es tan fácil como:
$ sudo gzip -c /dev/sda >/path/on/safe/storage/sda.img.gz
Dicho esto, parece que su administrador de particiones se ha reducido correctamente sda2
(la partición), pero no ha podido reducir el sistema de archivos contenido.
Deberías poder confirmar lo que dice GParted ejecutando:
$ sudo fsck.ext4 -v -f /dev/sda2
(responde y
si te pide abortar).
En lugar de intentar cambiar el tamaño del sistema de archivos, le sugiero que restaure el tamaño al sda2
que tenía originalmente. O, en todo caso, crecer sda2
según la cantidad de espacio libre que tenga a su derecha. Si el sistema de archivos contenido no está dañado, esto debería permitir montarlo nuevamente, permitiéndole al menos hacer una copia de seguridad de sus datos antes de intentar reducir esa partición nuevamente.
Según mis preferencias personales, usaríaGNU se separópara editar la tabla de particiones y volver a crear la segunda partición ( sda2
):
$ sudo parted /dev/sda
(parted) unit s
(parted) rm 2
(parted) mkpart primary ext4 275396608 843810815
(parted) quit
Esto, por supuesto, se basa en el fdisk
resultado que publicó originalmente. Es posible que deba ajustarlo si algo ha cambiado desde entonces.
(Usar fdisk
en lugar de parted
también es sencillo: después sudo fdisk /dev/sda
, use p
para inspeccionar la tabla de particiones, d
seguido de 2
para eliminar sda2
, n
seguido de p
, 275396608
como primer sector y nada como último sector (el último sector del espacio libre contiguo se seleccionará de forma predeterminada). ) para volver a crear sda2
y w
guardar. Es posible que luego necesite sudo partprobe -s /dev/sda
informar al kernel sobre la tabla de particiones actualizada.
Luego, podrá verificar el sistema de archivos (como se indicó anteriormente, usando fsck.ext4 -v -f /dev/sda2
) y montarlo sda2
nuevamente.
Finalmente, puede volver a intentar reducir sda2
: las herramientas que está utilizando, incluido KDE Partition Manager, deberían poder hacerlo. Sólo le sugiero que guarde/aplica una operación a la vez (por ejemplo, eliminar sda1
, reducir sda2
o desplazar sda2
...) y evitar poner en cola varias de ellas: aumenta la probabilidad de encontrar algún caso de esquina no probado.