Linux:¿es posible montar de forma remota una imagen que pueda iniciarse e instalarse sola?

Tengo un servidor remoto, que ejecuta Linux. Me gustaría instalar de forma remota la imagen del sistema operativo, en caso de que se corrompa (esto ya sucedió dos veces mientras estaba experimentando con el sistema operativo).

Hasta ahora, la única forma que tengo es ir físicamente a la ubicación de la máquina y usar un disco USB para montar el sistema operativo y el BIOS lo ve, para que pueda arrancar desde él.

¿Hay alguna forma de conectarse básicamente a la máquina a través de ssh? , adjunte esta imagen y haga que actúe como si estuviera en una unidad virtual en Windows (como las herramientas daemon, por ejemplo), para que persista hasta un reinicio y me permita instalar el sistema operativo de forma remota?

Estaba buscando soluciones en Google, pero encontré algo que mencionaba el arranque PXE... lo cual suena complicado, ya que necesitas un servidor y demás, y no es tan simple como montar una imagen y terminar con ella.

Más allá de eso, no encontré nada útil, por lo que me faltan opciones... ¿alguien sabe cómo lograr esto?

Respuesta aceptada:

Aquí hay una situación hipotética que considero que podría ser plausible:

1. La máquina de destino es EFI.
2. grub nunca se instaló en el objetivo o se eliminó por completo del sistema.
   • solo puede interferir y no ofrece nada de valor de lo contrario.

Entonces, lo que podríamos hacer en el caso anterior es configurar una opción de arranque para una pequeña imagen de instalación/rescate que mantenemos en nuestro /esp o partición del sistema EFI.

Si alguna vez algo saliera mal con nuestra instalación actual, mientras podamos al menos acceder a la partición del sistema EFI de alguna manera, podemos conectar nuestro firmware y configurar la máquina para que arranque con nuestra imagen de recuperación en el próximo reinicio . En ese caso, todo lo que tendríamos que hacer es cambiar uno o dos archivos de texto, cruzar los dedos y ejecutar reboot now .

Aquí hay un conjunto básico de comandos para un Arch Linux mínimamente configurado (porque es lo que uso) sistema que todavía podría hacer lo que describo.

• Primero, crearemos un directorio de trabajo y descargaremos algunos archivos.

  • Utilizo aria2c aquí. Lo recomiendo, pero usa lo que funcione.
  • Descomprimo rEFInd con 7za pero la misma
    preferencia de herramienta es tuya en todos los casos aquí.

  • Si no está leyendo esto dentro de unas pocas horas o días después de que lo publique, es muy probable que los enlaces que se usan a continuación no actual.

    mkdir /tmp/work && cd /tmp/work || exit
    aria2c  'magnet:?xt=urn:btih:331c7fac2e13c251d77521d2dc61976b6fc4a033&dn=archlinux-2015.06.01-dual.iso&tr=udp://tracker.archlinux.org:6969&tr=http://tracker.archlinux.org:6969/announce' 
            'http://iweb.dl.sourceforge.net/project/refind/0.8.7/refind-cd-0.8.7.zip'
    7za x ref*.zip; rm ref*zip
    

• A continuación, crearé un disco de imagen.

  • Utilizo un archivo aquí con dispositivos de bucle, pero es posible que desee utilizar un disco real si desea iniciar desde el firmware.

  • En el caso de un dispositivo real, el fallocate y losetup las cosas se pueden ignorar y es mucho más probable que los nombres reales de los dispositivos
    correspondan a /dev/sda[12] que /dev/loop0p[12]

    fallocate -l4G img
    

• Ahora particionaré ese disco con el gdisk utilidad y asígnela a un dispositivo de bucle.

  • Este es un atajo con secuencias de comandos para las opciones que le gustaría alimentar el programa de forma interactiva. Creará una tabla de particiones GUID y una partición de tipo EFI-system que abarca los primeros 750Mib disponibles del disco de destino y otra partición predeterminada de Linux que abarca el resto del disco.
    • Estas particiones serán /dev/sda1 y /dev/sda2 respectivamente, si está utilizando un disco real, que será /dev/sda en lugar de ./img . Por lo general, es deseable agregar más de una partición para una raíz de Linux, que se supone que es el propósito de /dev/sda2 .
  • printf script o no, el gdisk El programa es fácil de usar, por lo que es mejor que lo haga de forma interactiva. El disco de destino no debe montarse cuando se ejecuta, y probablemente necesitará derechos de root para w escriba los cambios.
  • Como regla general, puedes hacer prácticamente lo que quieras en ese programa sin ningún efecto hasta que w rito, así que asegúrese de hacerlo.

  • Pondré mi $TGT en una variable de shell. Excepto por su definición aquí, que quizás desee adaptar según sea necesario, donde yo la uso, usted también puede hacerlo.

    printf %s\n o y n 1 '' +750M ef00 
                     n 2 '' '' '' '' w y |
    gdisk ./img     >/dev/null
    TGT=$(sudo losetup --show -Pf img)p
    

