Archlinux.fr [Forums]

Bonjour à toutes et à tous,

Le problème est très récent, mais dès que je change de TTY (combinaison des touches Ctrl+Alt+Fx où x représente le TTY souhaité) le système plante.

L'unique moyen pour avoir une réponse du PC est de le redémarrer.

Au début c'est très légèrement « marrant » (tient, arch me fait des blagues), mais au bout de 3-4 fois c'est tout sauf marrant.

Le système est jour.

En navigant sur le web, j'ai vu passer des messages comme quoi que ça pouvait arriver après une mise en veille. Pour éteindre le poste, j'utilise la commande # shutdown -h now

La CG est une 00:02.0 VGA compatible controller: Intel Corporation CometLake-S GT2 [UHD Graphics 630] (rev 03) (intégré au processeur qui est un i5-10400)

Ça pourrait venir d'un problème d'instabilité, mais j'en doute.

Par acquis de conscience, je vais lancer un memtest.

Si vous avez des idées ou des conseils, je suis preneur.

Bon dimanche.

Bonjour,

Je me permets de revenir concernant la problématique.

J'ai effectué des tests du poste en question avec memtest (sur une bonne journée) : tout est OK, le poste est stable.

J'ai réalisé la même chose (changement de TTY) sur un autre poste également sous archlinux.
Je viens d'effectuer une mise à jour en même temps : les 2 PCs sont donc tous les 2 à jours avec la même version.

Sur le second, ça ne plante pas. La carte graphique n'est pas intégrée au processeur : elle est déportée.

Ce qui est un peu plus troublant, c'est que l'interface graphique est plantée mais le poste fonctionne toujours : j'ai lancé le lecteur en ligne moc sur un autre tty avant de faire le test.

Après le changement de tty, la musique tourne toujours mais rien ne répond (pas de clavier, moc en réagit pas : il est figé au niveau graphique).

Auriez-vous un ou deux tuyaux par hasard ?

Je vous remercie pour votre retour.

Bon week-end.

Je reviens vers vous rapidement pour donner quelques informations.

Avec un accès ssh, je m’aperçois que le poste est en réalité en attente d'un service.

Depuis htop, ça donne ça :

/usr/lib/systemd/systemd-userdbd
|__ systemd-userwork: waiting...
|__ systemd-userwork: waiting...
|__ systemd-userwork: waiting...

Il y a justement 3 tty.

Juste comme ça, il sert à quoi ce service ?

J'ai navigué un peu sur arch (anglophone) mais je ne cerne pas exactement son utilité (hormis la notion que ça a un rapport avec les enregistrements JSON / NSS UNIX/glibc et l'implémentation API (qui visiblement n'est pas content... Heu, L'Indien tu sors...) mais là je suis complètement à l'ouest) et je ne comprends pas en quoi tty est en attente de ce service.

Ça peut être grave Docteur si je désactive ce service ?

Si vous avez quelques idées pour m'éclairer...

Je vous remercie pour votre retour.

Bon week-end.

Bonjour, ceci n'a aucun lien... Moi aussi j'ai la même sortie sur un système parfaitement fonctionnel.
Il faudrait savoir si tu utilises Xorg ou Wayland, ton environnement de bureau. Les logs de Xorg (si applicable) et les logs du système.
Est-ce un PC fixe ou un PC portable ? As tu aussi une carte graphique dédiée ?
Quelle version de mesa utilises tu ? Quels sont les drivers graphiques que tu as installé ? Bref il nous faut beaucoup plus d'information afin de pouvoir t'aider
Attention de bien répondre à l'ensemble des questions, oui il y en a beaucoup...

Bonjour benjarobin

Merci pour ton retour.

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Bonjour, ceci n'a aucun lien...

Je te l'avoue... C'est juste une constatation de la situation.

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Moi aussi j'ai la même sortie sur un système parfaitement fonctionnel.

