Lors d’une mise à jour Linux, du lancement d’une application GTK, ou de l’ouverture d’une image, vous pouvez tomber sur cette erreur :
(gtk-update-icon-cache-3.0:12015): GdkPixbuf-WARNING **:
Cannot open pixbuf loader module file
'/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache':
No such file or directory
This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.Langage du code : JavaScript (javascript)Le message peut apparaître dans le terminal pendant un apt upgrade, lors du lancement d’un logiciel graphique, ou quand une application ne parvient plus à ouvrir certains formats d’images.
Dans la plupart des cas, le problème vient du cache des loaders GdkPixbuf. Ce cache indique à GTK quelles bibliothèques utiliser pour charger les formats d’images : PNG, JPEG, WebP, SVG, TIFF, AVIF selon les paquets installés, etc.
La bonne nouvelle : ce cache se régénère. Et, dans beaucoup de cas, une seule commande suffit.
À quoi sert GdkPixbuf ?
GdkPixbuf est une bibliothèque utilisée par les applications GTK pour charger et manipuler des images. Elle ne contient pas forcément tous les chargeurs d’images en dur : elle s’appuie sur des modules, appelés loaders, pour gérer différents formats.
La commande gdk-pixbuf-query-loaders collecte les informations sur ces modules et écrit le résultat dans le fichier de cache par défaut, ou sur la sortie standard selon son mode d’appel. La page de manuel Debian décrit précisément ce rôle : collecter les informations sur les modules chargeables de GdkPixbuf et les écrire dans l’emplacement de cache prévu. :contentReference[oaicite:0]{index=0}
Si ce fichier loaders.cache manque, est vide, pointe vers de mauvais chemins, ou correspond à une autre architecture, les applications GTK peuvent ne plus savoir charger certains formats d’images.
Solution rapide : régénérer le cache GdkPixbuf
Sur Debian, Ubuntu, Linux Mint et distributions dérivées, commencez par cette commande :
sudo gdk-pixbuf-query-loaders --update-cacheCette commande régénère le cache des loaders à l’emplacement attendu par le système. C’est la méthode propre : elle évite de rediriger manuellement la sortie vers un chemin qui peut varier selon la distribution, l’architecture ou la version du paquet.
Ensuite, relancez l’application qui posait problème. Si l’erreur apparaissait pendant une mise à jour, terminez la configuration des paquets :
sudo dpkg --configure -a
sudo apt -f installPuis relancez une mise à jour normale :
sudo apt update
sudo apt full-upgrade
Vérifier que gdk-pixbuf-query-loaders est installé
Si la commande n’existe pas, installez ou réinstallez le paquet qui la fournit.
Sur Debian, Ubuntu ou Linux Mint :
command -v gdk-pixbuf-query-loaders
sudo apt update
sudo apt install --reinstall libgdk-pixbuf-2.0-0 libgdk-pixbuf2.0-binLangage du code : CSS (css)Le paquet libgdk-pixbuf2.0-bin fournit notamment les outils en ligne de commande comme gdk-pixbuf-query-loaders. La page de manuel Debian actuelle est publiée sous ce paquet. :contentReference[oaicite:1]{index=1}
Sur certaines versions récentes, les noms de paquets peuvent évoluer légèrement. Si apt ne trouve pas un paquet, cherchez les paquets disponibles :
apt search gdk-pixbuf
apt-file search bin/gdk-pixbuf-query-loadersSi apt-file n’est pas installé :
sudo apt install apt-file
sudo apt-file updateNe copiez pas aveuglément le chemin indiqué dans l’erreur
L’ancien message suggère parfois une commande de ce type :
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cacheLangage du code : JavaScript (javascript)Elle peut fonctionner dans certains cas, mais elle n’est pas idéale aujourd’hui. Le chemin dépend de l’architecture, du packaging, de la distribution et parfois de l’environnement d’exécution.
Sur une machine 64 bits classique, vous pouvez voir :
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cacheSur une installation 32 bits ou multi-architecture, le chemin peut être différent :
/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cacheDans un conteneur, une AppImage, un chroot, un environnement Nix, Flatpak ou un système embarqué, le chemin peut encore changer. Bref, écrire directement dans /usr/lib/... au hasard, c’est le genre de commande qui mérite un café avant, pas après.
Préférez donc :
sudo gdk-pixbuf-query-loaders --update-cache
Trouver le chemin réel du cache loaders.cache
Si vous voulez inspecter le cache généré, cherchez-le ainsi :
sudo find /usr/lib -path '*gdk-pixbuf-2.0*loaders.cache' -printLangage du code : PHP (php)Vous pouvez aussi vérifier les loaders disponibles :
gdk-pixbuf-query-loaders | head -n 40Ou chercher un format précis, par exemple PNG, JPEG ou WebP :
gdk-pixbuf-query-loaders | grep -Ei 'png|jpeg|jpg|webp|svg|tiff'Langage du code : JavaScript (javascript)Si la commande liste bien les loaders, mais que le cache manque, le problème vient probablement de la génération du cache. Si la commande ne liste presque rien, il faut plutôt regarder les paquets installés.
Réinstaller les loaders d’images courants
Si certaines images ne s’ouvrent plus, réinstallez les bibliothèques GdkPixbuf et les loaders SVG/WebP selon vos besoins.
Sur Debian, Ubuntu ou Linux Mint :
sudo apt update
sudo apt install --reinstall \
libgdk-pixbuf-2.0-0 \
libgdk-pixbuf2.0-bin \
librsvg2-commonLangage du code : CSS (css)Puis régénérez le cache :
sudo gdk-pixbuf-query-loaders --update-cachelibrsvg2-common est utile pour le rendu SVG dans beaucoup d’environnements GTK. Pour WebP, AVIF ou d’autres formats, le support dépend de votre distribution, de la version de GdkPixbuf et des paquets disponibles.
Réparer une mise à jour interrompue
Cette erreur apparaît parfois après une mise à jour interrompue, un paquet partiellement configuré ou une opération apt qui a échoué.
Dans ce cas, commencez par remettre le système de paquets dans un état cohérent :
sudo dpkg --configure -a
sudo apt -f install
sudo apt update
sudo apt full-upgradePuis régénérez les caches liés à GTK et aux icônes :
sudo gdk-pixbuf-query-loaders --update-cache
sudo gtk-update-icon-cache -f -t /usr/share/icons/hicolor 2>/dev/null || trueLangage du code : JavaScript (javascript)Si le problème était simplement dû à une configuration incomplète, cette séquence suffit souvent.
Cas multi-architecture : i386 et x86_64
Sur certains systèmes, notamment avec des paquets 32 bits installés sur une machine 64 bits, plusieurs architectures peuvent coexister.
Vérifiez les architectures activées :
dpkg --print-architecture
dpkg --print-foreign-architecturesLangage du code : PHP (php)Si i386 est activé, vous pouvez avoir des chemins de loaders en x86_64-linux-gnu et en i386-linux-gnu. Dans ce cas, réinstallez les paquets concernés pour les architectures utiles, puis régénérez le cache.
sudo apt install --reinstall libgdk-pixbuf-2.0-0:amd64 libgdk-pixbuf2.0-bin:amd64Langage du code : CSS (css)Si vous avez réellement besoin de l’architecture i386 :
sudo apt install --reinstall libgdk-pixbuf-2.0-0:i386Langage du code : CSS (css)Ne forcez pas l’installation i386 si vous n’en avez pas besoin. Le multiarch est utile, mais il ajoute vite des petits pièges de chemins et de dépendances.
Vérifier les variables d’environnement GdkPixbuf
Dans certains environnements particuliers, une variable d’environnement peut forcer GdkPixbuf à chercher le cache au mauvais endroit.
Vérifiez les variables liées à GdkPixbuf :
env | grep -i GDK_PIXBUFSi vous voyez une variable comme GDK_PIXBUF_MODULE_FILE qui pointe vers un ancien chemin, testez l’application après l’avoir désactivée temporairement :
unset GDK_PIXBUF_MODULE_FILELangage du code : PHP (php)Si le problème disparaît, cherchez où cette variable est définie : ~/.profile, ~/.bashrc, /etc/environment, script de lancement, AppImage, Flatpak, conteneur ou environnement de développement.
Vérifier que les images s’ouvrent à nouveau
Après réparation, testez avec une application GTK ou un outil qui utilise GdkPixbuf. Par exemple, ouvrez une image PNG ou JPEG avec votre visionneuse habituelle.
Vous pouvez aussi relancer l’application qui affichait l’erreur depuis un terminal :
eog image.pngLangage du code : CSS (css)Selon votre distribution, la visionneuse peut s’appeler autrement : eog, xviewer, loupe, ristretto, etc.
Si l’image s’ouvre et que l’avertissement GdkPixbuf ne revient plus, le cache des loaders est corrigé.
Checklist rapide de correction
Voici la séquence que j’utiliserais sur Debian, Ubuntu ou Linux Mint :
# 1. Vérifier que l’outil existe.
command -v gdk-pixbuf-query-loaders
# 2. Réinstaller les paquets utiles si besoin.
sudo apt update
sudo apt install --reinstall \
libgdk-pixbuf-2.0-0 \
libgdk-pixbuf2.0-bin \
librsvg2-common
# 3. Réparer une mise à jour incomplète.
sudo dpkg --configure -a
sudo apt -f install
# 4. Régénérer le cache des loaders.
sudo gdk-pixbuf-query-loaders --update-cache
# 5. Relancer la mise à jour système.
sudo apt full-upgrade
# 6. Vérifier le cache.
sudo find /usr/lib -path '*gdk-pixbuf-2.0*loaders.cache' -printLangage du code : PHP (php)Conclusion
L’erreur Cannot open pixbuf loader module file indique généralement que le cache des loaders GdkPixbuf manque ou pointe vers un mauvais emplacement.
La commande moderne à retenir est :
sudo gdk-pixbuf-query-loaders --update-cacheSi cela ne suffit pas, réinstallez les paquets GdkPixbuf, terminez la configuration des paquets avec dpkg --configure -a, puis relancez la génération du cache.
Évitez de copier-coller un chemin /usr/lib/x86_64-linux-gnu/... trouvé dans une vieille erreur sans vérifier votre architecture. Le cache des loaders doit être reconstruit proprement, pas bricolé.
