Linux – Ist es möglich, ein Image remote zu mounten, das sich selbst booten und installieren kann?

Ich habe einen Remote-Server, auf dem Linux läuft. Ich möchte das Betriebssystem-Image remote installieren, falls es beschädigt wird (dies ist bereits zweimal passiert, während ich mit dem Betriebssystem experimentiere).

Bisher ist die einzige Möglichkeit, die ich habe, physisch zum Standort des Computers zu gehen und eine USB-Festplatte zu verwenden, um das Betriebssystem zu mounten, und das BIOS sieht es, sodass es davon booten kann.

Gibt es eine Möglichkeit, sich grundsätzlich über ssh mit der Maschine zu verbinden , hängen Sie dieses Image an und lassen Sie es sich so verhalten, als wäre es auf einem virtuellen Laufwerk unter Windows (wie zum Beispiel Daemon-Tools), damit es bis zu einem Neustart bestehen bleibt und mir ermöglicht, das Betriebssystem remote zu installieren?

Ich habe bei Google nach Lösungen gesucht, aber ich habe etwas gefunden, in dem PXE-Boot erwähnt wird ... was kompliziert klingt, da Sie einen Server und dergleichen benötigen und es nicht so einfach ist, ein Image zu mounten und damit fertig zu werden.

Darüber hinaus habe ich nichts Nützliches gefunden, daher sind mir die Optionen recht knapp. Weiß jemand, wie man das bewerkstelligt?

Akzeptierte Antwort:

Hier ist eine hypothetische Situation, die ich für plausibel halte:

1. Die Zielmaschine ist EFI.
2. grub ist entweder nie auf dem Ziel installiert oder wurde vollständig vom System gelöscht.
   • es kann immer nur stören und bietet sonst nichts Wertvolles.

Was wir also im obigen Fall tun könnten, ist eine Boot-Option für ein kleines Installations-/Rettungs-Image zu konfigurieren, das wir auf unserem /esp behalten oder EFI-Systempartition.

Wenn bei unserer aktuellen Installation jemals etwas schief gehen sollte, können wir, solange wir zumindest auf die EFI-Systempartition zugreifen können, unsere Firmware anschließen und den Computer so einstellen, dass er beim nächsten Neustart mit unserem Wiederherstellungs-Image startet . In diesem Fall müssten wir nur ein oder zwei Textdateien ändern, die Daumen drücken und reboot now ausführen .

Hier ist ein grundlegender Satz von Befehlen für ein minimal konfiguriertes Arch Linux (weil ich es verwende) System, das immer noch tun könnte, was ich beschreibe.

• Zuerst erstellen wir ein Arbeitsverzeichnis und laden einige Dateien herunter.

  • Ich verwende aria2c hier. Ich empfehle es, aber verwende, was auch immer funktioniert.
  • Ich entpacke rEFInd mit 7za aber die gleiche
    Werkzeugpräferenz liegt hier in allen Fällen bei Ihnen.

  • Wenn Sie dies nicht innerhalb weniger Stunden/Tage nach meiner Veröffentlichung lesen, besteht eine sehr gute Chance, dass die unten verwendeten Links nicht sind aktuell.

    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
    

• Als Nächstes erstelle ich eine Image-Diskette.

  • Ich verwende hier eine Datei mit Loop-Geräten, aber Sie möchten vielleicht eine tatsächliche Festplatte verwenden, wenn Sie von Firmware darauf booten möchten.

  • Im Fall eines tatsächlichen Geräts wird fallocate und losetup Sachen können ignoriert werden und die tatsächlichen Gerätenamen werden viel wahrscheinlicher
    /dev/sda[12] entsprechen als /dev/loop0p[12]

    fallocate -l4G img
    

