• Actualités
  • Fedora 24 et 25 Alpha : bogue important lors d'une mise à jour

Ce message fait suite à une discussion ayant eu lieu dans la liste de diffusion de développement de Fedora.

Il a été constaté que Fedora 24 et Fedora 25 Alpha sont touchés par un bogue lors d'une mise à jour du paquet systemd-udev.
Cela se manifeste quand sont réunies trois conditions qui sont :
  • Avoir une machine possédant deux unités graphiques, ce qui est le cas de beaucoup d'ordinateurs portables modernes ;
  • Exécuter la mise à jour par la commande dnf update dans un terminal graphique (comme GNOME Terminal, Konsole, etc.) ;
  • L'environnement graphique doit fonctionner sous X.org / X11 et non Wayland (Wayland n'étant par défaut que pour GNOME sur Fedora 25).
Dans ce cas, en cas de mise à jour du paquet dans ces conditions, le serveur X risque de crasher ce qui entraînera une coupure de la mise à jour en pleine opération et potentiellement une base de données des paquets et votre système dans un état incohérent (avec des paquets en double).

Pour éviter ce problème, vous pouvez faire :
  • Utiliser GNOME Logiciels pour les mises à jour, qui fait une mise à jour dite hors-ligne ;
  • Utiliser PackageKit pour effectuer vos mises à jour en mode hors-ligne* ;
  • Mettre à jour via les terminaux en mode texte du système (accessible via Ctrl+Alt+FX pour X valant 3 à 6) ;
  • Utiliser Wayland si vous êtes sur GNOME et Fedora 25 (sinon c'est déconseillé) ;
* La mise à jour hors ligne consiste à réaliser les mises à jour lors du démarrage de votre ordinateur, de manière similaire à Windows. L'objectif est de s'assurer qu'après la mise à jour tous les composants soient lancés effectivement à jour (ce qui n'est pas le cas quand vous le faite à chaud) mais aussi de réaliser cette opération dans un environnement minimal et contrôlé ce qui limite les problèmes. Depuis Fedora 18 c'est la méthode recommandée par le Projet Fedora et GNOME Logiciels en tire parti. Nous profitons de ce bogue pour vous rappeler de l'utilité de suivre cette procédure lors des mises à jour.

