Centos:¿cómo reducir el sistema de archivos raíz sin iniciar un Livecd?

Me encuentro en la necesidad de reorganizar las particiones de un sistema para mover los datos que antes estaban bajo el sistema de archivos raíz a puntos de montaje dedicados. Todos los volúmenes están en LVM, por lo que es relativamente fácil:cree nuevos volúmenes, transfiera datos a ellos, reduzca el sistema de archivos raíz y luego monte los nuevos volúmenes en los puntos apropiados.

El problema es el paso 3, la reducción del sistema de archivos raíz. Los sistemas de archivos involucrados son ext4, por lo que se admite el cambio de tamaño en línea; sin embargo, mientras está montado, los sistemas de archivos solo pueden crecer. Para reducir la partición es necesario desmontarla, lo que por supuesto no es posible para la partición raíz en funcionamiento normal.

Las respuestas en la Web parecen girar en torno a arrancar un LiveCD u otro medio de rescate, hacer la operación de reducción y luego volver a arrancar en el sistema instalado. Sin embargo, el sistema en cuestión es remoto y solo tengo acceso a través de SSH. Puedo reiniciar, pero no es posible iniciar un disco de rescate y realizar operaciones desde la consola.

¿Cómo puedo desmontar el sistema de archivos raíz mientras mantengo el acceso remoto al shell?

Respuesta aceptada:

Para resolver este problema, la información proporcionada en http://www.ivarch.com/blogs/oss/2007/01/resize-a-live-root-fs-a-howto.shtml fue fundamental. Sin embargo, esa guía es para una versión muy antigua de RHEL y cierta información estaba obsoleta.

Las instrucciones a continuación están diseñadas para funcionar con CentOS 7, pero deberían ser fácilmente transferibles a cualquier distribución que ejecute systemd. Todos los comandos se ejecutan como root.

1. Asegúrese de que el sistema esté en un estado estable

   Asegúrese de que nadie más lo esté usando y que no esté sucediendo nada más importante. Probablemente sea una buena idea detener las unidades que brindan servicios como httpd o ftpd, solo para garantizar que las conexiones externas no interrumpan las cosas en el medio.

   systemctl stop httpd
   systemctl stop nfs-server
   # and so on....
   

2. Desmontar todos los sistemas de archivos no utilizados

   mount -a
   

   Esto imprimirá una serie de advertencias de "El destino está ocupado", para el propio volumen raíz y para varios FS temporales/del sistema. Estos pueden ser ignorados por el momento. Lo importante es que ningún sistema de archivos en disco permanezca montado, excepto el propio sistema de archivos raíz. Verifica esto:

   # mount alone provides the info, but column makes it possible to read
   mount | column -t
   

   Si ve algún sistema de archivos en el disco todavía montado, entonces todavía se está ejecutando algo que no debería estarlo. Comprueba qué está usando fuser :

   # if necessary:
   yum install psmisc
   # then:
   fuser -vm <mountpoint>
   systemctl stop <whatever>
   umount -a
   # repeat as required...
   

3. Hacer la raíz temporal

   mkdir /tmp/tmproot
   mount -t tmpfs none /tmp/tmproot
   mkdir /tmp/tmproot/{proc,sys,dev,run,usr,var,tmp,oldroot}
   cp -ax /{bin,etc,mnt,sbin,lib,lib64} /tmp/tmproot/
   cp -ax /usr/{bin,sbin,lib,lib64} /tmp/tmproot/usr/
   cp -ax /var/{account,empty,lib,local,lock,nis,opt,preserve,run,spool,tmp,yp} /tmp/tmproot/var/
   

   Esto crea un sistema raíz mínimo, que interrumpe (entre otras cosas) la visualización de la página de manual (sin /usr/share ), personalizaciones a nivel de usuario (sin /root o /home ) Etcétera. Esto es intencional, ya que constituye un estímulo para no permanecer en un sistema de raíz manipulado por jurado más tiempo del necesario.

   En este punto, también debe asegurarse de que todo el software necesario esté instalado, ya que seguramente también romperá el administrador de paquetes. Eche un vistazo a todos los pasos y asegúrese de tener los ejecutables necesarios.

4. Pivote hacia la raíz

   mount --make-rprivate / # necessary for pivot_root to work
   pivot_root /tmp/tmproot /tmp/tmproot/oldroot
   for i in dev proc sys run; do mount --move /oldroot/$i /$i; done
   

   systemd hace que los montajes permitan compartir subárboles de forma predeterminada (como con mount --make-shared ), y esto hace que pivot_root fallar Por lo tanto, desactivamos esto globalmente con mount --make-rprivate / . Los sistemas de archivos temporales y del sistema se trasladan en su totalidad a la nueva raíz. Esto es necesario para que funcione; los sockets para la comunicación con systemd, entre otras cosas, viven en /run , por lo que no hay forma de hacer que los procesos en ejecución lo cierren.

