Linux:è possibile montare in remoto un'immagine, che può avviarsi e installarsi da sola?

Ho un server remoto, che esegue Linux. Vorrei installare in remoto l'immagine del sistema operativo, nel caso venga danneggiata (questo è già successo due volte mentre sto sperimentando il sistema operativo).

Finora, l'unico modo che ho è andare fisicamente nella posizione della macchina e utilizzare un disco USB per montare il sistema operativo e il BIOS vederlo, in modo che possa avviarsi da esso.

C'è un modo per connettersi sostanzialmente alla macchina tramite ssh , allega questa immagine e falla comportare come se si trovasse su un'unità virtuale su Windows (come ad esempio gli strumenti daemon), quindi persisterebbe fino al riavvio e mi permetterebbe di installare in remoto il sistema operativo?

Stavo cercando soluzioni su Google, ma ho trovato qualcosa che menziona l'avvio PXE... il che sembra complicato, dal momento che hai bisogno di un server e simili, e non è semplice come montare un'immagine e farla finita.

Oltre a ciò, non ho trovato nulla di utile, quindi sono abbastanza a corto di opzioni... qualcuno sa come farlo?

Risposta accettata:

Ecco una situazione ipotetica che ritengo plausibile:

1. La macchina di destinazione è EFI.
2. grub non è mai stato installato sulla destinazione o è stato completamente cancellato dal sistema.
   • può solo interferire e altrimenti non offre nulla di valore.

Quindi quello che potremmo fare nel caso precedente è configurare un'opzione di avvio per una piccola immagine di installazione/salvataggio che teniamo sul nostro /esp o partizione di sistema EFI.

Se qualcosa dovesse andare storto con la nostra attuale installazione, quindi, fintanto che possiamo almeno accedere alla partizione di sistema EFI in qualche modo, possiamo interfacciare il nostro firmware e impostare la macchina per l'avvio con la nostra immagine di ripristino al prossimo riavvio . In tal caso, tutto ciò che dovremmo fare è modificare uno o due file di testo, incrociare le dita ed eseguire reboot now .

Ecco un set di comandi di base per un Arch Linux configurato in modo minimo (perché è quello che uso) sistema che potrebbe ancora fare come descrivo.

• Per prima cosa creeremo una directory di lavoro e scaricheremo alcuni file.

  • Uso aria2c qui. Lo consiglio, ma usa quello che funziona.
  • Decomprimo rEFInd con 7za ma la stessa preferenza per lo strumento
    è tua in tutti i casi qui.

  • Se non lo leggi entro poche ore/giorni dal mio post, allora ci sono ottime possibilità che i link utilizzati di seguito non corrente.

    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
    

• Quindi creerò un disco immagine.

  • Uso un file qui con dispositivi loop, ma potresti voler usare un disco reale se vuoi avviare questo dal firmware.

  • Nel caso di un dispositivo reale, fallocate e losetup le cose possono essere ignorate e i nomi dei dispositivi effettivi saranno molto più probabili
    corrispondano a /dev/sda[12] di /dev/loop0p[12]

    fallocate -l4G img
    

• Ora partizionerò quel disco con gdisk utility e assegnarlo a un dispositivo loop.

  • Questa è una scorciatoia con script per le opzioni che vorresti alimentare il programma in modo interattivo. Creerà una tabella delle partizioni GUID e una partizione di tipo sistema EFI che copre i primi 750 Mib disponibili del disco di destinazione e un'altra partizione predefinita di Linux che copre il resto del disco.
    • Queste partizioni saranno /dev/sda1 e /dev/sda2 rispettivamente se stai usando un disco reale, che sarà /dev/sda anziché ./img . Di solito è desiderabile aggiungere più di una partizione per una radice Linux, che si presume sia lo scopo di /dev/sda2 .
  • printf script o no, il gdisk il programma è facile da usare, quindi potresti fare meglio a farlo in modo interattivo. Il disco di destinazione non deve essere montato quando viene eseguito e probabilmente avrai bisogno dei diritti di root per w rito le modifiche.
  • Come regola generale puoi fare praticamente tutto quello che vuoi in quel programma senza alcun effetto finché non w rito, quindi assicurati di farlo.

  • Metterò il mio $TGT in una variabile di shell. Fatta eccezione per la sua definizione qui, che potresti voler adattare secondo necessità, dove la uso io così puoi farlo tu.

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

• Avremo bisogno anche di un filesystem su esp. Deve essere GRASSO.

  • Al mio do l'etichetta fs VESP . Dovresti chiamare il tuo come vuoi.
  • Utilizzeremo l'etichetta più avanti in /etc/fstab e un altro file di configurazione, quindi fallo sicuramente qualcosa.
  • Secondo me dovresti sempre etichettare tutti dischi.

  • Se installi un sistema operativo su ${TGT}2 ora ovviamente avrai bisogno anche di un filesystem.

    sudo mkfs.vfat -nVESP "$TGT"1
    

• E faremo un po' di mount directory e inizia a estrarre i file rilevanti.

  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
  

• Installa rEFInd …

  • rEFInd è un boot manager, che per lo più offre e popola i menu di avvio.

  • rEFInd metterà i suoi file di configurazione sull'esp e questi possono essere modificati in qualsiasi momento e come preferisci.

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

