Changer le UUID est un bon plan. Mais le problème est que, bien que le système puisse être techniquement utilisable maintenant, vous devez vous assurer de certaines choses. Toutes ces notes sont basées sur mes notes pour la configuration du serveur avec Ubuntu 12.04:
Ajustements de réseau: Vous ne savez pas ce que les paramètres réseau de l'ancienne configuration ont été comparés à ce qu'ils devraient être sur Vultr , mais il y a de fortes chances que cela doive être ajusté. Si vous pouvez vous connecter à la machine, je vous conseillerais ifconfig
de lancer une lecture brute des données d'interface. En ce qui concerne les ajustements de réseau, cela se produirait dans /etc/network/interfaces
lequel on peut voir / éditer comme ceci:
sudo nano /etc/network/interfaces
Cela dit, si vous pouvez atteindre la machine, il y a des chances qu'il y ait un paramètre DHCP? Peu importe, je chercherais à changer des choses et si vous ne savez pas comment faire, contactez le support Vultr, et dites-leur exactement ce que vous avez fait et ce que vous devez changer. Très confiant, ils écriront tout de suite avec une petite liste de paramètres de réseau à ajuster.
Update Grub: Cela peut être un problème ou non, mais vous devez vous connecter et exécuter la commande suivante:
sudo update-grub2
Cela forcera le système à mettre à jour les paramètres du chargeur de démarrage Grub. Mais si vous remarquez un délai, il se peut que le programme d’installation du chargeur d’amorçage Grub prenne le temps nécessaire. Parfois - et honnêtement, il m’a été difficile de déterminer quand et comment - Grub attendra apparemment toujours pour l’interaction de l’utilisateur lors de la sélection d’un périphérique d’amorçage. Si vous êtes sûr à 100% de ne pas avoir à démarrer avec autre chose que le noyau Ubuntu que vous avez en place, je vous recommanderais d'ajuster les paramètres Grub par défaut dans ce fichier:
sudo nano /etc/default/grub
Trouvez cette ligne:
GRUB_TIMEOUT=2
Maintenant, commentez-le - ou supprimez-le - puis remplacez-le par ce nouveau paramètre ainsi que par un paramètre supplémentaire GRUB_RECORDFAIL_TIMEOUT
comme celui-ci:
GRUB_TIMEOUT=0
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT
Maintenant, exécutez à nouveau la commande de mise à jour Grub:
sudo update-grub2
Et voyez ce qui se passe au redémarrage. Si c'était le cas, le redémarrage devrait être assez rapide par rapport à la version précédente.
Et passé tout cela, vous dites:
Il est également intéressant de noter que j’ai adopté cette approche car je souhaite conserver le nouveau serveur exactement tel que mon ancien / actuel, il est hors de question de reconstruire le serveur. Je n'ai tout simplement pas le temps.
Combien de temps avez-vous réellement économisé entre la migration, la confusion au sujet des paramètres et la dissociation maintenant? S'agit-il d'un problème de gain de temps perçu qui n'ajoute pas réellement du temps réellement gagné?
Ne vous méprenez pas; Je suis heureux d'aider. Mais en général, lors de la configuration des serveurs Linux - et principalement sous Ubuntu -, j’ai une formule très bien testée pour créer un serveur de base solide à partir de rien. Il me faut maintenant environ 1 heure pour le faire; peut prendre plus de temps en fonction de la vitesse du système, etc. Mais une fois que je dispose de cette base solide, la configuration des applications et des utilisateurs devient presque une réflexion après coup.
Ainsi, les perceptions de gain de temps peuvent faire face aux réalités inconnues de la copie par clonage pur, comme ceci: En installant une distribution Linux propre pour commencer, puis en construisant une base solide, vous rendez tous vos systèmes Linux plus portables. sans les «pièges» imprévus d’un tel processus de clonage.