OK, merci pour l'info.

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Il faudrait savoir si tu utilises Xorg ou Wayland,

Xorg

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25ton environnement de bureau.

Openbox tout seul (avec des applications associées à d'autres environnement. Ex : dolphin, gnumeric)

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Les logs de Xorg (si applicable)

Oups, « petit » problème : même seul, il ne passe pas sur le forum... Pour une journée, le xorg fait 1145 lignes.

J'ai fait une extraction avec uniquement les warning.

WW a écrit :(WW) The directory "/usr/share/fonts/misc" does not exist.
(WW) The directory "/usr/share/fonts/OTF" does not exist.
(WW) The directory "/usr/share/fonts/Type1" does not exist.
(WW) Warning, couldn't open module intel
(WW) Warning, couldn't open module fbdev
(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support

Mais visiblement, le problème des 2 modules n'est pas grave (Merci benjarobin pour le retour)

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25les logs du système.

Les logs d'hier jusqu'à ce matin avec # journal -xb
Oups, « petit » problème : même seul, il ne passe pas sur le forum... Pour une journée, le système fait 5556 lignes.

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Est-ce un PC fixe ou un PC portable ? As tu aussi une carte graphique dédiée ?

C'est un PC fixe avec une carte graphique non dédiée : elle est intégrée au processeur.

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Quelle version de mesa utilises tu ?

La dernière mise à jour... Soit la 1:25.2.3-2

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Quels sont les drivers graphiques que tu as installé ?

C'est une bonne question, merci de l'avoir posée...

La carte étant intégrée au processeur, je ne me suis jamais posée cette question (réponse simplissime pour ne pas dire autre chose...).

benjarobin a écrit : ↑sam. 27 sept. 2025, 13:25Bref il nous faut beaucoup plus d'information afin de pouvoir t'aider
Attention de bien répondre à l'ensemble des questions, oui il y en a beaucoup...

J'espère que les réponses ont été claires...

Bon dimanche.

Bonjour,
Pour les logs tu as pleins de site qui permettent de les partager : https://wiki.archlinux.org/title/List_o ... n_services
Pour les logs, reproduit le problème puis donne les logs associés :
- Pour le log système, si tu as reboot, donne la sortie de : sudo journalctl -b -1
- Pour le log de Xorg, si tu as reboot, donne la sortie du fichier Old
Pour mesa tu as plusieurs version : mesa-amber ou mesa, mais d'après ton numéro de version cela correspond à mesa.
Quelle est la sortie de :

Code : Tout sélectionner

pacman -Qs xf86-
lsmod| grep i915
grep -Pvr "^ *#|^ *$" /etc/mkinitcpio.* /etc/modprobe* /usr/lib/modprobe* /etc/modules-load* /usr/lib/modules-load* /etc/X11/xorg.conf*

Merci Benjarobin pour ton retour.

2 liens vers les fichiers log :
Pour Xorg.0.log.old : https://paste.c-net.org/ChannelsGladly
Pour le log systeme : https://paste.c-net.org/CleanRussell.

Les retours des commandes :
# pacman -Qs xf86-

Code : Tout sélectionner

local/xf86-input-libinput 1.5.0-1 (xorg-drivers)
    Generic input driver for the X.Org server based on libinput
local/xf86-video-vesa 2.6.0-2 (xorg-drivers xorg)
    X.org vesa video driver

# lsmod| grep i915

Code : Tout sélectionner

i915                 4583424  12
drm_buddy              24576  1 i915
ttm                   102400  1 i915
drm_display_helper    266240  1 i915
cec                    90112  2 drm_display_helper,i915
i2c_algo_bit           24576  2 igb,i915
intel_gtt              28672  1 i915
video                  81920  1 i915

# grep -Pvr "^ *#|^ *$" /etc/mkinitcpio.* /etc/modprobe* /usr/lib/modprobe* /etc/modules-load* /usr/lib/modules-load* /etc/X11/xorg.conf*

Code : Tout sélectionner

/etc/mkinitcpio.conf:MODULES=()
/etc/mkinitcpio.conf:BINARIES=()
/etc/mkinitcpio.conf:FILES=()
/etc/mkinitcpio.conf:HOOKS=(base udev autodetect modconf block filesystems keyboard fsck mdadm_udev keymap shutdown)
/etc/mkinitcpio.conf:COMPRESSION_OPTIONS="-9"
/etc/mkinitcpio.d/linux-lts.preset:ALL_kver="/boot/vmlinuz-linux-lts"
/etc/mkinitcpio.d/linux-lts.preset:PRESETS=('default' 'fallback')
/etc/mkinitcpio.d/linux-lts.preset:default_image="/boot/initramfs-linux-lts.img"
/etc/mkinitcpio.d/linux-lts.preset:fallback_image="/boot/initramfs-linux-lts-fallback.img"
/etc/mkinitcpio.d/linux-lts.preset:fallback_options="-S autodetect"
/etc/mkinitcpio.d/linux.preset:ALL_kver="/boot/vmlinuz-linux"
/etc/mkinitcpio.d/linux.preset:PRESETS=('default' 'fallback')
/etc/mkinitcpio.d/linux.preset:default_image="/boot/initramfs-linux.img"
/etc/mkinitcpio.d/linux.preset:fallback_image="/boot/initramfs-linux-fallback.img"
/etc/mkinitcpio.d/linux.preset:fallback_options="-S autodetect"
/etc/modprobe.d/aliase-bond.conf:alias bond0 bonding
/etc/modprobe.d/aliase-bond.conf:options bond0 mode=0 miimon=100 max_bonds=1
/etc/modprobe.d/bonding0.conf:alias bond0 bonding
/etc/modprobe.d/bonding0.conf:options bond0 mode=0 miimon=100 max_bonds=1
/etc/modprobe.d/bonding.conf:alias bond0 bonding
/etc/modprobe.d/bonding.conf:options bond0 mode=0 miimon=100 max_bonds=1
/usr/lib/modprobe.d/bluetooth-usb.conf:options btusb reset=1
/usr/lib/modprobe.d/systemd.conf:options bonding max_bonds=0
/usr/lib/modprobe.d/systemd.conf:options dummy numdummies=0
/usr/lib/modprobe.d/systemd.conf:options ifb numifbs=0
/usr/lib/modprobe.d/virtualbox.conf:options kvm enable_virt_at_load=0
/usr/lib/modprobe.d/README:Files in this directory contain configuration for modprobe, a program to load
/usr/lib/modprobe.d/README:kernel modules.
/usr/lib/modprobe.d/README:See man:modprobe.d(5) for explanation of the configuration file format, and
/usr/lib/modprobe.d/README:man:modprobe(8) for a description of the program itself.
/usr/lib/modprobe.d/README:Use 'systemd-analyze cat-config modprobe.d' to display the effective config.
/etc/modules-load.d/virtualbox.conf:vboxdrv
/etc/modules-load.d/virtualbox.conf:vboxdrv
/usr/lib/modules-load.d/bluez.conf:crypto_user
/usr/lib/modules-load.d/virtualbox-host-modules-arch.conf:vboxdrv
/usr/lib/modules-load.d/virtualbox-host-modules-arch.conf:vboxnetadp
/usr/lib/modules-load.d/virtualbox-host-modules-arch.conf:vboxnetflt
/usr/lib/modules-load.d/cdrecord.conf:sg
/usr/lib/modules-load.d/virtualbox-host-modules-lts.conf:vboxdrv
/usr/lib/modules-load.d/virtualbox-host-modules-lts.conf:vboxnetadp
/usr/lib/modules-load.d/virtualbox-host-modules-lts.conf:vboxnetflt
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:Section "InputClass"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:	Identifier 	"Keyboard Layout"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:	MatchIsKeyboard	"yes"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:	MatchDevicePath	"/dev/input/event*"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:	Option		"XkbLayout" "fr"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:	Option		"XkbVariant" "latin9"
/etc/X11/xorg.conf.d/10-keyboard-layout.conf:EndSection
/etc/X11/xorg.conf.d/10-monitor.conf:Section "Monitor"
/etc/X11/xorg.conf.d/10-monitor.conf:	Identifier	"Monitor0"
/etc/X11/xorg.conf.d/10-monitor.conf:	Modeline	"1920x1080_60.00" 173.00 1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
/etc/X11/xorg.conf.d/10-monitor.conf:	Option		"PreferredMode" "1920x1080_60.00"
/etc/X11/xorg.conf.d/10-monitor.conf:EndSection
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:Section "InputClass"
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:	Identifier 	"Keyboard Terminate"
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:	MatchIsKeyboard	"yes"
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:	MatchDevicePath	"/dev/input/event*"
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:	Option		"XkbOptions" "terminate:ctrl_alt_bksp"
/etc/X11/xorg.conf.d/10-keyboard-terminate.conf:EndSection

Pour les 2 logs après le bug, je te les fais au plus tôt.

Bonne soirée.

Merci pour ces informations, comme cela pour l'instant rien d'anormal, ou presque :
Tu as quand même des applications qui crashes
- Pour ntpd cela ressemble plus à un problème de configuration, la question c'est pourquoi utiliser ntpd...
- Pour lxterminal je ne sais pas...

Merci de ne JAMAIS utiliser l'option -x de journalctl quand tu donnes les logs, cela les rends illisible et n'apporte aucune information supplémentaire.
Mais en effet les logs après le bug pourrait éventuellement aider à comprendre (ou pas) ton problème.

Merci benjarobin pour ta réponse rapide.

Désolé pour le # journalctl -xb, je n'ai pas le réflexe...

Ayant un système qui tourne normalement (hormis que je n'arrive plus à faire tourner des VM, mais bon ce n'est pas le sujet...), je me tourne rarement vers les logs...

benjarobin a écrit : ↑dim. 28 sept. 2025, 19:06 - Pour ntpd cela ressemble plus à un problème de configuration, la question c'est pourquoi utiliser ntpd...

Ça vient probablement du fait qu'il teste alors que le bonding n'est pas encore opérationnel. Je suis obligé de le lancer en root. C'est un peu relou pourtant je suis passer par un service.
C'est pas la mort après : juste avant de se loguer avec un utilisateur, je dois passer en root pour mettre le bonding.
J'utilise ntpd juste pour utiliser un serveur de temps. De souvenirs (très lointain), je me demande si ça ne vient pas du fait que les performances peuvent être plus faibles dans le cas d'accès fichier sur un serveur de fichier si les horloges ne sont pas synchronisées. Mais ça remonte à très longtemps... C'est peut-être périmé maintenant.

benjarobin a écrit : ↑dim. 28 sept. 2025, 19:06 - Pour lxterminal je ne sais pas...

Moi non plus. Pourtant, je l'utilise tout le temps...

Les logs tous frais :
# journalctl -b -1
Xorg.0.log.old

Et petite info en passant, les 3 lignes systemd-userwork: waiting... sont présentes avant le bug : c'est sûrement indépendant de la problématique.

Bonne soirée.

Tu peux remplacer ntpd par systemd-timesyncd. Cela fonctionne tout aussi bien.
Je regarde les logs... Honnêtement je ne sais pas trop... Problème avec ton xscreensaver ?
La bonne façon d'avancer est de se faire une configuration ultra minimaliste : Aucun lancement de Xorg automatiquement, rien de spécial, et utilisation de startx avec juste un xterm (pas de Windows manager), puis de vérifier que tu peux reproduire dans ces conditions. Si tu ne peux pas reproduire, il suffit de rajouter au fur et à mesure différents composants...

Bonjour benjarobin,

Merci pour ton retour.

Je viens de réaliser un test plutôt « rapide » étant pris par le temps...

Ayant un accès en ssh, j'ai pu arrêter les différents services/applications.

En stoppant openbox et xorg (et le script .xinitrc), je peux utiliser mon poste en normal et redémarrer une interface graphique (essai réalisé 5 fois environ).

Pour info, le scritp est le suivant (le même que sur le second poste avec la « même » config logicielle mais avec une carte CG dédiée) :

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
for f in /etc/X11/xinit/xinitrc.d/*; do
[ -x "$f" ] && . "$f"
done
unset f
fi

# exec gnome-session
# exec startkde
# exec startxfce4
# ...or the Window Manager of your choice
#exec ~/start-compiz.sh
exec dbus-launch openbox-session
exec openbox-session

Je continue les tests...

Bonne journée.

Je pense que ta configuration est fausse, cela fait maintenant longtemps que l'on ne doit plus lancer explicitement dbus-launch, que je sache c'est géré par systemd maintenant.
Il faut juste faire exec openbox-session
Donc tu peux supprimer la ligne exec dbus-launch openbox-session

Bonjour benjarobin,

Merci pour ton retour.

J'ai modifié ~/.xinitrc comme conseillé et effectué un nouvel essai. Et le résultat est identique.

Je t'avoue avoir hésité ensuite entre une épreuve de chute du PC, m'en servir comme billot ou ... sachant que ça ne résout absolument pas la problématique.

Enfin bref...

Avec les services minimums, le résultat était pareil.
Si le soucis ne vient pas de l'intérieur, c'est de l'extérieur.

J'ai changé de clavier, et là miracle. Nickel, pas de soucis. J'ai réalisé plusieurs fois le test de changement de tty et ça fonctionne normalement.
J'ai essayé en remettant le clavier : le dysfonctionnement se renouvelle.

Un petit détail m'a aidé pour en arriver à cette conclusion.

Rien de bien méchant : je n'arrivais plus à utiliser la touche « calculatrice » du clavier. Dans les lignes de commande au moment de lancer openbox (par un $ startx), il y avait les messages du type Could not resolve keysum XF86RaccourciApplication.

Ça coûte quoi de tester avec un autre clavier (hormis 5 minutes max...) ? Tout ça pour ça...

Merci pour tes informations benjarobin. Grâce à tes conseils, j'ai également pu avoir un système plus opérationnel qu'avant : un xinitrc plus propre, un système ntp sans bug et le bonding qui fonctionne au démarrage maintenant (car avant, je devais l’exécuter en manuel en root avant de me loguer sur ma session).

Bon week-end.

J'ai juste envie de dire comment c'est possible... C'est un clavier... Je ne vois aucun rapport... Jamais je n'aurais fait ce test.
C'est quoi la référence exacte de ton clavier ?
Si tu branches les 2 claviers (le premier qui pose problème, et le second), et que tu n'utilises pas le premier (branché, mais non utilisé), as-tu toujours le souci ? Est-ce que le premier clavier est fonctionnel à part le changement de TTY ? Et avec le second clavier, essaye de l'utiliser normalement et d'essayer de changer de TTY.

As-tu le même souci depuis un ISO d'installation d'Arch avec ce premier clavier ?

Edit : Je me demande si tu n'aurais pas un clavier avec des touches FN et que ce clavier aurait un bouton avec les touches FN d'activé.......
Tu n’aurais quand même pas ce clavier : Microsoft Sculpt Ergonomic Desktop, et tu n'aurais pas le bouton FN d'activé ?

Bonjour benjarobin

Merci pour ta réponse.

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14Tu n’aurais quand même pas ce clavier : Microsoft Sculpt Ergonomic Desktop,

Bien vu l'aveugle

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14 J'ai juste envie de dire comment c'est possible... C'est un clavier... Je ne vois aucun rapport... Jamais je n'aurais fait ce test.

Je t'avoue que c'est troublant pour ne pas dire incompréhensible...

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14C'est quoi la référence exacte de ton clavier ?

il est vieux, mais jusqu'à maintenant fonctionnel sur ce poste...

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14Si tu branches les 2 claviers (le premier qui pose problème, et le second), et que tu n'utilises pas le premier (branché, mais non utilisé), as-tu toujours le souci ? Est-ce que le premier clavier est fonctionnel à part le changement de TTY ? Et avec le second clavier, essaye de l'utiliser normalement et d'essayer de changer de TTY.

Pour commencer, le clavier qui déconne, je l'ai testé sur le second poste sous Arch en faisant la même manipe (changement de tty) et nickel : RAS. (mais c'est quoi ton problème avec mon poste CLAVIER ???? :mg:

)
J'ai effectué avec 2 claviers sans-fils (le microsoft (qui déconne) et un logitech). Les 2 branchés : peu importe sur quel clavier je tape (pas trop fort sur le microsoft même si l'envie chatouille un peu) il y a un blocage du poste. Juste le microsoft branché, le post est là pour ça et juste le logitech branché le post se serait pas là (...)

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14As-tu le même souci depuis un ISO d'installation d'Arch avec ce premier clavier ?

J'esssaye de voir ça si possible ce jour...

benjarobin a écrit : ↑sam. 04 oct. 2025, 18:14Edit : Je me demande si tu n'aurais pas un clavier avec des touches FN et que ce clavier aurait un bouton avec les touches FN d'activé.......
Tu n’aurais quand même pas ce clavier : Microsoft Sculpt Ergonomic Desktop, et tu n'aurais pas le bouton FN d'activé ?

L'idée m'a également traversée l'esprit, mais si la fonction « FN » est activée, il ne prend pas en compte les touches de « F1 » à « F12 » donc le changement de tty n'est pas possible.

En faisant les tests, j'ai récupéré quelques retours visuels. Voici un extrait des messages visible depuis l'écran :
error 140: BadRegion request 138 minor 14 serial 754208 sur un message le « serial » va de 753617 à 754324

et après

xsceensaver-systemd: 07:10:32: X connection closed(II) Server terminated successfully(0). Closing log file.l or sever shutdown).al 146912error 140: BadRegion request 138 minor 14 serial 146917error 140: BadRegion request 138 minor 14 ser

et juste après

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file. [i]1523 (Réseau désactivé)[/i]s for VT switcherror 140: BadRegion request 138 minor 14 serial 29155error 140: BadRegion request 138 minor 14 serial 29160xi

Je réalisé plusieurs fois le test, et il y a plusieurs scripts/applications qui sont mentionnées : xinit, xscreen-saver, VT switcherror, tint2, guake (et guake/session.json), AIGLX clients, VT switchlibEGL.

Pour libEGL, il y a un message qui se répète également libEGL warning: Ensure your X server supports DRI3 to get accelerated rendering

Pleins de messages sympa, mais concernant l'explication... C'est probablement une démonstration de l'incompatibilité entre 2 Mondes...

On est loin de ça, mais il y a de l'idée...

Bon week-end.

EDIT : Je viens de tester avec un live USB (un peu ancien... ==> Et un tout neuf...), mais ça fonctionne correctement (juste en live et en chroot). Je mets le dernier post en RÉSOLU même si je ne suis pas d'où vient le soucis (pourquoi ce p***** de clavier réagit comme ça sur ce poste en particulier... Mais bon, c'est pas la fin du monde non plus...)

Archlinux.fr [Forums]

[TTY] Freeze du système lors du changement (EN COURS...)

[TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (RÉSOLU)

Re: [TTY] Freeze du système lors du changement (EN COURS...)

Re: [TTY] Freeze du système lors du changement (RÉSOLU)