Suite à la tentative très moyennement couronnée de succès de mettre à jour la distribution Ubuntu server de la machine principale de LinuxFr.org vers une version un peu plus récente (et toujours supportée pour les mises à jour de sécurité), nous avions fini par récupérer un serveur vivant (encore merci aux admins de la fondation Free pour leur intervention), mais dans un état plutôt bancal.
La suite de cette dépêche, un tantinet auto-centrée mais susceptible d'intéresser certains d'entre-vous techniquement et/ou d'expliquer l'indisponibilité du mercredi 17 après-midi, est en seconde partie.
En effet, pour que le serveur démarre sans bloquer il fallait, dans cet ordre précis :
- Choisir le mode rescue dans Grub
- Choisir fsck dans le menu de recovery proposé par le système
- Choisir de continuer le démarrage normalement seulement après le fsck
Toute autre approche (comme tenter de continuer le démarrage normalement sans passer par le fsck) aboutissait à un blocage. Évidemment, pas moyen de réparer ça à distance, surtout avec une carte DRAC capricieuse et plus que limitée (cf. dépêche précédente). Nous avons donc décidé de la disponibilité de deux admins DLFP pour aller voir sur place ce qu'il en était et comment il était possible de réparer.
Premier état des lieux : en démarrage normal, l'écran devient tout noir (mais il reçoit toujours un signal VGA) juste après grub, et le serveur est dans un état qu'on peut qualifier de planté-mais-pas-tout-à-fait : pas de réseau, pas d'affichage, mais si on fait Ctrl-Alt-Suppr sur le clavier, il redémarre. En mode rescue, on voit bien le noyau démarrer (pas d'écran noir), et si on tente de continuer le démarrage sans fsck, il se bloque au moment de monter les partitions (mais il répond toujours au clavier si on fait Ctrl-Alt-Suppr).
Au bout de quelques essais, on constate qu'on peut tuer le processus qui bloque le démarrage (en jonglant avec les commandes alt-sysrq) : plymouthd. Les deux admins présents, plutôt habitués aux environnements debiannistes et sysv-istes, n'ont absolument aucune idée du boulot de ce daemon, et une brève recherche nous indique qu'il sert de splash screen graphique au démarrage, fonctionnalité absolument indispensable sur un serveur. Naturellement, le paquet mountall dépend de plymouth, on ne peut donc pas le virer. Impossible de trouver comment le désactiver dans la configuration d'upstart (le système de démarrage révolutionnaire d'Ubuntu qui fait afficher des splash screens sur les serveurs).
Après presque deux heures de bataille avec divers paramètres au démarrage (désactiver "quiet", activer "nomodeset", etc.), on décide de mettre à jour vers Precise Pangolin, en se disant qu'au pire ça continuera à planter comme actuellement, mais que de toute façon ça ne peut pas se dégrader davantage. Pendant la mise à jour, on constate que le mainteneur grub a eu la même idée que nous (désactiver "quiet" et activer "nomodeset"), merci. Premier redémarrage, plus d'écran noir ni de blocage, le bug qui nous affectait a donc été corrigé, même s'il a été décidé qu'il ne serait pas rétroporté vers la version précédente.
Gruik (oui c'est son petit nom), qui héberge le site web et quelques services, tourne donc maintenant sous Ubuntu 12.04 Precise Pangolin (LTS), les serveurs invités sont eux toujours en Debian Squeeze (et sans splash screen).
Quand à l'autre serveur, Zobe, il a été migré en Debian presque-Wheezy-qui-va-sortir-bientôt et son contrôleur RAID a été reconfiguré pour accepter de nouveau un disque dur qui était parti en vacances et ajouter deux nouveaux disques durs qui s'étaient matérialisés spontanément en son sein.
Aller plus loin
- Dépêche précédente sur la mise à jour de Gruik (266 clics)
# grub-console
Posté par NeoX . Évalué à 6.
dans le fichier /etc/default/grub
il est possible de forcer le boot en mode grub-console pour ne pas charger le systeme graphique
# re : Compte-rendu de l'intervention mercredi 17 avril
Posté par j (site web personnel) . Évalué à 4.
En mode rescue, on voit bien le noyau démarré …. hmmm ? démarrer ?
[^] # Re: re : Compte-rendu de l'intervention mercredi 17 avril
Posté par Lucas Bonnet . Évalué à 4.
C'est une idée :)
Corrigé, merci.
[^] # Re: re : Compte-rendu de l'intervention mercredi 17 avril
Posté par NilugeKiWi . Évalué à 1. Dernière modification le 26 avril 2013 à 17:26.
Encore raté.
[^] # Re: re : Compte-rendu de l'intervention mercredi 17 avril
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci. Ça doit être le comique de répétition qui permet des marrades.
# Upstart et Plymouth
Posté par ariasuni . Évalué à 9.
On fait bien des Windows Server alors…
Comment dire… C’est un peu comme si Xorg dépendait de NetworkManager.
Et pourtant c’est simple⸮
Et après on vient se plaindre de systemd…
Rho, mince!
P.-S.: oui vendredi, c’est vraiment dans trop longtemps.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Upstart et Plymouth
Posté par xcomcmdr . Évalué à 3. Dernière modification le 22 avril 2013 à 23:59.
Ça, c'est systemd.
Ubuntu ce serait plutôt :
Si c'est un script SysV.
Si c'est vraiment un bidule upstart (enfin il semblerait:
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Upstart et Plymouth
Posté par ariasuni . Évalué à 3. Dernière modification le 23 avril 2013 à 00:21.
Point d'ironie toussa…
Je savais que c'était pas clair mais je ne savais comment tourner la phrase. Mais en tout ça montre qu'Upstart est…compliqué.
P.-S.: tu as marché dedans!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Upstart et Plymouth
Posté par Marc Quinton . Évalué à 3.
compliqué ou différent … quel amalgame :-)
[^] # Re: Upstart et Plymouth
Posté par ariasuni . Évalué à 4. Dernière modification le 23 avril 2013 à 11:21.
Si la seule façon d'administrer Upstart est de modifier le nom de liens symboliques (avec un noexec à la fin? Mais d'où ça sort?), alors oui il est plus compliqué à administrer que systemd — systemctl un outil tellement pratique… Essaie donc de d'activer ou de désactiver plusieurs démons en même temps avec des mv…
Et les options de systemctl:
systemctl enable/disable/start/stop/restart/reload/etc machin[.service/socket/timer]
Des options claires, limpides même.
P.-S.: oui j'ai marché dedans. :D
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Upstart et Plymouth
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Ne jamais invoquer Cht******u dans un média public.
[^] # Re: Upstart et Plymouth
Posté par ariasuni . Évalué à 1.
Mécékoassa?
Écrit en Bépo selon l’orthographe de 1990
# Migration de Ubuntu vers Debian prévue ?
Posté par 0xfg (site web personnel) . Évalué à 5.
Vue les problèmes rencontrés avec Ubuntu Server, avez-vous planifiés une migration vers Debian ?
[^] # Re: Migration de Ubuntu vers Debian prévue ?
Posté par ariasuni . Évalué à 3.
La réponse est dans la dépêche précédente: non pour diverses raisons techniques.
Si je me souviens bien, il y avait l'intégration des conteneurs LXC et le support assez long des LTS comme arguments.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Migration de Ubuntu vers Debian prévue ?
Posté par laurent wandrebeck (site web personnel) . Évalué à 6.
Si on en est a parler de la longueur du support…CentOS ou Scientific Linux sont vos amies.
C'est précisément pour cela d'ailleurs que je n'installe que ça au boulot…en dehors de toute considération hautement intellectuelle du type rpm sapu et autres debian rulez, bien évidemment.
J'allais oublier, ça marche™ bien, c'est stable et je ne prendrais pas deux barils d'ubuntu LTS contre un baril de CentOS. Certes les repo sont un peu moins peuplés, mais vraiment rien de bien méchant…
Bref. C'était mes 0.02€ !
[^] # Re: Migration de Ubuntu vers Debian prévue ?
Posté par ariasuni . Évalué à 1.
Non mais cherche pas, Arch Linux a une durée de support illimitée… Et avec les dépôts AUR on a tout! :D
Plus sérieusement: mon serveur ssh/web/ftp/jabber (et bientôt courriel) tourne sous Arch Linux.
Écrit en Bépo selon l’orthographe de 1990
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.