5. Asegúrese de que el acceso remoto sobrevivió al cambio

   systemctl restart sshd
   systemctl status sshd
   

   Después de reiniciar sshd, asegúrese de poder ingresar abriendo otra terminal y conectándose a la máquina nuevamente a través de ssh. Si no puede, solucione el problema antes de continuar.

   Una vez que haya verificado que puede conectarse nuevamente, salga del shell que está usando actualmente y vuelva a conectarse. Esto permite que el sshd bifurcado restante para salir y se asegura de que el nuevo no esté reteniendo /oldroot .

6. Cierre todo lo que siga usando la antigua raíz

   fuser -vm /oldroot
   

   Esto imprimirá una lista de procesos que aún se mantienen en el directorio raíz anterior. En mi sistema, se veía así:

                USER        PID ACCESS COMMAND
   /oldroot:    root     kernel mount /oldroot
                root          1 ...e. systemd
                root        549 ...e. systemd-journal
                root        563 ...e. lvmetad
                root        581 f..e. systemd-udevd
                root        700 F..e. auditd
                root        723 ...e. NetworkManager
                root        727 ...e. irqbalance
                root        730 F..e. tuned
                root        736 ...e. smartd
                root        737 F..e. rsyslogd
                root        741 ...e. abrtd
                chrony      742 ...e. chronyd
                root        743 ...e. abrt-watch-log
                libstoragemgmt    745 ...e. lsmd
                root        746 ...e. systemd-logind
                dbus        747 ...e. dbus-daemon
                root        753 ..ce. atd
                root        754 ...e. crond
                root        770 ...e. agetty
                polkitd     782 ...e. polkitd
                root       1682 F.ce. master
                postfix    1714 ..ce. qmgr
                postfix   12658 ..ce. pickup
   

   Debe lidiar con cada uno de estos procesos antes de poder desmontar /oldroot . El enfoque de fuerza bruta es simplemente kill $PID para cada uno, pero esto puede romper las cosas. Para hacerlo más suavemente:

   systemctl | grep running
   

   Esto crea una lista de servicios en ejecución. Debería poder correlacionar esto con la lista de procesos que contienen /oldroot , luego emita systemctl restart para cada uno de ellos. Algunos servicios se negarán a aparecer en la raíz temporal y entrarán en un estado fallido; estos realmente no importan por el momento.

   Si la unidad raíz que desea cambiar el tamaño es una unidad LVM, es posible que también deba reiniciar algunos otros servicios en ejecución, incluso si no aparecen en la lista creada por fuser -vm /oldroot . Si descubre que no puede cambiar el tamaño de una unidad LVM en el Paso 7, intente systemctl restart systemd-udevd .

   Algunos procesos no se pueden tratar con un simple systemctl restart . Para mí, estos incluían auditd (al que no le gusta que lo maten a través de systemctl , por lo que solo quería un kill -15 ). Estos pueden tratarse individualmente.

   El último proceso que encontrará, por lo general, es systemd sí mismo. Para esto, ejecute systemctl daemon-reexec .

   Una vez que haya terminado, la tabla debería verse así:

                USER        PID ACCESS COMMAND
   /oldroot:    root     kernel mount /oldroot
   

7. Desmontar la antigua raíz

   umount /oldroot
   

   En este punto, puede realizar las manipulaciones que necesite. La pregunta original necesitaba un simple resize2fs invocación, pero puedes hacer lo que quieras aquí; otro caso de uso es transferir el sistema de archivos raíz desde una partición simple a LVM/RAID/lo que sea.

8. Pivote la raíz hacia atrás

   mount <blockdev> /oldroot
   mount --make-rprivate / # again
   pivot_root /oldroot /oldroot/tmp/tmproot
   for i in dev proc sys run; do mount --move /tmp/tmproot/$i /$i; done
   

   Esta es una inversión directa del paso 4.

9. Deseche la raíz temporal

   Repita los pasos 5 y 6, pero use /tmp/tmproot en lugar de /oldroot . Entonces:

   umount /tmp/tmproot
   rmdir /tmp/tmproot
   

   Dado que es un tmpfs, en este punto la raíz temporal se disuelve en el éter, para nunca más ser vista.

10. Pon las cosas en su lugar

    Vuelva a montar sistemas de archivos:

    mount -a
    

    En este punto, también debe actualizar /etc/fstab y grub.cfg de acuerdo con cualquier ajuste que haya realizado durante el paso 7.

    Reinicie cualquier servicio fallido:

    systemctl | grep failed
    systemctl restart <whatever>
    

    Permitir subárboles compartidos nuevamente:

    mount --make-rshared /
    

    Inicie las unidades de servicio detenidas; puede usar este único comando:

    systemctl isolate default.target
    

Y listo.

Relacionado:¿No puedo instalar el centro de software en Kali?

Muchas gracias a Andrew Wood, que elaboró ​​esta evolución en RHEL4, y a Steve, que me proporcionó el enlace al primero.