Linux - Est-il possible de monter à distance une image qui peut démarrer et s'installer toute seule ?

J'ai un serveur distant, qui exécute Linux. Je voudrais installer à distance l'image du système d'exploitation, au cas où elle serait corrompue (cela s'est déjà produit deux fois pendant que j'expérimente le système d'exploitation).

Jusqu'à présent, le seul moyen que j'ai est d'aller physiquement à l'emplacement de la machine et d'utiliser un disque USB pour monter le système d'exploitation et le BIOS le voir, afin qu'il puisse démarrer à partir de celui-ci.

Existe-t-il un moyen de se connecter essentiellement à la machine via ssh , joignez cette image et faites-la agir comme si elle se trouvait sur un lecteur virtuel sous Windows (comme des outils démons par exemple), afin qu'elle persiste jusqu'à un redémarrage et me permette d'installer le système d'exploitation à distance ?

Je cherchais des solutions sur Google, mais j'ai trouvé quelque chose mentionnant le démarrage PXE... ce qui semble compliqué, puisque vous avez besoin d'un serveur et autres, et ce n'est pas aussi simple que de monter une image et d'en finir avec.

Au-delà de cela, je n'ai rien trouvé d'utile, donc je suis assez à court d'options… est-ce que quelqu'un sait comment accomplir cela ?

Réponse acceptée :

Voici une situation hypothétique que je considère comme plausible :

La machine ciblée est EFI.
grub n'est jamais installé sur la cible ou a été complètement effacé du système.
- il ne peut qu'interférer et n'offre rien de valeur autrement.

Donc, ce que nous pourrions faire dans le cas ci-dessus est de configurer une option de démarrage pour une petite image d'installation/de secours que nous gardons sur notre /esp ou partition système EFI.

Si jamais quelque chose devait mal tourner avec notre installation actuelle, alors, tant que nous pouvons au moins accéder à la partition système EFI par un moyen quelconque, nous pouvons interfacer notre micrologiciel et configurer la machine pour qu'elle démarre sur notre image de récupération au prochain redémarrage. . Dans ce cas, tout ce que nous aurions à faire serait de changer un fichier texte ou deux, de croiser les doigts et d'exécuter reboot now .

Voici un ensemble de commandes de base pour un Arch Linux configuré de manière minimale (parce que c'est ce que j'utilise) système qui pourrait encore faire ce que je décris.

Tout d'abord, nous allons créer un répertoire de travail et télécharger quelques fichiers.
- J'utilise aria2c ici. Je le recommande, mais utilisez ce qui fonctionne.
- Je décompresse rEFInd avec 7za mais la même
  préférence d'outil est la vôtre dans tous les cas ici.
- Si vous ne lisez pas ceci dans les quelques heures/jours suivant ma publication, il y a de fortes chances que les liens utilisés ci-dessous ne soient pas courant.
```
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
```
Ensuite, je vais créer un disque d'image.
- J'utilise ici un fichier avec des périphériques en boucle, mais vous pouvez utiliser un disque réel si vous souhaitez démarrer à partir du micrologiciel.
- Dans le cas d'un appareil réel, le fallocate et losetup les choses peuvent être ignorées et les noms de périphériques réels correspondront bien plus probablement
  à /dev/sda[12] que /dev/loop0p[12]
```
fallocate -l4G img
```
Maintenant, je vais partitionner ce disque avec le gdisk utilitaire et affectez-le à un périphérique de boucle.
- Il s'agit d'un raccourci scripté pour les options que vous souhaitez alimenter le programme de manière interactive. Il créera une table de partition GUID et une partition de type EFI-system qui couvre les premiers 750 Mo disponibles du disque cible et une autre partition Linux par défaut couvrant le reste du disque.
  - Ces partitions seront /dev/sda1 et /dev/sda2 respectivement si vous utilisez un vrai disque, qui sera /dev/sda plutôt que ./img . Il est généralement souhaitable d'ajouter plus d'une partition pour une racine Linux, ce qui est supposé être le but de /dev/sda2 .
