Je rencontre actuellement un problème avec mon serveur VPS sur lequel j'ai réalisé un upgrade de l'espace disque en passant de l'offre 20go à 80go. J'ai suivi le tutoriel dans l'espace documentation d'OVH (https://docs.ovh.com/fr/vps/repartitionner-vps-suite-upgrade/ ). Cependant après avoir redémarré mon serveur VPS, je remarque que je n'arrive plus à y accéder en SSH. Après vérification en mode KVM depuis le manager je remarque que le serveur essaye de boot mais bloque à la ligne "btrfs loaded"
Pas de snapshot mais toutes mes données sont sauvegardées et ma partition est intacte en mode Rescue. Je la monte sans problème et j'accède à tout son contenu.
Petit résumé de la situation : Je fais un upgrade de mon VPS : Essential-2-4-80 -> Comfort-4-8-160 Tout se passe bien et je constate que mon sda1 a été mis à jour automatiquement et affiche bien 155Go. Je constate une dégradation de la latence du disque en écriture : io.wait_w multiplié par 20. J'ouvre donc un ticket. On me répond que je dois suivre la procédure de redimensionnement du disque !? Soit ! Je suis donc la procédure indiquée et tout se passe sans accro. Mes partitions sont toujours là et pleinement accessibles. Je redémarre en mode normal. La procédure de démarrage bloque sur la ligne : btrfs loaded. Pas de timeout, pas de message d'erreur… J'appelle le support (?). On me dit que ça n'est pas leur problème car mon VPS démarre correctement en mode Rescue. Fin de l'histoire.
Donc en résumé, j'ai un VPS qui fonctionne avec une dégradation de la latence en écriture. J'applique les recommandations du support et je me retrouve avec un VPS qui ne démarre plus et un support qui me dit d'aller voir ailleurs…
Je me demande à partir de quel moment le support a commencé à se payer ma tête…
Maintenant, si quelqu'un a une idée pour me sortir de ce truc, je suis preneur.
PS: on notera que je ne suis pas le seul à avoir expérimenté ce problème… mais nous devons avoir fait les mêmes erreurs…
Bonjour à tous, je n'avais pas fais de retour concernant mon problème. La seule solution a été de réinstaller complètement mon VPS sachant que je n'avais pas effectué de snapshot juste avant l'upgrade…
Réinstallation pour moi aussi. En fait, le staff se refuse à toute investigation arguant du fait que le VPS démarre en rescue. Ça fait trois retours différents avec ce problème. Il faut donc croire que : - 3 personnes différentes ont fait exactement les mêmes erreurs. - ou la doc et les conseils fournis par OVH sont foireux
À noter qu'on trouve trace de ce bug dans 1 ou 2 forums mais c'est au delà de mes compétences, et que ça semble provenir du superviseur qui est hors de notre portée…
J'ai l'impression que la seule et unique solution c'est la réinstallation pourtant en mode rescue, les partitions sont bien présentes et accessibles mais impossible de démarrer. Je pense qu'il y a un soucis lors de la mise à niveau automatique du vps et qu'en suivant la doc par la suite … Mais on a aucune visibilité dessus.
Je viens d'avoir le même soucis, après un bon temps de recherche !!! dans la configuration ubuntu d'OVH on a un fichier : /etc/default/grub.d/40-force-partuuid.cfg Celui force le partuuid dans la configuration de grub
Bien entendu la partuuid change lors de la procédure de changement de taille
Il faut démarrer en mode rescue et modififier le partuuid dans ce fichier