• Jetzt werde ich diese Festplatte mit gdisk partitionieren Dienstprogramm und weisen Sie es einem Loop-Gerät zu.

  • Dies ist eine Skript-Verknüpfung für die Optionen, die Sie dem Programm interaktiv zuführen möchten. Es erstellt eine GUID-Partitionstabelle und eine Partition vom Typ EFI-System die die ersten verfügbaren 750 MB der Zielfestplatte und eine weitere Linux-Standardpartition umfasst, die den Rest der Festplatte umfasst.
    • Diese Partitionen sind /dev/sda1 und /dev/sda2 bzw. wenn Sie eine echte Festplatte verwenden, die /dev/sda sein wird statt ./img . Normalerweise ist es wünschenswert, mehr als eine Partition für ein Linux-Root hinzuzufügen, was vermutlich der Zweck von /dev/sda2 ist .
  • printf Skript oder nicht, die gdisk Das Programm ist einfach zu bedienen – und Sie sollten es stattdessen lieber interaktiv angehen. Die Zielfestplatte sollte nicht gemountet werden, wenn sie ausgeführt wird, und Sie benötigen wahrscheinlich Root-Rechte für w rite die Änderungen.
  • Als allgemeine Regel können Sie in diesem Programm so ziemlich alles tun, was Sie wollen, ohne Auswirkungen, bis Sie w Ritus – sei also sicher, wann du es tust.

  • Ich gebe mein $TGT ein in einer Shell-Variablen. Abgesehen von seiner Definition hier, die Sie vielleicht nach Bedarf anpassen möchten, wo ich es verwende, können Sie es auch.

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

• Wir brauchen auch ein Dateisystem auf dem ESP. Es muss FAT sein.

  • Ich gebe meinem das fs-Label VESP . Du solltest deine nennen, wie du willst.
  • Wir werden das Label später in /etc/fstab verwenden und eine weitere Konfigurationsdatei – also machen Sie auf jeden Fall etwas. daraus
  • Meiner Meinung nach sollte man immer alle kennzeichnen Festplatten.

  • Wenn Sie ein Betriebssystem auf ${TGT}2 installieren jetzt brauchst du dafür natürlich auch ein Dateisystem.

    sudo mkfs.vfat -nVESP "$TGT"1
    

• Und wir werden einige mount machen Verzeichnisse und beginnen Sie mit dem Extrahieren der relevanten Dateien.

  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
  

• Installieren Sie rEFInd …

  • rEFInd ist ein Bootmanager – der meistens nur Bootmenüs anbietet und füllt.

  • rEFInd legt seine Konfigurationsdateien auf dem esp ab und diese können jederzeit und beliebig bearbeitet werden.

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

• Jetzt mount wir unser esp und holen Sie sich die benötigten Dateien von der Arch-Installationsdiskette, um unsere eigene bootfähige Live-Rettungsdiskette zu erhalten.

  • Die meisten Live-Festplatten implementieren eine Art hässlichen Hack, um das flache, unpartitionierte ISO-Dateisystem auszusehen wie ein akzeptables Startgerät für ein UEFI-System, während die Abwärtskompatibilität mit BIOS-Systemen erhalten bleibt.
  • Arch Linux ist da keine Ausnahme.

  • Dieser hässliche Hack ist das efiboot.img derzeit auf ./efi gemountet . Dort finden wir unseren Kernel und die initramfs-Image-Datei. Der andere diejenigen auf der Festplatte (in ./arch/arch/boot ) wird nicht Arbeit für EFI-Systeme.

    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
    

Sie haben im Wesentlichen gerade – von Grund auf – eine Pre-Boot-Rettungsumgebung mit einem dauerhaften Copy-on-Write installiert save file (also könnten Sie zum Beispiel systemctl enable sshd_socket jetzt und die Einstellung würde beim nächsten Start des Live-Systems bestehen bleiben) . Das Live-Installationsmedium von Arch Linux befindet sich jetzt auf der Boot-Partition Ihres Systems und kann jederzeit über das Boot-Menü aufgerufen werden. Natürlich haben Sie auch den Bootmenü-Manager installiert.

• Ein paar Dinge zu dem oben Gesagten sollten Ihnen auffallen:
  • Ich verwende *x86* weil ich einen 64-Bit-Rechner habe und dieser Glob bekommt, was ich brauche. Für eine 32-Bit-Installation (aber warum?) Verwenden Sie *686* stattdessen.
    • Was ich brauche sind übrigens insgesamt nur 7 Dateien und ca. 300M.
    • Das rootfs des Live-Systems ist das komprimierte Bild in esp/EFI/archiso/x86_64/airootfs.sfs .
  • Ich spezifiziere die Festplatte nach Label. Es gibt keine Hinweise oder ähnlichen Unsinn – die Platte hat einen Namen und ist daher leicht zu finden. Sie müssen anstelle von VESP ein beliebiges ESP-Label ersetzen .
  • Das copytoram Kernel-Parameter weist Arch Linux Live init an system, sein rootfs-Image in ein tmpfs zu kopieren, bevor es loopmountt – was Ihnen den Zugriff auf das esp freigibt, wenn Sie in dieser Umgebung arbeiten. Die meisten Live-Installationssysteme bieten ähnlich angeordnete Konstrukte.