• Ora mount il nostro esp e ottenere i file necessari dal disco di installazione di Arch per ottenere il nostro disco di ripristino live avviabile.

  • La maggior parte dei dischi live implementa una sorta di brutto hack per far sembrare il filesystem iso piatto e non partizionato come un dispositivo di avvio accettabile per un sistema UEFI pur mantenendo la compatibilità con le versioni precedenti con i sistemi BIOS.
  • Arch Linux non fa eccezione.

  • Questo brutto trucco è quello efiboot.img attualmente montato su ./efi . È qui che troveremo il nostro kernel e il file immagine initramfs. L'altro quelli sul disco (in ./arch/arch/boot ) non funziona per i sistemi 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
    

In pratica hai appena installato, da zero, un ambiente di ripristino di pre-avvio con una copia su scrittura persistente salva il file (quindi potresti, ad esempio systemctl enable sshd_socket ora e l'impostazione persiste al prossimo avvio del sistema live) . Il supporto di installazione live di Arch Linux ora risiede nella partizione di avvio del tuo sistema e può essere chiamato dal menu di avvio in qualsiasi momento. Ovviamente hai anche installato il gestore del menu di avvio.

• Un paio di cose su quanto sopra dovrebbero risaltare per te:
  • Uso *x86* perché ho una macchina a 64 bit e quel glob ottiene ciò di cui ho bisogno. Per un'installazione a 32 bit (ma perché?) usa *686* invece.
    • Di cosa ho bisogno , a proposito, è un totale di soli 7 file e circa 300 milioni.
    • Il rootfs del sistema live è l'immagine schiacciata in esp/EFI/archiso/x86_64/airootfs.sfs .
  • Specifico il disco per etichetta. Non ci sono suggerimenti o altre sciocchezze del genere:il disco ha un nome e quindi è facilmente trovabile. Dovrai sostituire un'etichetta esp con qualsiasi cosa tu scelga invece di VESP .
  • Il copytoram il parametro kernel indica a Arch Linux live init system per copiare la sua immagine rootfs in un tmpfs prima di montarlo in loop, il che ti libera effettivamente per accedere all'esp quando lavori in quell'ambiente. La maggior parte dei sistemi di installazione live offre costrutti organizzati in modo simile.

Correlati:esaurito lo spazio su disco nella partizione /usr/ports, come posso creare le porte?

Dove EFI brilla è nella sua capacità di gestire un filesystem . Sui computer moderni non c'è assolutamente bisogno di comprimere alcuni binari non elaborati e incastrarli tra le partizioni del disco. Mi stupisce che le persone lo facciano ancora, quando, invece, potrebbero gestire e configurare il proprio ambiente di avvio con semplici file di testo disposti in un normale albero di directory quotidiano. Sopra ho inserito il kernel e initramfs nella loro cartella denominata in una struttura ad albero centrale. L'EFI – che prenderà spunto da rEFInd in questo caso per comodità, lo invocherà all'avvio tramite pathname perché si monta l'es.

Ora tutto ciò che resta da fare è assicurarti di capire come selezionare il sistema che si avvierà effettivamente quando necessario. Comprendi:puoi avviarlo subito. Puoi farlo in una macchina virtuale con qemu (avrai bisogno di OVMF -pflash firmware) oppure puoi riavviare il computer e rEFInd rileverà il kernel e passerà il suo percorso al firmware che caricherà ed eseguirà il sistema live di Arch Linux. Quando installi un sistema più permanente sul disco – o diversi (cosa che puoi fare subito se lo desideri riavviando sul disco live ed eseguendo l'installazione) – ti consigliamo di mantenere il suo kernel e initramfs nella stessa struttura. Questo è molto facile da organizzare.

• Se, ad esempio, dovessi installare un sistema su una partizione di root denominata, per mancanza di fantasia, root , vorresti configurarlo in questo modo:

  • mount --bind la sua particolare cartella di avvio sulla radice /boot percorso in /etc/fstab .

  • Avrai bisogno di due righe in /etc/fstab e per creare un punto di montaggio in /esp per gestire questo.

    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
    

Devi fare qualcosa del genere solo una volta per installazione - e questo presuppone che tu non l'abbia impostato in quel modo in primo luogo - il che è più semplice perché il kernel e initramfs saranno già al loro posto. Una volta che hai quelle righe in /etc/fstab e un file di configurazione minimo in /boot/refind_linux.conf sei pronto per il bene. Puoi supportare tutte le installazioni che vuoi sullo stesso sistema con lo stesso /esp dispositivo e centralizza tutti i binari avviabili nello stesso albero proprio in questo modo. Sistemi diversi
faranno le cose in modo leggermente diverso – Windows richiede un po' più di lusinghe per renderlo conforme, ad esempio – ma funzionano tutti .

• Ok, l'ultima cosa che devi sapere, come ho detto prima, è come scegliere la prossima installazione di avvio dal filesystem. Questo è configurato nel file /esp/EFI/BOOT/refind.conf .

  • Dovresti leggere questo file:probabilmente è un commento al 99% e ti dirà tutto su cosa potresti fare con esso.
  • Ovviamente, non devi fare nulla, per impostazione predefinita rEFInd avvierà il kernel aggiornato più di recente nel suo albero di scansione.

  • Ma di solito finisco per impostare le seguenti opzioni:

    <<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
    

  • E il file di salvataggio...

    <<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
    

    • E così ora puoi semplicemente spostarli.
    • Ad esempio, per fare in modo che l'ambiente di ripristino si avvii definitivamente dopo aver eseguito reboot now …

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

    • E sostituisci .def per il .res usato sopra, ovviamente, per tornare alla root predefinita.

Correlati:installare Ubuntu da un file ISO su Windows?