Bonjour à tous
Lors d'un upgrade debian 10->11 sur un dédié adv l'upgrade s'arrête avec le message:
```
GRUB failed to install to the following devices: │
│ │
│ /dev/sda │
│ │
│ Do you want to continue anyway? If you do, your computer may not start up properly. │
│ │
│ Writing GRUB to boot device failed - continue?
```
les disques installés:
```
# fdisk -l
Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: HGST HUS724040AL
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7C23BC22-5A94-4978-83CB-5758069CDBBC
Device Start End Sectors Size Type
/dev/sda1 2048 1048575 1046528 511M EFI System
/dev/sda2 1048576 1025046527 1023997952 488.3G Linux RAID
/dev/sda3 1025046528 1026093055 1046528 511M Linux swap
/dev/sda4 1026093056 7814023167 6787930112 3.2T Linux RAID
/dev/sda5 7814035215 7814037134 1920 960K Linux filesystem
Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: HGST HUS724040AL
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B3EDAB53-4974-43FA-AAF1-4E9FC1E7909C
Device Start End Sectors Size Type
/dev/sdb1 2048 1048575 1046528 511M EFI System
/dev/sdb2 1048576 1025046527 1023997952 488.3G Linux RAID
/dev/sdb3 1025046528 1026093055 1046528 511M Linux swap
/dev/sdb4 1026093056 7814023167 6787930112 3.2T Linux RAID
Disk /dev/md4: 3.2 TiB, 3475420151808 bytes, 6787929984 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/md2: 488.3 GiB, 524286885888 bytes, 1023997824 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
```
Puis-je continuer l'install et revenir sur grub plus tard ?
Bonjour,
@TTY, @janus57, @Fritz2cat avez-vous déjà été confronté à cette problématique?
^FabL
Bonjour,
Non… Je ne fait jamais de dist-upgrade, je change de serveur (surtout si pas d'accès local à la machine).
@Sich @JeanR ?
Mais changer de serveur ne vous oblige-t-il pas à tout reparamétrer, services, scripts spécifiques à la machine, etc… J'ai fait ça une fois, ça m'a pris la journée sans compter de multiples surprises par la suite qui m'ont recoûté une heure par par là.
J'ai donc choisi continuer et l'install s'est faite correctement, le système fonctionne. J'ai ouvert un incident et on m'a répondu de rebooter en mode rescue et faire une série de tests. Maus que se passera-t-il si le système ne reboot pas correctement après les tests ?
Mais changer de serveur ne vous oblige-t-il pas à tout reparamétrer, services, scripts spécifiques à la machine, etc... J'ai fait ça une fois, ça m'a pris la journée sans compter de multiples surprises par la suite qui m'ont recoûté une heure par par là.
Tous cela est vrai. Et c'est chiant parfois, quand Apache change sa syntax par exemple.
Mais il y a d'autres avantages à procéder ainsi :
- Les machines et surtout les disques sont renouvelés
- Le tarif à puissance équivalente baisse avec le temps
- J'ai une petite vingtaines de serveurs et une grosse partie du travail de migration est scripté ou avec les commandes à copier coller.
- Avec cette méthode je connais précisément la durée indisponibilité (je migre un serveur ayant une cinquantaine de clients en 1 heure... Vive l'IP failover).
- J'ai bien eu le temps de valider le fonctionnement de la nouvelle version de l'OS et d'adapter les scripts de post install.
etc.
Je ne dis pas que c'est ce qu'il faut faire, juste ce que je fait :)
Maus que se passera-t-il si le système ne reboot pas correctement après les tests ?
Dans ce genre de situation je ne rebooterai pas de suite et vérifierais à fond la configuration de Grub2.
Si le serveur ne boot pas sur ses disk, sélectionnez dans le manager le boot réseaux et le serveur devrait repartir (sans son noyau mais bon, les services seront UP).
Tu as tenté un grub-install sur toutes les partitions et tous les disques ?
Du genre grub-install /dev/sda puis sdb, puis sur les différentes partitions (vu qu'il y a du raid ça doit être du /dev/mdx).
Sinon pour le sujet de faire un dist-upgrade j'évite tjrs.
Plusieurs raisons :
- les merdes dans le genre rencontrées ici.
- les configs qui changent (du genre la config rzo, ou de certaines applis).
- généralement avec le temps OVH propose de nouveaux serveurs avec un meilleur rapport qualité / prix (on au mieux au même prix).
Après oui faut migrer les datas, mais ça à la limite osef.
Je préfère louer un nouveau serveur, le paramétrer (j'ai des scripts qui font 90% du taf en automatique), migrer les données, tout tester, puis déplacer mon IP FO.
Résultat quasiment pas de downtime, j'ai le temps de gérer les problèmes…
Faire une telle intervention en prod c'est risquer de se retrouver avec un serveur down pendant des heures (voir + ?) si on n'arrive pas à rebooter, si la config rzo n'est pas ok au reboot ou si des applis plantent car la config a bougé…
Théoriquement un grub-install sur toutes les partitions / disques devrait faire le job…
Faut pas hésiter à le faire sur à peu près tout…
Et si le reboot plante, bah rescue… du café, des cierges et si ça part trop en co…les … des calmants… Penser à couper le téléphone pour ne pas avoir les clients sur le dos aussi 
Merci pour vos infos. OK je vais tenter un grub install sur tous les disques.
Quant aux dist-upgrade, depuis 2003 que j'ai des serveurs apache2/php sous debian, j'ai eu une fois beaucoup de travail à reconfigurer apache quand ils sont passés à apache2, parfois quelques soucis avec mysql, ssh,.. mais sinon je n'ai pas le souvenir de grosses galères avec les dist-upgrade sur ce genre d'installation quand même assez rudimentaire.
Sur ma machine de dev avec beaucoup plus de logiciels, dont KDE, j'ai été obligé de repartir d'une distrib vierge une fois.
Par contre les changements de serveur, c'est vrai que j'en ai pas fait souvent et que j'ai peut-être pas les bonnes méthodes mais à chaque fois je l'ai senti passer car, outre les transferts de data, il y a toujours une foule de petits paramètres customisés dans tous les coins, vi, bash, firewall, scripts persos qu'il faut refaire,voire débugger. Et puis ça veut dire qu'il faut louer parallèlement 2 machines le temps de la migration. D'ailleurs à l'époque du changement de la config apache il aurait fallu reparamétrer tous les vhosts même en changeant de serveur. Les migrations 9,10,11 ne m'ont donné quasiment aucun travail qui m'ait laissé une trace douloureuse.
Pour le moment si je fais le bilan j'ai eu moins de casses avec les dist-upgrade qu'avec les changement de serveur. A vérifier sur ce coup là… je vais intervenir vendredi pour me laisser le WE si ça tourne mal.
Mais je vais être plus attentif sur ce que je peux automatiser la prochaine fois que je change de serveur.
Bonjour,
perso je fait tout en VM maintenant :
- je peux monter une VM de test a côté
- si de change de physique je transfert la VM
=> simplicité de gestion, et RGPD oblige, si le client souhaite ces données pour partir ailleurs il a le droit à la VM complète.
Cordialement, janus57
@Fritz2cat avez-vous déjà été confronté à cette problématique?
Bonjour,
Non pas en ce qui me concerne.
Je ne le ferais que sur un serveur non-prod de toute façon.
Après avoir fait un update-grub qui n'a généré aucun message d'erreur, j'ai rebooté en mode rescue, puis fait les tests des disques préconnisés par les services OVH et rebooté sur le disque dur sans aucun problème ou autre adaptation.
Bilan: upgrade 9->10->11 en somme toute quelques minutes d'intervention. Je n'ai encore jamais eu de rupture de service d'un client suite à un upgrade Debian en prod. La plus grosse intervention a été celle du fameux changement de configurations Apache qu'un changement de machine ne m'aurait pas épargné.
Je crois donc que je fais continuer à faire confiance à Debian si personne ne me traite d'hérétique 
Un grand merci à tous pour vos participations à ce fil
Bonne nouvelle, merci du retour