J'ai supprimé tout le contenu de /boot et maintenant le serveur ne démarre pas.

La partition /boot contient des fichiers importants du noyau Linux ainsi que des fichiers Grub. Sans eux, votre système ne pourra pas démarrer (comme vous l'avez déjà compris). Et la simple restauration des fichiers Grub ne va pas vous aider. Pour récupérer de cette situation, vous devriez être en mesure de faire ce qui suit :

• Démarrer le système en mode de secours à partir de l'image DVD/ISO CentOS.
• Réinstallez le noyau en exécutant yum reinstall kernel
• Réinstaller Grub en exécutant /sbin/grub2-install /dev/sda

Dans la dernière étape, vous devrez peut-être remplacer /dev/sda avec un autre nom de périphérique, en fonction de votre matériel. Il doit s'agir de votre disque dur principal à partir duquel vous souhaitez démarrer. Sur les machines virtuelles, il s'agit généralement de /dev/vda . Si vous n'êtes pas sûr, vous pouvez utiliser la fonction lsblk (vous devrez peut-être exécuter la commande yum install util-linux d'abord) pour lister tous vos périphériques de bloc et vous devriez être capable de reconnaître le disque par sa taille.

Après cela, votre système devrait à nouveau démarrer normalement.

J'ai eu un problème similaire récemment. J'ai pu récupérer en suivant la réponse aquí .
J'ai documenté les étapes que j'ai suivies dans une nouvelle réponse.

J'ai copié ma réponse ici pour plus de commodité :

J'ai un PC sous Fedora 30. La partition de démarrage est sur /dev/sda3 et la partition racine est sur un LVLM nommé Fedora-root . J'ai exécuté toutes les commandes avec le compte root.

1. J'ai démarré depuis le live media de Fedora (depuis une clé USB).

2. Monter ma partition racine

   mount /dev/mapper/Fedora-root /mnt

3. Monter ma partition de démarrage

   mount /dev/sda3 /mnt/boot

4. Copiez le noyau de la partition live vers la partition de démarrage prévue.

   cp /boot/vmlinuz-$(uname -r) /mnt/boot/

5. Monter les partitions du système

   mount --bind /dev /mnt/dev
   mount --bind /sys /mnt/sys
   mount --bind /proc /mnt/proc

6. Changez la racine en /mnt

   chroot /mnt

7. Générer le initramfs

   dracut /boot/initramfs-$(uname -r).img $(uname -r) -v

8. Réinstaller Grub et le re-configurer

   grub2-mkconfig -o /boot/grub2/grub.cfg

Pour une raison que je ne connais pas, la génération de la initramfs était très lent et ne pouvait pas se terminer sur mon système (étape 6). Cependant, la commande a fonctionné normalement lorsque je n'ai pas chrooté le système de fichiers. J'ai donc sauté les étapes à partir de 3. J'ai également dû modifier le fichier dracut pour pointer vers le système racine.

Donc, les nouvelles étapes sont :

3. Pointez vers l'emplacement de la racine dans le dracut configuration

   echo "root=/dev/mapper/Fedora/root" > /etc/dracut.conf.d/kernel.conf

4. Réinstallez le kernel et générer le initramfs

   dracut /dev/sda/initramfs-$(uname -r).img $(uname -r) -v

5. J'ai ensuite suivi les étapes 3-6 ci-dessus, afin de pouvoir reconstruire la configuration Grub (cette étape n'est peut-être pas nécessaire, j'ai été trop prudent).

   mount /dev/mapper/Fedora-root /mnt`  
   mount /dev/sda3 /mnt/boot
   cp /boot/vmlinuz-$(uname -r) /mnt/boot/
   mount --bind /dev /mnt/dev
   mount --bind /sys /mnt/sys
   mount --bind /proc /mnt/proc
   chroot /mnt

6. Réinstaller Grub et le re-configurer

   grub2-install /dev/sda
   grub2-mkconfig -o /boot/grub2/grub.cfg

Note pour les propriétaires de NVIDIA
J'ai un GPU NVIDIA, et j'avais installé les pilotes propriétaires avant l'incident.
Le noyau restauré à partir du média live utilise les pilotes Nouveau (car c'est le pilote par défaut dans Fedora). Le noyau restauré n'était pas non plus la dernière version. Lorsque j'ai mis à jour le kernel après avoir utilisé l'interface graphique, il a utilisé les pilotes propriétaires de NVIDIA.