Pour faire cela en terminal avec PackageKit, vous pouvez exécuter les commandes suivantes avec les droits superutilisateur :
# pkcon refresh force
# pkcon update --only-download
# pkcon offline-trigger
# systemctl reboot
Le problème est en cours de correction auprès de systemd et de X11.
18 jours plus tard
Des nouvelles de ce bug ? (j'ai jeté un coup d'oeil à Bugzilla, mais c'est du chinois pour moi ...)
Faut-il continuer à passer par l'une des solutions de contournement, ou la situation est-elle à nouveau normale ?

Merci à ceux qui pourront m'/nous éclairer sur le sujet.
Rah non! Pas de windowsites aigu birdel! C'est quoi cette manie de faire comme eux??? A quand les mises à jour qui prennent des heures pour trois conneries et 360000 reboot???!!!

Pas envie de ramener du taff à la maison quoi!!!

Je n'ai pas eu le cas, a voir si il a été résolu depuis ce qui ne m'étonnerait pas.
VINDICATORs wrote:Rah non! etc.
😐 😐 😐
Moi y en a rien compris ...
Que cela rappel les mises à jours sous Windows.
VINDICATORs wrote:... voir si il a été résolu depuis ce qui ne m'étonnerait pas.
J'aimerais bien en être sûre avant de lancer une mise à jour catastrophique ...
@VINDICATORs:
Il ne faut pas prendre Microsoft et les développeur de Windows pour des nœuds nœuds, s'ils font ça c'est pour une bonne raison et nous en avons la preuve aujourd'hui et cela pourrait se reproduire.

La seule solution pour éviter cela est le cloisonnement des applications via Flatpack, mais cela ne concerne que les applications et non les couches basses du système.

@tosca

Rien ne t'empêche de faire tes mises à jour comme préconisé par le projet Fedora. Au contraire.
À priori le problème est résolu si ta machine est à jour à l'heure actuelle.
Renault wrote: @tosca

Rien ne t'empêche de faire tes mises à jour comme préconisé par le projet Fedora. Au contraire.
Renault wrote: C'est tout de même plus contraignant qu'un dnf update qui tourne en arrière-plan.
À priori le problème est résolu si ta machine est à jour à l'heure actuelle.
Tu as une information précise sur le sujet ?
Hum, je n'ai pas compris ta question. Tu parles à propos du bogue ou du moyen préconisé officiellement ?
Renault wrote:Hum, je n'ai pas compris ta question. Tu parles à propos du bogue ou du moyen préconisé officiellement ?
Je demande si le bug est corrigé, car j'aimerais pouvoir revenir à une méthode "normale" de mise à jour.
Et notamment à partir de quelle(s) version(s) de quel(s) paquet(s) la situation est "safe".
Normalement à partir de la version de systemd 229-16.fc24 c'est bon.
Renault wrote:Normalement à partir de la version de systemd 229-16.fc24 c'est bon.
OK, merci. Je me lance, alors ...
Renault wrote:@VINDICATORs:
Il ne faut pas prendre Microsoft et les développeur de Windows pour des nœuds nœuds, s'ils font ça c'est pour une bonne raison et nous en avons la preuve aujourd'hui et cela pourrait se reproduire.

La seule solution pour éviter cela est le cloisonnement des applications via Flatpack, mais cela ne concerne que les applications et non les couches basses du système.

@tosca

Rien ne t'empêche de faire tes mises à jour comme préconisé par le projet Fedora. Au contraire.
À priori le problème est résolu si ta machine est à jour à l'heure actuelle.
Je sais, j'en vois assez au taff . C'est juste que je tiens pas à le voir débarquer sous linux vu le bordel que cela provoque sous win.

Après je n'ai pas vu passer ce bogue, mais après je n'utilise la deuxième carte que pour l'affichage. Et non avec la possibilité d'utiliser l'une ou l'autre, ce qui explique sans doute pourquoi je ne l'ai pas vu.
> Après je n'ai pas vu passer ce bogue, mais après je n'utilise la deuxième carte que pour l'affichage. Et non avec la possibilité d'utiliser l'une ou l'autre, ce qui explique sans doute pourquoi je ne l'ai pas vu.

Note que ce bogue, même avec les conditions réunies, ne semble pas affecter tout le monde de manière systématique. Mais le taux reste élevé.
Mais peut être que ton cas de figure t'en a protégé, oui.
9 jours plus tard
Bonjour,
moi je galère, ça fait 5 fois que je réinstalle tout et ça commence à piquer un peu...
une mise à jour avec "pkcon" c'est près de 3h de téléchargement alors :-x
J'ai une install avec 2 cartes titan nvidia, un Raid 1 hybride et je vous dis même
pas comment je balise à chaque fois que je redémarre ma machine...
Le bogue n'a rien de résolu... ou alors il y en a plusieurs en même temps...
PackageKit évite de saturer le lien Ethernet que tu utilises pour ne pas t'empêcher d'utiliser d'autres services à la fois, d'où sa relative lenteur.

Sinon, comment tu procèdes, tu fais bien les mises à jour par dnf après que systemd soit à la version indiquée au moins ? Sinon c'est normal que tu aies des problèmes.
pour ne pas t'empêcher
gaffe aux doubles négations 🙂
Renault wrote:La seule solution pour éviter cela est le cloisonnement des applications via Flatpack, mais cela ne concerne que les applications et non les couches basses du système.
Même si c'est un peu hors sujet il existe des solutions pour mettre à jour les couches basses du système sans redémarrage sur certaines distributions comme Oracle Ksplice: http://www.ksplice.com/
Ksplice reste assez limité (toutes les parties du noyau ne sont pas compatibles, loin de là). Et il est de base difficile à mettre en œuvre. Généraliser son fonctionnement au reste des couches basses me semble délicat.