• También necesitaremos un sistema de archivos en el esp. Debe ser GORDO.

  • Le doy a la mía la etiqueta fs VESP . Deberías llamar al tuyo como quieras.
  • Usaremos la etiqueta más adelante en /etc/fstab y otro archivo de configuración, así que definitivamente hazlo algo.
  • En mi opinión, siempre debe etiquetar todos discos.

  • Si instala un sistema operativo en ${TGT}2 ahora, por supuesto, también necesitará un sistema de archivos.

    sudo mkfs.vfat -nVESP "$TGT"1
    

• Y haremos un poco de mount directorios y comience a extraer los archivos relevantes.

  set     ref     ref*iso         
          arch    arch*iso        
          efi     arch/EFI/archiso/efiboot.img
  while   [ "$#" -gt 0 ]
  do      mkdir "$1" || exit
          sudo mount "$2" "$1"
          shift 2
  done;   mkdir esp
  

• Instalar rEFInd …

  • rEFInd es un administrador de inicio, que en su mayoría solo ofrece y completa los menús de inicio.

  • rEFInd pondrá sus archivos de configuración en el esp y estos se pueden editar en cualquier momento y de la forma que desee.

    sudo ref/install.sh --usedefault "$TGT"1 &&
    sudo umount ref  && rm -rf ref*
    