- printf script ou non, le gdisk est facile à utiliser - et vous feriez mieux de le faire de manière interactive à la place. Le disque cible ne doit pas être monté lorsqu'il est exécuté, et vous aurez probablement besoin des droits root pour w notez les changements.
- En règle générale, vous pouvez faire à peu près tout ce que vous voulez dans ce programme sans aucun effet jusqu'à ce que vous w rite - alors soyez sûr quand vous le faites.
- Je vais mettre mon $TGT dans une variable shell. À l'exception de sa définition ici, que vous voudrez peut-être adapter si nécessaire, là où je l'utilise, vous aussi.
```
printf %s\n o y n 1 '' +750M ef00 
                 n 2 '' '' '' '' w y |
gdisk ./img     >/dev/null
TGT=$(sudo losetup --show -Pf img)p
```
Nous aurons également besoin d'un système de fichiers sur l'esp. Il doit être FAT.
- Je donne au mien le label fs VESP . Vous devriez appeler le vôtre comme vous voulez.
- Nous utiliserons l'étiquette plus tard dans /etc/fstab et un autre fichier de configuration - alors faites-en certainement quelque chose.
- À mon avis, vous devriez toujours étiqueter tous disques.
- Si vous installez un système d'exploitation sur ${TGT}2 maintenant, vous aurez bien sûr besoin d'un système de fichiers pour cela également.
```
sudo mkfs.vfat -nVESP "$TGT"1
```

Et nous ferons du mount répertoires et commencez à extraire les fichiers pertinents.

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

