Un billet d’humeur et d’humour qui risque de s’étaler un peu. Prenez donc un café ou un thé et dégustez les mésaventures de ma journée du 21 mars 2021. Vous allez comprendre pourquoi le dimanche est sûrement la pire journée pour avoir droit à un bug assez casse-bonbons.
Comme tous les matins, je mets à jour mon installation d’Archlinux. Dans le lot, je constate l’arrivée de la dernière révision en date du noyau Linux 5.11, le 5.11.8. Il y a d’autres mises à jour dans le lot, comme les premiers éléments de Gnome 40, comme la calculatrice et le moniteur système.
J’en profite pour en parler sur mes réseaux asociaux… euh, je voulais dire sociaux, comme Mastodon par exemple avec la capture d’écran à l’appui qui va bien.
Tout content, je redémarre. Puis je me dis qu’avec l’arrivée de ces éléments, il serait bien de voir ce que donne l’environnement sur sa distribution mère, la Fedora Linux. Je récupère donc une image d’une pré-bêta de la Fedora Linux 34. Je l’installe tranquillement dans une machine virtuelle Qemu dédiée en utilisant Virt-Manager.
Je décide donc de l’explorer un, histoire de prendre des notes pour un potentiel article. Comme j’aime travailler en musique, je lance Quodlibet et pas moins de 5 secondes plus tard, j’ai droit à un superbe plantage de ma session Gnome. Je récupère la main, un peu secoué par une telle mauvaise surprise.
Ma première idée est de rétrograder le noyau et les mises à jour jusqu’à trouver le paquet coupable. En gros, pour la première fois depuis que j’ai cette installation, je retourne sur les dépôts stables au lieu d’être en testing.
Oui, je sais, je cherche les ennuis en étant en testing, mais j’ai rarement eu des tracas auparavant, donc… Bref !
Mon premier suspect est la nouvelle version du noyau. En faisant quelques recherches, je tombe sur un rapport de bug proche de mon problème.
Mais ce n’est complètement celui-ci. Je préfère prévenir en parlant sur mes réseaux asociaux (encore une fois) d’un bug qui serait lié à cette version du noyau en ayant la fonctionnalité IOMMU désactivée. Mais cela se révelèra être une fausse piste.
J’ouvre un rapport de bug pour faire remonter mes ennuis. Je me dis qu’avec un peu de chance, un des mainteneurs de la distribution me donnera la solution.
Vous pouvez voir sur le rapport de bug que j’ai fait pas mal de tests. Mais c’est en étudiant le journal d’un plantage que le bout du tunnel commence à se faire voir.
Je trouve en effet deux messages qui ne sont pas lié au noyau mais à Gnome Shell :
mars 21 20:37:49 fredo-arch-gnome kernel: traps: gnome-shell[1057] general protection fault ip:7f77fe3a548a sp:7ffff9c48b10 error:0 in libmozjs-78.so[7f77fe2c2000+b72000]
mars 21 20:46:35 fredo-arch-gnome kernel: traps: gnome-shell[6087] general protection fault ip:7f7c7401fb07 sp:7ffebfbc3cf0 error:0 in libgjs.so.0.0.0[7f7c73fe7000+84000]
En faisant une recherche rapide, je tombe sur un composant, gjs qui a été mis à jour le matin même. Je décide donc de le faire rétrograder et miracle : je n’ai plus le crash. Je décide par acquis de conscience de retrouver les informations dans le fichier /var/log/pacman.log. Et je tombe sur ça :
[2021-03-21T08:49:24+0100] [ALPM] upgraded gjs (2:1.66.2-1 -> 2:1.68.0-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded libldap (2.4.57-1 -> 2.4.58-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded gnome-calculator (3.38.2-1 -> 40.0-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded gnome-screenshot (3.38.0-1 -> 40.0-2)
[2021-03-21T08:49:24+0100] [ALPM] upgraded gnome-system-monitor (3.38.0-1 -> 40.0-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded imagemagick (7.0.11.3-1 -> 7.0.11.4-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded libvirt (1:7.0.0-3 -> 1:7.1.0-3)
[2021-03-21T08:49:24+0100] [ALPM] upgraded libvirt-glib (3.0.0-2 -> 4.0.0-1)
[2021-03-21T08:49:24+0100] [ALPM] upgraded libvirt-python (1:6.4.0-3 -> 1:7.1.0-1)
[2021-03-21T08:49:25+0100] [ALPM] upgraded linux (5.11.7.arch1-1 -> 5.11.8.arch1-1)
[2021-03-21T08:49:29+0100] [ALPM] upgraded linux-headers (5.11.7.arch1-1 -> 5.11.8.arch1-1)
[2021-03-21T08:49:29+0100] [ALPM] upgraded virtualbox-host-modules-arch (6.1.18-19 -> 6.1.18-20)
[2021-03-21T08:49:29+0100] [ALPM] upgraded yelp-xsl (3.38.3-1 -> 40.0-1)
[2021-03-21T08:49:29+0100] [ALPM] upgraded yelp-tools (3.38.0-1 -> 40.0-1)
Mon intuition avait été la bonne. Un problème lié au composant gjs. Mais cela ne résolvait qu’à moitié le problème. C’est alors que la personne qui m’a aidé sur mon rapport de bug m’oriente vers une autre entrée sur l’outil de suivi.
Et d’un seul coup, je suis en terrain connu. Le problème rapporté ressemble comme deux gouttes d’eau au mien. En désactivant l’extension « gnome-shell-extension-appindicator« , je n’ai plus le moindre plantage, mais je perds une zone de stockage des icones de notifications.
J’avais passé la moitié de la journée à accuser le noyau mais c’était « tout simplement » une extension, point sensible de Gnome qui semble être cassée.
Inutile de préciser que j’avais passé sur le plan informatique, une mauvaise journée, et surtout la pire pour avoir un bug, un dimanche. Tout est bien qui finit bien même si cela fut long. Je me demande combien de personnes auraient changé de distribution en rencontrant ce genre de bug bien vicieux…
J’ai pu sauvé mon installation qui a dépassé les trois ans…
$ head /var/log/pacman.log -n 20
[2018-02-27 17:39] [PACMAN] Running 'pacman -r /mnt -Sy --force --cachedir=/mnt/var/cache/pacman/pkg --noconfirm bash bzip2 coreutils cryptsetup device-mapper dhcpcd diffutils e2fsprogs file filesystem findutils gawk gcc-libs gettext glibc grep gzip inetutils iproute2 iputils jfsutils less licenses linux logrotate lvm2 man-db man-pages mdadm nano netctl pacman pciutils pcmciautils perl procps-ng psmisc reiserfsprogs s-nail sed shadow sysfsutils systemd-sysvcompat tar texinfo usbutils util-linux vi which xfsprogs alsa-utils base-devel cpupower cups cups-pdf dialog efibootmgr ffmpegthumbnailer git grml-zsh-config grub gst-libav gst-plugins-bad gst-plugins-base gst-plugins-good gst-plugins-ugly gtk3-print-backends gtk-engine-murrine gvfs gvfs-mtp gvfs-smb libreoffice-fresh libreoffice-fresh-fr lightdm lightdm-gtk-greeter lightdm-gtk-greeter-settings linux-headers mate mate-extra mesa-libgl networkmanager network-manager-applet ntfs-3g pamac-aur pavucontrol pulseaudio pulseaudio-alsa screenfetch ttf-dejavu unzip vim wget wireless_tools wpa_actiond wpa_supplicant xdg-user-dirs xf86-video-ati xorg-apps xorg-server xorg-xinit xterm zsh zsh-completions zsh-syntax-highlighting'
[2018-02-27 17:39] [PACMAN] synchronizing package lists
[2018-02-27 17:44] [ALPM] transaction started
[2018-02-27 17:44] [ALPM] installed linux-api-headers (4.14.8-1)
[2018-02-27 17:44] [ALPM] installed tzdata (2018c-1)
[2018-02-27 17:44] [ALPM] installed iana-etc (20180221-1)
[2018-02-27 17:44] [ALPM] installed filesystem (2017.10-2)
[2018-02-27 17:44] [ALPM] installed glibc (2.26-11)
[2018-02-27 17:44] [ALPM] installed gcc-libs (7.3.0-1)
[2018-02-27 17:44] [ALPM] installed ncurses (6.1-3)
[2018-02-27 17:44] [ALPM] installed readline (7.0.003-1)
[2018-02-27 17:44] [ALPM] installed bash (4.4.019-1)
[2018-02-27 17:44] [ALPM] installed bzip2 (1.0.6-7)
[2018-02-27 17:44] [ALPM] installed attr (2.4.47-3)
[2018-02-27 17:44] [ALPM] installed acl (2.2.52-4)
[2018-02-27 17:44] [ALPM] installed gmp (6.1.2-1)
[2018-02-27 17:44] [ALPM] installed libcap (2.25-1)
[2018-02-27 17:44] [ALPM] installed gdbm (1.14.1-1)
[2018-02-27 17:44] [ALPM] installed db (5.3.28-3)
[2018-02-27 17:44] [ALPM] installed perl (5.26.1-2)
Comme le temps passe vite… Ce doit être sûrement une des plus vieilles installations d’Archlinux que j’ai jamais eu sous la souris, et pourtant je lui en fais voir de toutes les couleurs !
Comme quoi il ne faut surtout pas passer à Gnome 40 c’est l’apocalypse.
Ou simplement que certaines extensions auront besoin d’une mise à jour, comme à chaque montée en version de Gnome.
Que les bonnes volontés prêtes à essuyer les plâtres soient assurées de ma gratitude 🙂
Cela dit je ne risque rien, GNOME me met de mauvaise humeur dont je n’y touche plus. Ce qui ne m’empêche pas de faire mon marché sur https://download.gnome.org/sources/?C=M&O=D, bien pratique ce répertoire qu’on peut trier par date.
Que ça soit sur debian ou fedora, nous n’avons pas rencontré de souci avec GNOME.
Il faut dire que nous n’utilisons que des versions stable de cet environnement et pas d’extension (GNOME suffit comme tel à notre usage).
Votre commentaire fait penser à une lecture en diagonale de l’article.
Ensuite, un Gnome nu sur une Archlinux, une Debian, une Fedora sera toujours aussi stable. Si on rajoute des extensions à foison, ça cassera un jour ou l’autre.
Sur ce, je vous souhaite une bonne continuation.
Désolé que mon commentaire vous ait donné cette impression.
Pas de souci, aucun doute sur votre analyse. En ce domaine, vous avez certainement des compétences que je n’ai pas.
PS : concernant votre livre « le dragon et la princesse », il y a des fautes d’impression. Si vous le désirez, vous pouvez me joindre.
Parfois les impressions sont trompeuses. Quant à ce livre, je ne veux plus y toucher. Il doit rester quelques coquilles, ce n’est pas grave.
J’avoue que j’écris pour le plaisir, pas pour devenir riche et célèbre.
Bonne continuation.
« moins tu auras d’extension, mieux ta distrib se portera »
« moins tu seras en testing, ta tranquilité tu préserveras »
On ne peut pas avoir le beurre et l’argent du beurre et encore moins le c……
Exactement. Et il faut des personnes suffisamment casse-cou pour utiliser les versions de test pour que les autres soient tranquilles par la suite.
Effectivement beaucoup aurez download un ISO et se serait tirer ailleurs !
Vicieux quand même se bug fallait chercher quand même , les extensions sa posera toujours de petit soucis , comme les X addons qu’un utilisateur débutant install sous firefox et se plein qu’il devient lent …
Le bonheur en informatique, c’est quand on arrête de réparer ce qui fonctionne.
J’attendais de savoir combien de temps ça allait prendre avant qu’on se rende compte que les développeurs des extensions et ceux de l’environnement de bureau ne dansent pas au même rythme.
bon, ça, c’est fait.
Les extensions utilisent encore des librairies qui ne sont plus dans la nouvelle génération de Gnome.
Vive Mate ; dont les développeurs sont, comme tu le sais, des contributeurs d’Arch Linus, et vive XFCE.
Red Hat en ce moment fait dans la fantaisie. Ils viennent de lâcher le projet CentOS dont le code est repris par je ne sais combien de sociétés différentes, à commencer par Oracle. Ils ont tant bien que mal et plutôt mal que bien, tenté d’imposer un » Gnome Logiciels » ; qui sous Fedora est codé pour proposer par défaut l’installation de versions flatpak. Comme si un environnement de bureau avait vocation à jouer les gestionnaires de logiciels et de mises à jour.
Bref, depuis qu’ils appartiennent à IBM, c’est le cirque.
Réponses rapides à ce commentaire.
Les extensions tierces sont le point faible de Gnome, c’est connu. Si les développeurs tiers laissent crever leurs extensions, ce n’est pas de la faute de l’équipe de Gnome.
Ayant utilisé les trois environnements cités, désolé, mais je pense que Gnome colle plus avec l’hyperconnexion de l’informatique.
CentOS n’est pas laché, il est modifié pour devenir une version intermédiaire entre la Fedora et la RHEL.
Gnome Logiciels ? Il est né en 2013… pour Gnome 3.10, cf https://help.gnome.org/misc/release-notes/3.10/
Le rachat par IBM ? Juillet 2019 : https://www.redhat.com/en/about/press-releases/ibm-closes-landmark-acquisition-red-hat-34-billion-defines-open-hybrid-cloud-future
Quant aux flatpak, à l’origine les xdg-apps, ça remonte à 2007, avant que le projet ne prenne du poids à compter de 2013 : https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/
Sur ce, bonne continuation.
Salut,
Je suis moi aussi sur Archlinux/ Gnome et je n’ai pas été victime de ce bug. Comme pour les autres OS, des personnes peuvent être handicapées par un bug, et d’autres pour qui ça passe crème !
Est-ce que depuis qu’IBM a racheté Redhat Gnome pose plus de problèmes qu’avant?
Personnellement je ne vois aucune différence et j’ai adopté cet environnement de bureau depuis suffisamment longtemps pour avoir tout lu, tout entendu à son sujet … tout et son contraire !
Logiciels a toujours été une purge, lent, lourd, bugé… il parait qu’il y a une refonte de cette engeance, pour concurrencer Pamac va y avoir du boulot !
Redhat peut imposer tous les logiciels qu’il veut, tant que l’on peut les désinstaller pour les remplacer ça ne me va !
Je ne suis pas certain qu’avec Deepin on soit aussi libre de ses choix …
Simple remarque sur ta première remarque, étant d’accord avec le reste : peut-être n’as-tu pas un extension qui provoque ce bug ?
Mea-culpa tu as raison, je suis allé trop rapidement dans la lecture de ton message, je n’ai pas gnome-shell-extension-appindicator mais pamac updates indicator !
petite nuance… de taille, je te l’accorde 😉
Quoi que … attends, je me pose deux secondes, re-re vérification … gnome-shell-extension-appindicator … hummm… tu ne parlerais pas de celle-ci des fois ? 🙂 https://ibb.co/4gZgx4P
Gagné.
Ah mais celle-ci tourne rond chez moi !
Dans ce cas, tu as de la chance. Ce que je n’ai pas eu de mon côté.
Il y a quelques fois des choses bizarres avec ces extensions ! Nouvel exemple, il y a quelques mois j’ai eu avec Dash to panel une curieuse expérience, lorsque je lançais la grille des applications, il y avait une sorte de faux départ, une sorte d’hésitation .
Extension qui était installée via la page qui leur est dédiée.
Il a fallu que je la désinstalle et que je la réinstalle via Pamac pour me débarrasser de ce bug visuel assez désagréable!
Oui, de ce que j’ai compris, il vaut mieux privilégier en priorité les dépôts des distributions pour les extensions de Gnome (où on a une certaine garantie de compatibilité et une mise à jour synchronisée avec le reste de l’environnement), plutôt que le site de ce dernier où ça peut casser et obliger à réinstaller à la main à chaque nouvelle version.
Mais là, le bug de Fred s’est produit alors qu’il avait installé cette extension depuis les dépôts (d’où sa surprise), non ? Ah, non : dans la liste des paquets à mettre à jour sur la capture d’écran, il n’y a pas d’extension de Gnome…
Avant de finir : ça y est, Gnome 40 est officiellement sorti, maintenant. Peut-être que le souci est réglé, maintenant ?
Salut,
Merci pour tes précisions. Pour voir Gnome débarquer officiellement sur Arch, je pense qu’il va falloir attendre quelques jours, peut-être même une ou deux semaines.
Maintenant connaissant (un peu) Fred’ il ne serait pas étonnant d’apprendre qu’il ait installé cette nouvelle mouture, avant même que les devs d’Archlinux n’aient fini de boulotter leur tartine du p’tit déjeuner ! 🙂
Pour ta conclusion, tu es dans l’erreur. J’attends que les élements arrivent les uns après la autres.
Ce matin, par exemple, j’ai eu droit à en version Gnome 40:
Manque en gros gdm et le gnome-shell principalement.
Hummm … mais en fait tu as gardé tous les logiciels ! La maj devrait bien se passer ! Pour moi… peut-être un peu moins ! 😀
J’ai gardé une installation classique et complète de Gnome. Trop de personnalisation = explosion en vol.
Oui : sur XFCE, j’ai justement vu passer des éléments de Gnome (sic) en version 40 (simple-scan, gnome-font-viewer, adwaita-icon-theme, dconf-editor)… Au passage, je sais pas si ça vient du paquet ou pas, mais gnome-font-viewer 40 a tendance à segfault assez violemment (il s’ouvre, mais il se referme après 5 à 10 secondes ; peut-être que j’ai une police dans la liste qui lui plaît pas, va savoir). Heureusement que c’est pas un outil que j’utilise souvent !
Sinon, ce qui me surprend, c’est que ces paquets, conçus au départ pour Gnome 40 mais aussi préconisés pour compléter XFCE, ne dépendent pas de GTK4 (que Pacman ne m’a toujours pas proposé d’installer, tout comme Qt6). Ça ne doit pas encore concerner ces éléments périphériques.
Bonjour,
Il y’a des Dimanche comme ça….
« Les extensions tierces sont le point faible de Gnome, c’est connu. Si les développeurs tiers laissent crever leurs extensions, ce n’est pas de la faute de l’équipe de Gnome. » Tu as raison, mais c’est quand même de la faute des devs de Gnome si celui-ci ne supporte plus quelque chose d’aussi simple, que des notifications. Et qu’il faut avoir recours à une extension.
Quand tu utilises des outils ou tu dois voir en permanence l’état de synchro de dossiers/fichiers distant ce n’est pas du plus pratique.
Bien que Gnome sur mon système soit largement épuré, j’ai tenté le diable en faisant joujou avec : gnome-unstable repo !
A cette minute je suis donc entièrement sous Gnome 40 X11 et tout fonctionne très bien sauf que j’ai perdu la quasi totalité des extensions … il fallait s’y attendre ! Saluuuuuut 😉
Gnome unstable necessite aussi l’activation des dépôts de test. Les paquets manquants ne vont donc pas trop tarder. 48 heures, je dirais.
Je viens de regarder la liste des paquets, il en manque pas mal… Peut-être ceux déjà disponible sur extra ? Bref, on verra bien.
Ouioui tu as raison, ils sont aussi activés. Ce qui surprend d’emblée, c’est l’hyper réactivité de l’ensemble du système ! Vraiment surprenant !
Je ne suis pas trop étonné. J’ai pu voir cela dans une Fedora 34 beta que j’avais dans une machine qemu/kvm.
Sous Manjaro, j’ai vu passé hier la version 36 de « KStatusNotifierItem/AppIndicator Support » via l’application « Extensions ». Peut-être cela corrige le pb avec Gnome 40.
Apparemment, oui. https://github.com/ubuntu/gnome-shell-extension-appindicator/releases/tag/v36
« Fixes GNOME Shell crash related to gjs bug ». Quant à Gnome 40, je pense que ce sera l’occasion de faire une purge bien utile dans les extensions qui sont abandonnées depuis plusieurs versions de l’environnement.
Hello,
Pourquoi tu n’utilises pas Timeshift? Surtout avec une arch ou des fails de MAJ sont bien possibles.
Ce truc est génial. Même avec mon sys /home compris qui approche les 1To, une restauration prend entre 40mn et 1h.
Ca se setup en 10mn :
-Emplacement des snapshots (je les mets sur un LVM de 2 SSD mais un DD interne ou externe, ou une partoche ça marche tout aussi bien)
-Type de snapshot – Btrfs si tu utilises ce FS, sinon rsync classique
-Régularité des snapshots et nombre (quotidien, semaine, mensuel, au boot)
Le truc c’est qu’il faut au moins la taille de ton sys actuel en place. Tu peux gicler ou snapshoter ton /home, à toi de voir. Avec 30Go, tu peux déjà snapshot et en garder pas mal si tu prends pas le /home avec.
C’est hyper pratique. Tu peux restore via la GUI dédiée, en CLI si t’as flingué Xorg/wayland, et même via un liveUSB (moyennant l’installation de TS après avoir démarré le live) en GUI si t’as tout pété.
Ce truc a sauvé mon install plus d’une fois. Ca m’arrive des fois de vouloir tester des trucs à la con en dur. Je fais un snapshot « ondemand » avant, je pète tout, et dès que j’en ai marre, je restore, et un café et une ballade des chiens plus tard je retrouve mon système tel que je l’ai laissé avant de sortir la Tsar Bomba.
Penses-y, ce genre de petit outil est sous-coté mais ça te rend au final sacrément bien service quand t’as besoin
Je n’y ai tout simplement pas pensé. Timeshift est un excellent outil en effet. Je le mettrais en place un jour, quand l’envie m’en viendra 🙂