Verwandte:Kein Speicherplatz mehr auf der /usr/ports-Partition, wie kann ich Ports erstellen?

Wo EFI glänzt, ist seine Fähigkeit, mit einem Dateisystem umzugehen . Auf modernen Computern besteht absolut keine Notwendigkeit, eine rohe Binärdatei zu packen und zwischen Ihre Festplattenpartitionen zu klemmen. Es erstaunt mich, dass die Leute das immer noch tun, wenn sie stattdessen ihre Boot-Umgebung mit einfachen Textdateien verwalten und konfigurieren könnten, die in einem normalen, alltäglichen Verzeichnisbaum angeordnet sind. Oben habe ich den Kernel und initramfs in einem eigenen benannten Ordner in einer zentralen Baumstruktur abgelegt. Das EFI – das sich an rEFInd orientieren wird in diesem Fall der Einfachheit halber – wird dies beim Booten mit Pfadname aufgerufen weil es mountet die bes.

Jetzt müssen Sie nur noch sicherstellen, dass Sie verstehen, wie Sie das System auswählen, das tatsächlich bootet, wenn Sie es brauchen. Verstehen Sie – Sie können das jetzt sofort starten. Sie können dies in einer virtuellen Maschine mit qemu tun (Sie benötigen OVMF -pflash Firmware) oder Sie können Ihren Computer neu starten und rEFInd erkennt den Kernel und übergibt seinen Pfadnamen an die Firmware, die das Arch Linux Live-System lädt und ausführt. Wenn Sie ein dauerhafteres System auf der Festplatte installieren – oder mehrere (was Sie jetzt tun können, wenn Sie dies wünschen, indem Sie die Live-Festplatte neu starten und die Installation durchführen) – Sie sollten den Kernel und initramfs in derselben Struktur behalten. Dies ist sehr einfach zu arrangieren.

• Wenn Sie beispielsweise ein System auf einer Root-Partition installieren, die aus Mangel an Vorstellungskraft root heißt , möchten Sie es etwa so einrichten:

  • mount --bind seinen speziellen Boot-Ordner über das Stammverzeichnis /boot Pfad in /etc/fstab .

  • Sie benötigen zwei Zeilen in /etc/fstab und um einen Einhängepunkt in /esp zu erstellen damit umzugehen.

    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
    

So etwas müssen Sie immer nur einmal pro Installation tun – und das vorausgesetzt, Sie haben es gar nicht erst so eingerichtet – was einfacher ist, da der Kernel und das initramfs bereits dort sind, wo sie hingehören. Sobald Sie diese Zeilen in /etc/fstab haben und eine minimale Konfigurationsdatei in /boot/refind_linux.conf Sie sind für das Gute gerüstet. Sie können beliebig viele Installationen auf demselben System mit demselben /esp unterstützen Gerät und zentralisieren Sie einfach so alle bootfähigen Binärdateien im selben Baum. Verschiedene
Systeme werden die Dinge ein wenig anders machen – Windows braucht zum Beispiel etwas mehr Schmeichelei, um es konform zu machen – aber sie werden alle funktionieren .

• Ok, das Letzte, was Sie wissen müssen, ist, wie ich bereits sagte, wie Sie die nächste Boot-Installation aus dem Dateisystem auswählen. Dies wird in der Datei /esp/EFI/BOOT/refind.conf konfiguriert .

  • Du solltest diese Datei lesen – sie besteht wahrscheinlich zu 99 % aus Kommentaren und wird dir alles darüber erzählen, was du damit machen könntest.
  • Natürlich müssen Sie nicht wirklich etwas tun – standardmäßig rEFInd bootet den zuletzt aktualisierten Kernel in seinem Scan-Baum.

  • Aber am Ende setze ich normalerweise die folgenden Optionen:

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

  • Und die Rettungsdatei…

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

    • Und jetzt können Sie sie einfach verschieben.
    • Zum Beispiel, um die Rettungsumgebung definitiv booten zu lassen, nachdem Sie reboot now ausgeführt haben …

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

    • Und ersetzen Sie .def für die .res oben natürlich verwendet, um zum Standard-Root zurückzukehren.

Verwandte:Ubuntu von einer ISO-Datei unter Windows installieren?