Installer rEFInd …
- rEFInd est un gestionnaire de démarrage - qui propose et remplit principalement les menus de démarrage.
- rEFInd mettra ses fichiers de configuration sur l'esp et ceux-ci peuvent être modifiés à tout moment et comme vous le souhaitez.
```
sudo ref/install.sh --usedefault "$TGT"1 &&
sudo umount ref  && rm -rf ref*
```
Maintenant, nous allons mount notre esp et extrayez les fichiers nécessaires du disque d'installation d'Arch pour obtenir notre propre disque de secours amorçable en direct.
- La plupart des disques actifs implémentent une sorte de hack laid pour rendre le système de fichiers iso plat et non partitionné apparence comme un périphérique de démarrage acceptable pour un système UEFI tout en conservant la rétrocompatibilité avec les systèmes BIOS.
- Arch Linux ne fait pas exception.
- Ce hack laid est-ce efiboot.img actuellement monté sur ./efi . C'est là que nous trouverons notre noyau et le fichier image initramfs. L'autre ceux sur le disque (dans ./arch/arch/boot ) ne sera pas fonctionne pour les systèmes 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
```

Vous venez essentiellement d'installer - à partir de zéro - un environnement de secours de pré-démarrage avec une copie sur écriture persistante enregistrer le fichier (vous pouvez donc, par exemple, systemctl enable sshd_socket maintenant et le paramètre persisterait au prochain démarrage du système en direct) . Le support d'installation en direct d'Arch Linux réside désormais sur la partition de démarrage de votre système et peut être appelé à tout moment à partir du menu de démarrage. Bien sûr, vous avez également installé le gestionnaire de menu de démarrage.

Certaines choses à propos de ce qui précède devraient vous retenir :
- J'utilise *x86* parce que j'ai une machine 64 bits et que glob obtient ce dont j'ai besoin. Pour une installation 32 bits (mais pourquoi ?) utilisez *686* à la place.
  - Ce dont j'ai besoin , soit dit en passant, est un total de seulement 7 fichiers et environ 300M.
  - Le rootfs du système en direct est l'image écrasée dans esp/EFI/archiso/x86_64/airootfs.sfs .
- Je spécifie le disque par étiquette. Il n'y a pas d'indices ou d'autres bêtises de ce type - le disque est nommé et il est donc facile à trouver. Vous devrez remplacer ce que vous avez choisi par une étiquette esp au lieu de VESP .
- Le copytoram le paramètre du noyau indique à Arch Linux live init système pour copier son image rootfs dans un tmpfs avant de le monter en boucle - ce qui vous permet en fait d'accéder à l'esp lorsque vous travaillez dans cet environnement. La plupart des systèmes d'installation en direct proposent des constructions organisées de la même manière.

Connexe :Manque d'espace disque dans la partition /usr/ports, comment puis-je créer des ports ?

Là où EFI brille, c'est dans sa capacité à gérer un système de fichiers . Sur les ordinateurs modernes, il n'est absolument pas nécessaire d'emballer du binaire brut et de le caler entre vos partitions de disque. Je suis étonné que les gens le fassent encore, alors qu'au lieu de cela, ils pouvaient gérer et configurer leur environnement de démarrage avec de simples fichiers texte disposés dans une arborescence de répertoires régulière et quotidienne. Ci-dessus, j'ai placé le noyau et initramfs dans leur propre dossier nommé dans une arborescence centrale. L'EFI - qui s'inspirera de rEFInd dans ce cas pour plus de commodité - invoquera cela au démarrage par pathname parce qu'il monte l'esp.

Il ne vous reste plus qu'à vous assurer que vous comprenez comment sélectionner le système qui démarrera réellement lorsque vous en aurez besoin. Comprenez - vous pouvez le démarrer maintenant. Vous pouvez le faire dans une machine virtuelle avec qemu (vous aurez besoin d'OVMF -pflash micrologiciel) ou vous pouvez redémarrer votre ordinateur et rEFInd détectera le noyau et transmettra son nom de chemin au micrologiciel qui chargera et exécutera le système live Arch Linux. Lorsque vous installez un système plus permanent sur le disque - ou plusieurs (ce que vous pouvez faire maintenant si vous le souhaitez en redémarrant sur le disque en direct et en effectuant l'installation) – vous voudrez garder son noyau et initramfs dans la même structure. C'est très facile à organiser.

Si, par exemple, vous deviez installer un système sur une partition racine nommée, faute d'imagination, root , vous voudriez le configurer quelque chose comme ceci :

mount --bind son dossier de démarrage particulier sur la racine /boot chemin dans /etc/fstab .

Vous aurez besoin de deux lignes dans /etc/fstab et de créer un point de montage dans /esp pour gérer cela.

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

Vous n'avez jamais à faire quelque chose comme ça une fois par installation - et cela en supposant que vous ne l'avez pas configuré de cette façon en premier lieu - ce qui est plus facile car le noyau et initramfs seront déjà là où ils appartiennent. Une fois que vous avez ces lignes dans /etc/fstab et un fichier de configuration minimal dans /boot/refind_linux.conf vous êtes prêt pour de bon. Vous pouvez prendre en charge autant d'installations que vous le souhaitez sur le même système avec le même /esp périphérique et centralisez tous les fichiers binaires amorçables dans la même arborescence, comme ça. Différents
systèmes feront les choses un peu différemment - Windows prend un peu plus de cajolerie pour le rendre conforme, par exemple - mais ils fonctionneront tous .

Ok, la dernière chose que vous devez savoir, comme je l'ai déjà dit, est de savoir comment choisir la prochaine installation de démarrage à partir du système de fichiers. Ceci est configuré dans le fichier /esp/EFI/BOOT/refind.conf .
- Vous devriez lire ce fichier :il contient probablement 99 % de commentaires et vous dira tout sur ce que vous pourriez en faire.
- Bien sûr, vous n'avez rien à faire - par défaut rEFInd démarrera le noyau le plus récemment mis à jour dans son arbre d'analyse.
- Mais je finis généralement par définir les options suivantes :
```
<<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
```
- Et le dossier de secours…
```
<<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
```
  - Et maintenant, vous pouvez simplement les déplacer.
  - Par exemple, pour que l'environnement de secours démarre définitivement après avoir reboot now …
```
sudo cp /esp/EFI/BOOT/refind.conf.res 
        /esp/EFI/BOOT/refind.conf
```
  - Et remplacer .def pour le .res utilisé ci-dessus, bien sûr, pour revenir à la racine par défaut.

Connexe :installer Ubuntu à partir d'un fichier ISO sous Windows ?