Bonjour,
J'ai décidé d'upgrader mon serveur dédié afin de retrouver une version plus récentes et non obsolète.
Pour ce faire, je suis parti de la version 7.4 (Wheezy) déployé initialement :
> root [/] > uname -r
> 3.8.13-xxxx-grs-ipv6-64
> root [/] > cat /etc/debian_version
> 7.4
> root [/etc/dovecot] > cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
> NAME="Debian GNU/Linux"
> VERSION_ID="7"
> VERSION="7 (wheezy)"
> ID=debian
> ANSI_COLOR="1;31"
Pour m'aider dans cette évolution,
j'ai suivi le tutoriel du domaine : prado.lt nommé : how-to-upgrade-debian-7-wheezy-to-10-buster-safely
Une recherche google : "prado.it how-to-upgrade-debian-7-wheezy-to-10-buster-safely" vous retourne l'url vers le tutoriel.
Ci-dessous le déroulé jusqu'à mon blocage actuel.
STEP 1 : OK
STEP 2 : OK
Vérification après STEP 2 :
> root [/] > uname -r
> 3.8.13-xxxx-grs-ipv6-64
> root [~] > cat /etc/debian_version
> 8.11
> root [~] > cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> NAME="Debian GNU/Linux"
> VERSION_ID="8"
> VERSION="8 (jessie)"
> ID=debian
J'attaque la STEP 3 afin de passer de Deb 8 à Deb 9 :
Mise à jours du /etc/apt/sources.list comme indiqué afin de pointer vers jessie et ai rencontré une erreur au moment de l'upgrade.
apt-get update : OK sans erreur
C'est à l'upgrade que j'ai rencontre un blocage :
> root [/] > apt-get upgrade
> Lecture des listes de paquets… Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état… Fait
> Vous pouvez lancer « apt-get -f install » pour corriger ces problèmes.
> Les paquets suivants contiennent des dépendances non satisfaites :
> consolekit : Casse: udev (< 204-1) mais 175-7.2 est installé
> E: Dépendances manquantes. Essayez d'utiliser l'option -f.
Après avoir rechercher plusieurs heures sur internet, j'ai trouvé que c'était un problème de boot sur le mauvais kernel.
Je ne suis pas certain de ce que je dois désormais faire.
D'après mes recherches, le devrais télécharger un nouveau kernel plus à jour, faire un update du grub et rebooter.
Mais je suis très frileux de perdre l'accès au serveur suite à ce reboot.
Voici l'état actuel du /boot :
> root [/boot] > ls -lrt
> total 9564
> -rw-r–r-- 1 root root 2674109 août 5 2013 System.map-3.8.13-xxxx-grs-ipv6-64
> -rw-r–r-- 1 root root 7102912 août 5 2013 bzImage-3.8.13-xxxx-grs-ipv6-64
> drwxr-xr-x 5 root root 12288 nov. 20 22:45 grub
> root [/boot] > ls -l grub/
> total 2380
> -rw-r–r-- 1 root root 110 août 14 2013 device.map
> drwxr-xr-x 2 root root 4096 nov. 20 18:34 fonts
> -r–r–r-- 1 root root 3731 nov. 20 22:45 grub.cfg
> -rw-r–r-- 1 root root 1024 oct. 10 2012 grubenv
> drwxr-xr-x 2 root root 12288 nov. 20 18:34 i386-pc
> drwxr-xr-x 2 root root 4096 nov. 20 18:34 locale
> -rw-r–r-- 1 root root 2400500 nov. 20 18:34 unicode.pf2
J'ai trouvé le tutoriel OVH pour mettre à jour le kernel, mais j'ai peur de choisir un mauvais kernel : (docs.ovh.com/gb/en/dedicated/updating-kernel-dedicated-server/)
Pourtant il semble que ce soit la solution d'après cette discution :
https://debian-facile.org/viewtopic.php?id=23058
Cette personne serait passé du 3.10.9-xxxx-grs-ipv6-64 au 4.9.142-xxxx-std-ipv6-64
Je serais tenter de :
1 - Prendre les fichiers présents dans : https://last-public-ovh-kernel.snap.mirrors.ovh.net/builds/4.19.158/1516830/bzImage/4.19.158-xxxx-std-ipv6-64/
2 - Les mettre dans mon /boot a côté de mes fichiers déjà présents
3 - Faire un "update-grub"
3,5 - Mon grub.d est déjà OK :
> root [/] > ls /etc/grub.d/
> 00_header 05_debian_theme 06_OVHkernel 10_linux 20_linux_xen 30_os-prober 30_uefi-firmware 40_custom 41_custom README
4- Faire un "reboot" & prier que le système soit dispo suite à ce reboot !
Et ensuite refaire un apt-get update / upgrade etc… (reprendre le tutorail d'évolution de Deb8 vers Deb9 qui ne devrait plus planter avec du udev.
=> Qu'en pensez-vous ?
Le rollback me semble compliqué, c'est pourquoi j'aimerais votre avis avant de me lancer !
Désolé du long pavé, mais j'ai voulu être bien précis afin de donner un maximum d'information pour que vous n'ayez pas à me demander des logs ou informations complémentaires.
D'avance merci pour votre aide.
Comme la nuit porte conseil, je vous dit bonne soirée et reviendrais voir vos réponses/conseils demain.
réponses/conseils demain.
Bonjour Alexandre,
Perso, pour passer de 7 à 10 j'aurais pris un nouveau serveur et fait une installation fraîche.
Avec les deux serveurs allumés ça permet de repartir sur de bases saines pour transférer ce qui doit l'être (et documenter au passage).
Par la même occasion tu te retrouverais sur un hardware plus moderne, car j'imagine que debian 7 n'est pas sur un VPS.
Bonjour Fritz,
Par la même occasion tu te retrouverais sur un hardware plus moderne, car j'imagine que debian 7 n'est pas sur un VPS.
=> Effectivement c'est un dédié.
Merci pour ce conseil, mais il ne me rassure pas.
J'ai vu également qu'il était possible de downgrader de Jessie vers Wheezy en modifiant les préférences de l'apt à ce que j'ai compris.
Comme ça :
Le mieux est de mettre dans le fichier preferences
Package: *<br />Pin: release o=Debian,n=wheezy,l=Debian<br />Pin-Priority: 1001<br />Package: *<br />Pin: release o=Debian,n=jessie,l=Debian<br />Pin-Priority: 490puis un update et un upgrade devrait retrograder tout en wheezy
Bonjour,
Très mauvaise idée de faire l'upgrade sur le même serveur. Tu serais obligé de faire tous les correctifs en catastrophe pour ne pas trop impacter la disponibilité de tes sites. Alors que sur un autre serveur, tu peux prendre tout le temps nécessaire à la validation.
Faire un upgrade puis downgrade, c'est le meilleur moyen d'avoir un système qui sera finalement instable et le cul entre deux chaises. Sans compter l'indisponibilité une nouvelle fois sur tes sites… Si ton but est de t'amuser, tu peux t'y risquer. Si ton but est de garder tes sites dispo, évite et prends un nouveau serveur.
D'accord, merci pour ces conseils éclairés.
Dans l'état actuel du serveur, pensez-vous qu'il est rebootable ou ça représent un gros risque ?
Pour rappel, cette situation est arrivée suite à un dist-upgrade en succès de 7.11 vers 8.11, un reboot (sur mauvais kernel), puis un update OK, upgrade ok, distr-upgrade en erreur udev.
L'idée serait de tenter une modification du kernel et rebooter voir si l'update upgrade fonctionne et arrêter là les mises à jours au profit de votre solution de monter un autre serveur en // pour faciliter la transition.
C'est exactement pour ça que je ne fais jamais d'upgrade…
Je prends tjrs un nouveau serveur…
Cela permet d'avoir une nouvelle offre, souvent + intéressante en ratio puissance / prix. Cela limite le temps d'indisponibilité des sites, permet de tester les sites sur le nouvel environnement avec de basculer en prod… Bref que du bon…
Dans l'état actuel des choses c'est compliqué de savoir si oui ou non tu vas pouvoir redémarrer… A part dire "bah essaie" je n'ai rien à te proposer…
Eventuellement passer par un boot sur un noyau ovh via le netboot si tu as un soucis…
Je rejoins ce que tous les autres ont dit… On migre sur un nouveau serveur, on ne fait pas de montée de version (surtout de 7 à 10)…
Courage vu la galère en cours !