• Ahora vamos a mount nuestro esp y obtenga los archivos necesarios del disco de instalación de Arch para obtener nuestro propio disco de rescate de arranque en vivo.

  • La mayoría de los discos en vivo implementan una especie de truco feo para hacer que el sistema de archivos iso plano y sin particiones luzca como un dispositivo de arranque aceptable para un sistema UEFI mientras se mantiene la compatibilidad con versiones anteriores con sistemas BIOS.
  • Arch Linux no es una excepción.

  • Este truco feo es que efiboot.img actualmente montado en ./efi . Es donde encontraremos nuestro kernel y el archivo de imagen initramfs. El otro unos en el disco (en ./arch/arch/boot ) no trabajo para sistemas EFI.

    sudo sh -ec    <<CONF '
         mount    "$1" esp
         cp -ar    efi/EFI/archiso esp/EFI
         cp -ar    arch/arch/*x86* esp/EFI/archiso
         mkdir     esp/EFI/archiso/cow
         xargs   > esp/EFI/archiso/refind_linux.conf
         umount    efi arch
         rm -rf    efi arch*' -- "$TGT"1
    "arch_iso" "archisobasedir=EFI/archiso    
                   archisolabel=VESP             
                   copytoram                     
                   cow_label=VESP                
                   cow_directory=/EFI/archiso/cow
                   cow_persistence=P             
                   cow_spacesize=384M            
                   initrd=EFI/archiso/archiso.img"
    CONF
    

Básicamente, acaba de instalar, desde cero, un entorno de rescate previo al arranque con una copia en escritura persistente. guarde el archivo (por lo que podría, por ejemplo, systemctl enable sshd_socket ahora y la configuración persistiría en el siguiente arranque del sistema en vivo) . Los medios de instalación en vivo de Arch Linux ahora residen en la partición de inicio de su sistema y se pueden llamar desde el menú de inicio en cualquier momento. Por supuesto, también instaló el administrador del menú de arranque.

• Debería destacar un par de cosas sobre lo anterior:
  • Uso *x86* porque tengo una máquina de 64 bits y ese glob obtiene lo que necesito. Para una instalación de 32 bits (¿pero por qué?) usa *686* en cambio.
    • Lo que necesito , por cierto, es un total de solo 7 archivos y aproximadamente 300M.
    • El rootfs del sistema en vivo es la imagen aplastada en esp/EFI/archiso/x86_64/airootfs.sfs .
  • Especifico el disco por etiqueta. No hay pistas u otras tonterías similares:el disco tiene un nombre y, por lo tanto, se encuentra fácilmente. Deberá sustituir lo que elija por una etiqueta esp en lugar de VESP .
  • El copytoram El parámetro del kernel instruye a Arch Linux live init system para copiar su imagen rootfs en un tmpfs antes de montarlo en bucle, lo que lo libera para acceder al esp cuando trabaja en ese entorno. La mayoría de los sistemas de instalación en vivo ofrecen construcciones dispuestas de manera similar.

Relacionado:Se quedó sin espacio en disco en la partición /usr/ports, ¿cómo puedo crear puertos?

Donde EFI brilla es en su capacidad para manejar un sistema de archivos . En las computadoras modernas, no hay absolutamente ninguna necesidad de empaquetar un binario sin formato y colocarlo entre las particiones de su disco. Me sorprende que la gente todavía lo haga, cuando, en cambio, podrían administrar y configurar su entorno de arranque con archivos de texto simples organizados en un árbol de directorios normal y cotidiano. Arriba puse el kernel e initramfs en su propia carpeta con nombre en una estructura de árbol central. El EFI, que se inspirará en rEFInd en este caso por conveniencia, lo invocará en el arranque mediante pathname porque monta la especial

Ahora todo lo que queda por hacer es asegurarse de que comprende cómo seleccionar el sistema que realmente se iniciará cuando lo necesite. Comprenda:puede iniciar esto ahora mismo. Puedes hacerlo en una máquina virtual con qemu (necesitará OVMF -pflash firmware) o puede reiniciar su computadora y rEFInd detectará el kernel y pasará su nombre de ruta al firmware que cargará y ejecutará el sistema en vivo Arch Linux. Cuando instala un sistema más permanente en el disco, o varios (lo que puede hacer ahora mismo si así lo desea, reiniciando el disco en vivo y realizando la instalación) – querrá mantener su núcleo e initramfs en la misma estructura. Esto se arregla muy fácilmente.

• Si, por ejemplo, fuera a instalar un sistema en una partición raíz llamada, por falta de imaginación, root , querrás configurarlo de la siguiente manera:

  • mount --bind su carpeta de inicio particular sobre la raíz /boot ruta en /etc/fstab .

  • Necesitarás dos líneas en /etc/fstab y para crear un punto de montaje en /esp para manejar esto.

    sudo sh -c          <<FSTAB     '
         [ -d /esp ]    || mkdir /esp
         findmnt   /esp || mount -L ESP /esp
         mkdir -p  /esp/EFI/root
         cp        /boot/kernel binary   
                   /boot/initramfs.img   
                   /esp/EFI/root
         mount -B  /esp/EFI/root /boot
         cat   >>  /etc/fstab
         echo "$1">/boot/refind_linux.conf
    ' -- '"new_menu_item" "root=LABEL=root"'
    LABEL=ESP       /esp    vfat    defaults        0 2
    /esp/EFI/root   /boot   none    bind,defaults   0 0
    FSTAB
    

Solo tiene que hacer algo así una vez por instalación, y eso suponiendo que no lo configuró de esa manera en primer lugar, lo cual es más fácil porque el kernel e initramfs ya estarán donde pertenecen. Una vez que tenga esas líneas en /etc/fstab y un archivo de configuración mínimo en /boot/refind_linux.conf estás listo para el bien. Puede admitir tantas instalaciones como desee en el mismo sistema con el mismo /esp dispositivo y centralice todos los binarios de arranque en el mismo árbol así como así. Distintos
sistemas harán las cosas un poco diferentes (por ejemplo, Windows requiere un poco más de persuasión para que se ajuste), pero todos funcionarán .

• Ok, lo último que necesita saber, como dije antes, es cómo elegir la próxima instalación de arranque desde el sistema de archivos. Esto se configura en el archivo /esp/EFI/BOOT/refind.conf .

  • Debería leer este archivo; es probable que el 99 % sea un comentario y le dirá todo lo que puede hacer con él.
  • Por supuesto, en realidad no tienes que hacer nada; de forma predeterminada, rEFInd arrancará el núcleo actualizado más recientemente en su árbol de exploración.

  • Pero normalmente termino configurando las siguientes opciones:

    <<DEF sudo tee 
           /esp/EFI/BOOT/refind.conf.def
    ### refind.conf.def
    ### when renamed to refind.conf this file
    ### will cause refind to select by default
    ### the menu item called "new_menu_item"
    ### in its /boot/refind_linux.conf
    default_selection new_menu_item
    ### this file will also set the menu timeout
    ### to only 5 seconds at every boot
    timeout 5
    ### END
    DEF
    

  • Y el archivo de rescate...

    <<RES sudo tee 
           /esp/EFI/BOOT/refind.conf.res
    ### refind.conf.res
    ### this one will default to selecting
    ### the entry named "arch_iso" with a
    ### 10 second timeout
    default_selection arch_iso
    timeout 10
    ### END
    RES
    

    • Y ahora puedes simplemente moverlos.
    • Por ejemplo, para que el entorno de rescate se inicie definitivamente después de reboot now …

    sudo cp /esp/EFI/BOOT/refind.conf.res 
            /esp/EFI/BOOT/refind.conf
    

    • Y sustituya .def para el .res utilizado anteriormente, por supuesto, para volver a la raíz predeterminada.

Relacionado:¿instalar Ubuntu desde un archivo ISO en Windows?