Re: Alfresco 6.2 et debian/testing
Trouvé. Un strace du processus montre que tomcat essaie d'ouvrir un fichier d'eclipse. Après copie dudit fichier dans /var/lib/tomcat9/lib, ça fonctionne. Mais la moindre des choses qu'on puisse dire, c'est que l'erreur n'était pas très explicite. JB signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
Le 30/10/2024 à 19:23, BERTRAND Joël a écrit : [...] La question (pour les spécialistes Tomcat/Java) est donc : où se configure ce fichu compilateur Java ? [...] peut-être (sous réserve que je comprenne correctement ce qui n'est pas certain du tout) est-ce détaillé ici: https://tomcat.apache.org/tomcat-9.0-doc/jasper-howto.html "[...] The servlet which implements Jasper is configured using init parameters in your global $CATALINA_BASE/conf/web.xml. [...] compiler - Which compiler Ant should use to compile JSP pages. The valid values for this are the same as for the compiler attribute of Ant's javac task. If the value is not set, then the default Eclipse JDT Java compiler will be used instead of using Ant. There is no default value. If this attribute is set then setenv.[sh|bat] should be used to add ant.jar, ant-launcher.jar and tools.jar to the CLASSPATH environment variable. [...]"
Re: Alfresco 6.2 et debian/testing
Le 30/10/2024 à 19:23, BERTRAND Joël a écrit : Bonsoir, J'ai un peu progressé. Jasper.jar n'est plus fourni par Debian. J'ai donc copié jasper.jar dans /var/lib/tomcat9/lib (j'y avais déjà le connecteur postgresql). d'après https://packages.debian.org/search?searchon=contents&keywords=jasper.jar&mode=exactfilename&suite=testing&arch=any ce fichier est présent dans le paquet tomcat10-common et il ne semble plus y avoir dans trixie relatif à Tomcat9 que le paquet libtomcat9-java Tu restes volontairement en Tomcat9 bien que ce ne soit plus dans Debian depuis Bookworm: tu as installé Tomcat9 à partie des binaires de chez Apache? (question peut-être stupide, y a peut-être des avantages évidents à faire ça, mais Apache/Tomcat/Alfresco et compagnie me sont totalement étrangers)
Re: Alfresco 6.2 et debian/testing
Bonsoir, J'ai un peu progressé. Jasper.jar n'est plus fourni par Debian. J'ai donc copié jasper.jar dans /var/lib/tomcat9/lib (j'y avais déjà le connecteur postgresql). Mais je me prends encore l'erreur suivante : 30-Oct-2024 19:16:16.305 GRAVE [ajp-nio-127.0.0.1-8009-exec-9] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() du Servlet [jsp] dans le contexte au chemin [] a retourné une exception [java.lang.IllegalStateException: Aucun compilateur Java disponible] avec la cause java.lang.IllegalStateException: Aucun compilateur Java disponible at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:228) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:638) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) La question (pour les spécialistes Tomcat/Java) est donc : où se configure ce fichu compilateur Java ? Tomcat trouve tout ce qu'il faut (je vois les logs de tomcat tourner normalement) jusqu'au moment où je tente une connexion et où jasper.jar est chargé. Je fatigue d'autant que j'ai absolument de récupérer des documents qui sont dans les entrepôts alfresco... JB signature.asc Description: OpenPGP digital signature
Re: [HS] La sécurité de testing (Re: Alfresco 6.2 et debian/testing)
Sébastien NOBILI a écrit : > Bonjour, > > Je ne connais pas ton contexte et donc ma remarque ne sera peut-être pas > pertinente, > mais je la poste quand-même car elle pourrait éveiller la curiosité > d'autres. > > Testing est la branche de Debian avec le niveau de sécurité le plus > faible et ne > devrait pas être utilisée pour un serveur de prod potentiellement exposé > à des > attaques. > > https://wiki.debian.org/Status/Testing#Security Bonjour, Il faut faire des compromis. Et ici, le compromis est parfaitement acceptable. JB signature.asc Description: OpenPGP digital signature
[HS] La sécurité de testing (Re: Alfresco 6.2 et debian/testing)
Bonjour, Je ne connais pas ton contexte et donc ma remarque ne sera peut-être pas pertinente, mais je la poste quand-même car elle pourrait éveiller la curiosité d'autres. Testing est la branche de Debian avec le niveau de sécurité le plus faible et ne devrait pas être utilisée pour un serveur de prod potentiellement exposé à des attaques. https://wiki.debian.org/Status/Testing#Security Sébastien Le 2024-10-29 17:23, BERTRAND Joël a écrit : Bonjour à tous, J'utilise depuis des années Alfresco sur un serveur testing/amd64. Depuis la dernière mise à jour du serveur qui date de quelques jours, Alfresco ne fonctionne plus et je ne comprends pas pourquoi. La configuration d'Alfresco n'a pas changé. J'ai vérifié celle de Tomcat (9), le reverse proxy d'Apache, rien n'a changé. Lorsque j'essaie de me connecter sur Alfresco/share/page, j'obtiens bien la page de connexion, mais après la connexion, je n'ai plus qu'une page blanche. => le reverse proxy d'Apache tape bien sur Tomcat, lequel trouve le moyen d'afficher la page de connexion d'Alfresco. Dans les logs de Tomcat, je trouve ceci : 29-Oct-2024 17:14:27.337 GRAVE [ajp-nio-127.0.0.1-8009-exec-7] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() du Servlet [jsp] dans le contexte au chemin [] a retourné une exception [java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null]] avec la cause java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:237) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:1583) et là, je ne comprends pas. Pourquoi ce fichu truc ne trouve-t-il pas un compilateur java ? Lorsque je tape directement sur l'url du serveur (Alfresco tout court), je me prends comme réponse : HTTP Status 500 – Internal Server Error Type Exception Report Message java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] Description The server enc
Re: Alfresco 6.2 et debian/testing
On Tuesday 29 October 2024 18:46:42 BERTRAND Joël wrote: Ce ne serait pas lié à ta base de données et/ou ton serveur Web ? (qui sont en relation avec l'ECM).
Re: Alfresco 6.2 et debian/testing
ajh-valmer a écrit : > On Tuesday 29 October 2024 18:46:42 BERTRAND Joël wrote: > > Ce ne serait pas lié à ta base de données et/ou ton serveur Web ? > (qui sont en relation avec l'ECM). Alfresco se connecte correctement à la base de données (j'ai vérifié, c'est une postgresql). Et le serveur web fonctionne correctement, y compris le revers proxy pour tomcat. signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
didier gaumet a écrit : > Bonjour, > > Avertissement: je n'y connais absolument rien à tout ça: > > une recherche sur le message d'erreur et Alfresco m'a balancé plusieurs > résultat dont ton propre post sur le support Alfresco et ce post-là qui > m"a l'air, de loin, à peu près en rapport avec ton cas: > https://stackoverflow.com/questions/45937784/how-to-resolve-java-lang-illegalstateexception-no-java-compiler-available-for-c > > > peut-être (ou non) que ça t'éclairera un peu. > Pas la peine de m'en demander plus: tu as compris que sur le sujet je > tâtonne dans le noir donc si tu entends un grand bruit c'est que je me > suis cassé la gueule en heurtant quelque chose ;-) > Merci pour l'effort, mais ça ne s'applique pas ici (c'est l'un des premiers liens qui sort). signature.asc Description: OpenPGP digital signature
Re: Alfresco 6.2 et debian/testing
Bonjour, Avertissement: je n'y connais absolument rien à tout ça: une recherche sur le message d'erreur et Alfresco m'a balancé plusieurs résultat dont ton propre post sur le support Alfresco et ce post-là qui m"a l'air, de loin, à peu près en rapport avec ton cas: https://stackoverflow.com/questions/45937784/how-to-resolve-java-lang-illegalstateexception-no-java-compiler-available-for-c peut-être (ou non) que ça t'éclairera un peu. Pas la peine de m'en demander plus: tu as compris que sur le sujet je tâtonne dans le noir donc si tu entends un grand bruit c'est que je me suis cassé la gueule en heurtant quelque chose ;-)
Alfresco 6.2 et debian/testing
Bonjour à tous, J'utilise depuis des années Alfresco sur un serveur testing/amd64. Depuis la dernière mise à jour du serveur qui date de quelques jours, Alfresco ne fonctionne plus et je ne comprends pas pourquoi. La configuration d'Alfresco n'a pas changé. J'ai vérifié celle de Tomcat (9), le reverse proxy d'Apache, rien n'a changé. Lorsque j'essaie de me connecter sur Alfresco/share/page, j'obtiens bien la page de connexion, mais après la connexion, je n'ai plus qu'une page blanche. => le reverse proxy d'Apache tape bien sur Tomcat, lequel trouve le moyen d'afficher la page de connexion d'Alfresco. Dans les logs de Tomcat, je trouve ceci : 29-Oct-2024 17:14:27.337 GRAVE [ajp-nio-127.0.0.1-8009-exec-7] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() du Servlet [jsp] dans le contexte au chemin [] a retourné une exception [java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null]] avec la cause java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:237) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:597) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:779) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:227) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360) at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.base/java.lang.Thread.run(Thread.java:1583) et là, je ne comprends pas. Pourquoi ce fichu truc ne trouve-t-il pas un compilateur java ? Lorsque je tape directement sur l'url du serveur (Alfresco tout court), je me prends comme réponse : HTTP Status 500 – Internal Server Error Type Exception Report Message java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] Description The server encountered an unexpected condition that prevented it from fulfilling the request. Exception org.apache.jasper.JasperException: java.lang.IllegalStateException: Aucun compilateur Java disponible pour les options de configuration compilerClassName : [null] et compiler : [null] org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:589) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrap
Re: Fail2ban testing
Olivier a écrit : > Quelques pistes: > - soit n'arrive pas à accéder à une ressources parce qu'une autre > instance de fail2ban ou d'un service, a déjà l'accès exclusif à cette > ressource > - soit un simple problème de droits d'accès sur cette ressource > (droits sur le fichier, son répertoire, ...) > - soit une règle de fail2ban relative à ZoneMinder, n'est plus utilisable Je vais regarder ça, mais j'ai déjà désactivé à la main toutes les règles sans succès. Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: Fail2ban testing
Quelques pistes: - soit n'arrive pas à accéder à une ressources parce qu'une autre instance de fail2ban ou d'un service, a déjà l'accès exclusif à cette ressource - soit un simple problème de droits d'accès sur cette ressource (droits sur le fichier, son répertoire, ...) - soit une règle de fail2ban relative à ZoneMinder, n'est plus utilisable Le lun. 24 juin 2024 à 08:48, BERTRAND Joël a écrit : > > Bonjour à tous, > > Je viens de mettre un serveur de test à jour et fail2ban râle. Je ne > vois pas ce qui ne lui plaît pas d'autant qu'il n'est pas verbeux. > > Ma configuration fail2ban fonctionne parfaitement avec la version > 1.0.2-2. Avec la version poussée dans testing (1.1.0-4), je me prends > l'erreur suivante : > > 2024-06-24 08:20:42,067 fail2ban.transmitter[3910]: ERROR Command > ['server-stream', [['set', 'syslogsocket', 'auto'], ['set', 'loglevel', > 'INFO'], ['set', 'logtarget', '/var/log/fail2ban.log'], ['set', > 'allowipv6', 'true'], ['set', 'dbfile', > '/var/lib/fail2ban/fail2ban.sqlite3'], ['set', 'dbmaxmatches', 10], > ['set', 'dbpurgeage', '1d'],... > ['start', 'recidive'], ['start', 'zoneminder']]] has failed. Received > OSError(38, 'Function not implemented') > > Je suppose qu'il y a quelque chose qui ne lui plaît pas dans ma > configuration. J'ai donc essayé de lancer fail2ban en console pour avoir > plus d'information (sans aucun succès) puis de désactiver les pans de la > configuration les uns après les autres. Même résultat. > > Comment savoir ce qui ne lui plaît pas et quelle est cette "function > non implemented" ? > > Bien cordialement, > > JB > >
Fail2ban testing
Bonjour à tous, Je viens de mettre un serveur de test à jour et fail2ban râle. Je ne vois pas ce qui ne lui plaît pas d'autant qu'il n'est pas verbeux. Ma configuration fail2ban fonctionne parfaitement avec la version 1.0.2-2. Avec la version poussée dans testing (1.1.0-4), je me prends l'erreur suivante : 2024-06-24 08:20:42,067 fail2ban.transmitter[3910]: ERROR Command ['server-stream', [['set', 'syslogsocket', 'auto'], ['set', 'loglevel', 'INFO'], ['set', 'logtarget', '/var/log/fail2ban.log'], ['set', 'allowipv6', 'true'], ['set', 'dbfile', '/var/lib/fail2ban/fail2ban.sqlite3'], ['set', 'dbmaxmatches', 10], ['set', 'dbpurgeage', '1d'],... ['start', 'recidive'], ['start', 'zoneminder']]] has failed. Received OSError(38, 'Function not implemented') Je suppose qu'il y a quelque chose qui ne lui plaît pas dans ma configuration. J'ai donc essayé de lancer fail2ban en console pour avoir plus d'information (sans aucun succès) puis de désactiver les pans de la configuration les uns après les autres. Même résultat. Comment savoir ce qui ne lui plaît pas et quelle est cette "function non implemented" ? Bien cordialement, JB signature.asc Description: OpenPGP digital signature
Re: [testing] plus de session graphique !
Merci ! :) Le 18 mars 2024 08:50:26 GMT+01:00, "Sébastien NOBILI" a écrit : >Bonjour, > >Le 2024-03-17 15:53, Gaëtan Perrier a écrit : >> Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets >> libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme >> plus disponibles j'ai perdu ma session graphique. Elle s'est fermée >> pendant la mise à jour ... > >Le fichier /var/log/apt/history.log permet de retrouver l'historique APT. > >Sébastien > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [testing] plus de session graphique !
Bonjour, Le 2024-03-17 15:53, Gaëtan Perrier a écrit : Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme plus disponibles j'ai perdu ma session graphique. Elle s'est fermée pendant la mise à jour ... Le fichier /var/log/apt/history.log permet de retrouver l'historique APT. Sébastien
Re: [testing] plus de session graphique !
Non, il faut chercher la commande correspondante pour gnome, à lancer en tant que utilisateur. Ou lightdm ou qc de ce genre pour lancer le gestionnaire de connexion graphique installé. Mais si X ne fonctionne pas du tout, ça ne peut pas fonctionner non plus Klaus
[resolu] Re: [testing] plus de session graphique !
Problème résolu ! Je ne sais pas comment ça s'est fait mais gdm3, gnome-shell et gnome- session avaient été déinstallés ... Après les avoir remis tout est rentré dans l'ordre. Ouf ! Gaëtan
Re: [testing] plus de session graphique !
Le dimanche 17 mars 2024 à 16:47 +0100, Gaëtan Perrier a écrit : > Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit : > > > > Salut, > > > > j'ai parfois un problème du même genre sous instable. Comme > > workaround, > > je démarre XFCE4 en tty avec "startxfce4". > > > > Pour Gnome, est-ce que c'est startx ? > > Gaëtan > Si je lance startx, j'ai un écran noir avec curseur de la souris uniquement. Gaëtan
Re: [testing] plus de session graphique !
Le dimanche 17 mars 2024 à 16:25 +0100, Klaus Becker a écrit : > > Salut, > > j'ai parfois un problème du même genre sous instable. Comme > workaround, > je démarre XFCE4 en tty avec "startxfce4". > Pour Gnome, est-ce que c'est startx ? Gaëtan
Re: [testing] plus de session graphique !
J'ai pu lancer synaptic via ssh -X et j'ai pu constater que le problème n'est pas lié aux paquets que je voulais retirer car en fait ils n'ont pas été retirés. Le plantage de X est donc intervenu juste avant et sans rapport. C'est donc liés aux mises à jours d'aujourd'hui... Le dimanche 17 mars 2024 à 15:53 +0100, Gaëtan Perrier a écrit : > Bonjour, > > Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets > libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme > plus disponibles j'ai perdu ma session graphique. Elle s'est fermée > pendant la mise à jour ... > Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog > ou > dans journalctl. > J'utilise les pilotes nvidia-legacy-driver-390xx. > J'ai juste le service ocserv qui est failed mais je ne pense pas que > ça > ait un lien ? > Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les > retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui > est sous stable mais je ne vois pas de paquet pouvant correspondre > ... > > C'était un nom court et dans un des deux il me semble qu'il y avait > 64. > > Si quelqu'un a une idée je suis preneur. > > Gaëtan >
Re: [testing] plus de session graphique !
Am 17/03/2024 um 15:53 schrieb Gaëtan Perrier: Bonjour, Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme plus disponibles j'ai perdu ma session graphique. Elle s'est fermée pendant la mise à jour ... Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou dans journalctl. J'utilise les pilotes nvidia-legacy-driver-390xx. J'ai juste le service ocserv qui est failed mais je ne pense pas que ça ait un lien ? Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui est sous stable mais je ne vois pas de paquet pouvant correspondre ... C'était un nom court et dans un des deux il me semble qu'il y avait 64. Si quelqu'un a une idée je suis preneur. Gaëtan Salut, j'ai parfois un problème du même genre sous instable. Comme workaround, je démarre XFCE4 en tty avec "startxfce4". librement Klaus
[testing] plus de session graphique !
Bonjour, Suite à la mise à jour d'aujourd'hui et au nettoyage de deux paquets libt* (je ne me souviens pas du nom exact) qui étaient indiqués comme plus disponibles j'ai perdu ma session graphique. Elle s'est fermée pendant la mise à jour ... Depuis elle ne démarre plus mais je ne vois pas d'erreur dans syslog ou dans journalctl. J'utilise les pilotes nvidia-legacy-driver-390xx. J'ai juste le service ocserv qui est failed mais je ne pense pas que ça ait un lien ? Bref j'aimerai remettre ces 2 paquets libt* mais pas moyen de les retrouver. J'ai regardé sur la machine depuis laquelle j'écris et qui est sous stable mais je ne vois pas de paquet pouvant correspondre ... C'était un nom court et dans un des deux il me semble qu'il y avait 64. Si quelqu'un a une idée je suis preneur. Gaëtan
Re: compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40
Bonjour Basile, Mon avis à deux sous d'internaute vaut ce qu'il vaut, et je ne suis pas à l'abri de me prendre les pieds dans le tapis, donc n'hésitez pas à prendre d'autres avis par ailleurs avant d'engager des frais. En particulier, je décline toute responsabilité s'il devait y avoir un ou des pépins après achat. ;) Basile Starynkevitch, on 2024-02-22: > Est ce ia carte mère et le processeur susdits sont compatible Debian > Testing? En particulier pour faire tourner un serveur Xorg et Gimp. Je > m'interroge sur la compatibilité de la carte mère avec le coprocesseur > graphique du AMD Ryzen 7 8700G. Je ne vois pas d'objections : les nouvelles moutures de l'installateur Debian devraient automatiquement ajouter les microprogrammes nécessaires au bon fonctionnement du processeur et de sa puce graphique embarquée. Évidemment, le diable se cache dans les détails, et on n'est pas à l'abri que certains composants se trouvent être retors : cartes réseau, puces WiFi, ce genre de choses. En fait, ce pourrait être intéressant à la fin de l'installation de la machine de rédiger un rapport via le système de suivi de bogues, pour indiquer à l'équipe en charge de l'installateur ce qui s'est bien passé et ce qui s'est moins bien passé : $ reportbug installation-reports Pour le moment, aucun des rapports d'installation[1] ne semblent concerner les cartes mères à chipset B650, ce qui suggère que : soit elles n'ont pas de problèmes, soit personne ne s'en sert. [1] : https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports > (l'usage principal étant le traitement d'images numériques, notamment avec > Gimp et Inkscape; accessoirement la compilation par GCC) > > Pour ceux qui connaissent materiel.net les composants qu'on souhaite > assembler sont listés en https://materiel.net/s/5CKV6K et vos critiques > constructives sont bienvenues (pour un usage professionnel pour un > photographe professionnel) Pour éviter de perdre du temps sur de la casse, surtout pour un usage professionnel où le temps est littéralement de l'argent, est-ce que ça ne vaudrait pas le coup de rajouter un disque pour constituer une colonne Raid 1, et ainsi éviter de perdre une journée de travail à jongler avec des sauvegardes lors de la panne du disque ? Attention, le Raid 1 ne remplace pas la mise en place d'une stratégie de sauvegarde. Autrement, compter uniquement sur une puce graphique embarquée peut paraître un peu léger pour un usage professionnel, mais la configuration a l'air suffisamment solide pour rajouter une carte graphique dédiée après coup, si la puce intégrée devait être insuffisante. Bonne journée, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/0, please excuse my verbosity. signature.asc Description: PGP signature
compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40
Bonsoir, Est ce ia carte mère et le processeur susdits sont compatible Debian Testing? En particulier pour faire tourner un serveur Xorg et Gimp. Je m'interroge sur la compatibilité de la carte mère avec le coprocesseur graphique du AMD Ryzen 7 8700G. (l'usage principal étant le traitement d'images numériques, notamment avec Gimp et Inkscape; accessoirement la compilation par GCC) Pour ceux qui connaissent materiel.net les composants qu'on souhaite assembler sont listés en https://materiel.net/s/5CKV6K et vos critiques constructives sont bienvenues (pour un usage professionnel pour un photographe professionnel) Merci NB. Je me réjouis de l'arrêt de la Cour de Cassation https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563?search_api_fulltext=licence%20GPL&op=Rechercher&date_du=&date_au=&judilibre_juridiction=all&previousdecisionpage=&previousdecisionindex=&nextdecisionpage=0&nextdecisionindex=1 <https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563?search_api_fulltext=licence%20GPL&op=Rechercher&date_du=&date_au=&judilibre_juridiction=all&previousdecisionpage=&previousdecisionindex=&nextdecisionpage=0&nextdecisionindex=1> en faveur la la licence GPL, qui est celle utilisée dans le moteur d'inference RefPerSys dont le code source est en https://github.com/RefPerSys/RefPerSys -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir: https://github.com/RefPerSys/RefPerSys
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Par exemple le raytracing ne semble pas supporté sur les cartes AMD > alors qu'il fonctionne sur Nvidia (ainsi que le DLSS) ? Chez AMD, on trouve le FSR qui semble aussi efficace. Quant au raytracing, la carte que j'utilise ne doit pas savoir qu'il n'est pas supporté. JKB
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 13 septembre 2023 à 15:50 +0200, BERTRAND Joël a écrit : > Gaëtan Perrier a écrit : > > Je suis d'accord sur le fond mais le problème c'est que les cartes > > NVIDIA, d'après tout ce je lis, semblent être les plus performantes. > > Là j'envisage de changer de PC car il commence à atteindre ses limites, > > et en cherchant un peu je vois que le support des nouvelles cartes Intel > > ARC semble être foireux, que le support des AMD semble bon et libre mais > > que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout > > le monde mais avec des pilotes proprio. :( > > Franchement, j'aimerais bien savoir ce qu'on reproche aux cartes > AMD. > J'ai un truc comme ça pour faire de la CAO (bi écran) sur un i9, ça > tient vraiment bien la route, même pour des jeux en 3D : > Par exemple le raytracing ne semble pas supporté sur les cartes AMD alors qu'il fonctionne sur Nvidia (ainsi que le DLSS) ? Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote nouveau à proprio
Même pour des matériels disposant d'un bon pilote totalement libre le support disparaît... Ma carte a plus de 10 ans et fonctionne encore avec les pilotes proprios. Le 13 septembre 2023 20:52:45 GMT+02:00, "BERTRAND Joël" a écrit : >ajh-valmer a écrit : >> Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. >> avec leur pilote, il y a une configuration sophistiquée de la carte, >> permettant d'améliorer le rendu (nvidia-settings). >> Les pilotes libres n'ont pas cet outil de config. >> Seulement, leurs pilotes ne suivent pas toujours les distributions >> et les versions. > > Je leur reproche surtout le fait qu'après quelques années de ne plus >être supportées. J'ai des lots de telles cartes et ça m'a toujours dérangé. > > Il n'y a aucune raison /valable/ à cela. > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [testing] passage du pilote nouveau à proprio
ajh-valmer a écrit : > Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. > avec leur pilote, il y a une configuration sophistiquée de la carte, > permettant d'améliorer le rendu (nvidia-settings). > Les pilotes libres n'ont pas cet outil de config. > Seulement, leurs pilotes ne suivent pas toujours les distributions > et les versions. Je leur reproche surtout le fait qu'après quelques années de ne plus être supportées. J'ai des lots de telles cartes et ça m'a toujours dérangé. Il n'y a aucune raison /valable/ à cela.
Re: [testing] passage du pilote nouveau à proprio
On Wednesday 13 September 2023 13:41:45 BERTRAND Joël wrote: > > On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: > >> Les pilotes nvidia legacy 390 de sid étant maintenant compatibles > >> avec les kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. > >> Avec nouveau c'était invivable. > ajh-valmer a écrit : > > Je n'ai jamais réussi à faire fonctionner correctement un > > pilote "nouveau". > > Ce sont les pilotes proprio qui fonctionnent vraiment. > > Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre > > à 100% mais parfois ce n'est pas possible. On Wednesday 13 September 2023 13:41:45 BERTRAND Joël wrote: >Sans être terroriste libriste, nvidia est un machin qui pose problème > parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le > pilote libre faute de support. Je boycotte scrupuleusement toutes les > cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour > où nvidia daignera fournir les specs de ses cartes. Les cartes Nvidia ont une très bonne qualité de rendu à l'écran. avec leur pilote, il y a une configuration sophistiquée de la carte, permettant d'améliorer le rendu (nvidia-settings). Les pilotes libres n'ont pas cet outil de config. Seulement, leurs pilotes ne suivent pas toujours les distributions et les versions.
Re: [testing] passage du pilote proprio à nouveau
Gaëtan Perrier a écrit : > Je suis d'accord sur le fond mais le problème c'est que les cartes > NVIDIA, d'après tout ce je lis, semblent être les plus performantes. > Là j'envisage de changer de PC car il commence à atteindre ses limites, > et en cherchant un peu je vois que le support des nouvelles cartes Intel > ARC semble être foireux, que le support des AMD semble bon et libre mais > que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout > le monde mais avec des pilotes proprio. :( Franchement, j'aimerais bien savoir ce qu'on reproche aux cartes AMD. J'ai un truc comme ça pour faire de la CAO (bi écran) sur un i9, ça tient vraiment bien la route, même pour des jeux en 3D : 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] Flags: bus master, fast devsel, latency 0, IRQ 132 Memory at 42 (64-bit, prefetchable) [size=8G] Memory at 41 (64-bit, prefetchable) [size=2M] I/O ports at 4000 [size=256] Memory at a020 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Capabilities: [200] Physical Resizable BAR Capabilities: [270] Secondary PCI Express Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Capabilities: [320] Latency Tolerance Reporting Capabilities: [328] Alternative Routing-ID Interpretation (ARI) Capabilities: [370] L1 PM Substates Kernel driver in use: amdgpu Kernel modules: amdgpu
Re: [testing] passage du pilote proprio à nouveau
Je suis d'accord sur le fond mais le problème c'est que les cartes NVIDIA, d'après tout ce je lis, semblent être les plus performantes. Là j'envisage de changer de PC car il commence à atteindre ses limites, et en cherchant un peu je vois que le support des nouvelles cartes Intel ARC semble être foireux, que le support des AMD semble bon et libre mais que côté perf ce n'est pas encore ça et au final NVIDIA et devant tout le monde mais avec des pilotes proprio. :( Gaëtan Le 13 septembre 2023 13:41:45 GMT+02:00, "BERTRAND Joël" a écrit : >ajh-valmer a écrit : >> On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: >>> Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les >>> kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. >>> Avec nouveau c'était invivable. >> >> Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". >> Ce sont les pilotes proprio qui fonctionnent vraiment. >> >> Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à >> 100% mais parfois ce n'est pas possible. > > Sans être terroriste libriste, nvidia est un machin qui pose problème >parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le >pilote libre faute de support. Je boycotte scrupuleusement toutes les >cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour >où nvidia daignera fournir les specs de ses cartes. > > JKB > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [testing] passage du pilote proprio à nouveau
ajh-valmer a écrit : > On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: >> Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les >> kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. >> Avec nouveau c'était invivable. > > Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". > Ce sont les pilotes proprio qui fonctionnent vraiment. > > Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à > 100% mais parfois ce n'est pas possible. Sans être terroriste libriste, nvidia est un machin qui pose problème parce qu'au bout d'un certain temps, on se retrouve à devoir utiliser le pilote libre faute de support. Je boycotte scrupuleusement toutes les cartes nvidia pour cette raison. Je changerai d'avis sur nvidia le jour où nvidia daignera fournir les specs de ses cartes. JKB
Re: [testing] passage du pilote proprio à nouveau
On Tuesday 12 September 2023 23:24:24 Gaëtan Perrier wrote: > Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les > kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. > Avec nouveau c'était invivable. Je n'ai jamais réussi à faire fonctionner correctement un pilote "nouveau". Ce sont les pilotes proprio qui fonctionnent vraiment. Ce sont les "terroristes libristes" qui imposent d'utiliser que du Libre à 100% mais parfois ce n'est pas possible.
Re: [testing] passage du pilote proprio à nouveau
Salut, Les pilotes nvidia legacy 390 de sid étant maintenant compatibles avec les kernel jusqu'à 6.5 je suis repassé sur le pilote proprio. Avec nouveau c'était invivable. A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 07 août 2023 à 08:59 +0200, Michel Verdier a écrit : > Le 6 août 2023 Gaëtan Perrier a écrit : > > > > tout ces firmwares semblent faire partie du paquet > > > firmware-misc-non-free qui ne doit pas être installé chez toi, donc > > > installe-le > > > > Il est installé mais ils ne sont pas dedans. > > update-initramfs liste tous les firmwares qui peuvent être demandés par le > kernel. Mais tu as juste besoin de ceux qui vont bien pour ton > matériel. Donc tu peux ignorer ces warnings si ton matériel est bien pris > en charge par un firmware présent. Oui effectivement ça ne semble pas concerner ma carte qui est sur du gf116. > Ou tu peux aller piocher sur internet > des firmwares en plus, mais là il faut chercher spécifiquement ce qui te > manque. Par exemple moi je vais piocher sur : > https://anduin.linuxfromscratch.org/sources/linux-firmware/ > https://github.com/intel/backport-iwlwifi > https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git Merci pour les liens. Mais rien de plus que ce que j'ai déjà. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 6 août 2023 Gaëtan Perrier a écrit : >> tout ces firmwares semblent faire partie du paquet >> firmware-misc-non-free qui ne doit pas être installé chez toi, donc >> installe-le > > Il est installé mais ils ne sont pas dedans. update-initramfs liste tous les firmwares qui peuvent être demandés par le kernel. Mais tu as juste besoin de ceux qui vont bien pour ton matériel. Donc tu peux ignorer ces warnings si ton matériel est bien pris en charge par un firmware présent. Ou tu peux aller piocher sur internet des firmwares en plus, mais là il faut chercher spécifiquement ce qui te manque. Par exemple moi je vais piocher sur : https://anduin.linuxfromscratch.org/sources/linux-firmware/ https://github.com/intel/backport-iwlwifi https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 19:54 +0200, didier gaumet a écrit : > Le 06/08/2023 à 16:19, Gaëtan Perrier a écrit : > > Le samedi 05 août 2023 à 11:19 +0200, didier gaumet a écrit : > [...] > > > - chercher les paquets obsolètes (aptitude search '~o') > > > > rien concernant le système graphique. > > - par effet de bord ton fonctionnement graphique peut être impacté par > un truc non graphique > - en gros il faut vérifier que ce qui reste ne sont que des paquets > *locaux* (hors dépôts Trixie mentionnés dans /etc/apt/sources.list et > /etc/apt/sources.list.d) parce qu'ils apparaissent aussi avec aptitude > search '~o'. Par contre, pas forcément, mais potentiellement, tous les > paquets qui sont réellement obsolètes ou d'une autre distro que Trixie > (stable, bookworm, unstable, sid, Ubuntu et autres) peuvent casser ton > installation. > > [...] > > Sinon en faisant un update-initramfs (pour une autre raison) j'ai ces > > messages > > qui sont sortis: > > update-initramfs -k all -u > > update-initramfs: Generating /boot/initrd.img-6.4.0-1-amd64 > > W: Possible missing firmware > > /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin > > for module nouveau > [...] > > W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for > > module nouveau > > tout ces firmwares semblent faire partie du paquet > firmware-misc-non-free qui ne doit pas être installé chez toi, donc > installe-le > > Il est installé mais ils ne sont pas dedans. Par exemple pour ga103 il y a juste: /lib/firmware/nvidia/ga103 /lib/firmware/nvidia/ga103/gr /lib/firmware/nvidia/ga103/gr/NET_img.bin /lib/firmware/nvidia/ga103/gr/fecs_bl.bin /lib/firmware/nvidia/ga103/gr/fecs_sig.bin /lib/firmware/nvidia/ga103/gr/gpccs_bl.bin /lib/firmware/nvidia/ga103/gr/gpccs_sig.bin Donc rien concernant ga103/sec2/* signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 20:04 +0200, didier gaumet a écrit : > Le 06/08/2023 à 16:38, Gaëtan Perrier a écrit : > > Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit : > [...] > > > ~]# apt purge *nvidia* > [...] > > En fait il faut faire apt purge "*nvidia*" sinon il prend les fichier > > contenant > > nvidia qui sont dans le répertoire ... > > > > Les paquets suivants seront ENLEVÉS : > > firmware-nvidia-gsp* glx-diversions* libnvidia-allocator1* > > libnvidia-egl-gbm1* libnvidia-egl-wayland1* nvidia-installer-cleanup* > > > > Y a pas grand chose qui traînait. > > c'est pas tellement qu'il reste des bibliothèques proprio nvidia qui > était gênant, c'est le fait que les scripts d'installation de ces > procédures avaient probablement paramétré que ta caret devait être gérée > à tous les niveaux par le pilote proprio, donc Nouveau ne pouvait > fonctionner correctement. > Si tu as de la chance et que tout s'est bien passé la purge a non > seulement supprimé les paquets mais aussi supprimé certains fichiers de > conf et changé des valeurs de paramètres dans les fichiers de conf restant. > > => refais un vainfo et un vdpauinfo, tu devrais avoir de meilleurs > résultats qu'auparavant Les résultats sont exactement les mêmes, par contre depuis ce nettoyage je n'ai pas eu de nouveau crash. Je croise les doigts. > > => et surtout, si il était auparavant absent et que tu as installé le > paquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir > expliquer tes problèmes et les résoudre. Non il était là depuis le début. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 06/08/2023 à 16:38, Gaëtan Perrier a écrit : Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit : [...] ~]# apt purge *nvidia* [...] En fait il faut faire apt purge "*nvidia*" sinon il prend les fichier contenant nvidia qui sont dans le répertoire ... Les paquets suivants seront ENLEVÉS : firmware-nvidia-gsp* glx-diversions* libnvidia-allocator1* libnvidia-egl-gbm1* libnvidia-egl-wayland1* nvidia-installer-cleanup* Y a pas grand chose qui traînait. c'est pas tellement qu'il reste des bibliothèques proprio nvidia qui était gênant, c'est le fait que les scripts d'installation de ces procédures avaient probablement paramétré que ta caret devait être gérée à tous les niveaux par le pilote proprio, donc Nouveau ne pouvait fonctionner correctement. Si tu as de la chance et que tout s'est bien passé la purge a non seulement supprimé les paquets mais aussi supprimé certains fichiers de conf et changé des valeurs de paramètres dans les fichiers de conf restant. => refais un vainfo et un vdpauinfo, tu devrais avoir de meilleurs résultats qu'auparavant => et surtout, si il était auparavant absent et que tu as installé le paquet firmware-misc-nonfree, ça devrait au moins en partie pouvoir expliquer tes problèmes et les résoudre.
Re: [testing] passage du pilote proprio à nouveau
Le 06/08/2023 à 16:19, Gaëtan Perrier a écrit : Le samedi 05 août 2023 à 11:19 +0200, didier gaumet a écrit : [...] - chercher les paquets obsolètes (aptitude search '~o') rien concernant le système graphique. - par effet de bord ton fonctionnement graphique peut être impacté par un truc non graphique - en gros il faut vérifier que ce qui reste ne sont que des paquets *locaux* (hors dépôts Trixie mentionnés dans /etc/apt/sources.list et /etc/apt/sources.list.d) parce qu'ils apparaissent aussi avec aptitude search '~o'. Par contre, pas forcément, mais potentiellement, tous les paquets qui sont réellement obsolètes ou d'une autre distro que Trixie (stable, bookworm, unstable, sid, Ubuntu et autres) peuvent casser ton installation. [...] Sinon en faisant un update-initramfs (pour une autre raison) j'ai ces messages qui sont sortis: update-initramfs -k all -u update-initramfs: Generating /boot/initrd.img-6.4.0-1-amd64 W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin for module nouveau [...] W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for module nouveau tout ces firmwares semblent faire partie du paquet firmware-misc-non-free qui ne doit pas être installé chez toi, donc installe-le
Re: [testing] passage du pilote proprio à nouveau
Le dimanche 06 août 2023 à 16:19 +0200, Gaëtan Perrier a écrit : > > > > - essayer de faire un apt purge *nvidia* pour virer les restes de > > fichiers de conf' qui doivent encore traîner > > ~]# apt purge *nvidia* > Lecture des listes de paquets... Fait > Construction de l'arbre des dépendances... Fait > Lecture des informations d'état... Fait > E: Impossible de trouver le paquet glxinfo_nvidia.txt > > Là je ne sais pas quoi penser vu qu'il n'existe pas de paquet avec un tel nom > ... > > En fait il faut faire apt purge "*nvidia*" sinon il prend les fichier contenant nvidia qui sont dans le répertoire ... Les paquets suivants seront ENLEVÉS : firmware-nvidia-gsp* glx-diversions* libnvidia-allocator1* libnvidia-egl-gbm1* libnvidia-egl-wayland1* nvidia-installer-cleanup* Y a pas grand chose qui traînait. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le samedi 05 août 2023 à 11:19 +0200, didier gaumet a écrit : > > je ne sais pas trop quoi te conseiller, à part > > - tester une livekey Debian 12 pour voir si tu as des freezes, pour > éliminer la possibilité que l'association de ton matériel et sa gestion > par Nouveau génère les crashes. Si ça crashe c'est vraisemblablement > que tu ne peux obtenir un bon fonctionnement que par le pilote proprio. > Sinon c'est que ton installation Testing est bancale Je ferai ce test à mon retour de vacances fin août. > > - vérifier (apt policy) entre autres les versions de libc6 et libdrm* > installées sont les dernières disponibles libc6 je suis en 2.37-6 et sid en 2.37-7 libdrm 2.4.155-1 comme sid > > - chercher les paquets obsolètes (aptitude search '~o') rien concernant le système graphique. > > - essayer de faire un apt purge *nvidia* pour virer les restes de > fichiers de conf' qui doivent encore traîner ~]# apt purge *nvidia* Lecture des listes de paquets... Fait Construction de l'arbre des dépendances... Fait Lecture des informations d'état... Fait E: Impossible de trouver le paquet glxinfo_nvidia.txt Là je ne sais pas quoi penser vu qu'il n'existe pas de paquet avec un tel nom ... > > - si pas plus de succès, envisager une réinstallation propre de Debian > (après sauvegarde de tes données), parce que honnêtement, si j'ai bien > compris, tu fais des mises-à-jour depuis 20 ans, ça m'étonnerait que ton > système ne soit pas bancal ;-) C'est possible mais jusqu'à maintenant ça fonctionnait très bien :) Sinon en faisant un update-initramfs (pour une autre raison) j'ai ces messages qui sont sortis: update-initramfs -k all -u update-initramfs: Generating /boot/initrd.img-6.4.0-1-amd64 W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_ahesasc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_asb.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/acr/ucode_unload.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/nvdec/scrubber.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga107/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga106/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga104/sec2/desc.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/hs_bl_sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/sig.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/image.bin for module nouveau W: Possible missing firmware /lib/firmware/nvidia/ga103/sec2/desc.bin for module nouveau signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
je ne sais pas trop quoi te conseiller, à part - tester une livekey Debian 12 pour voir si tu as des freezes, pour éliminer la possibilité que l'association de ton matériel et sa gestion par Nouveau génère les crashes. Si ça crashe c'est vraisemblablement que tu ne peux obtenir un bon fonctionnement que par le pilote proprio. Sinon c'est que ton installation Testing est bancale - vérifier (apt policy) entre autres les versions de libc6 et libdrm* installées sont les dernières disponibles - chercher les paquets obsolètes (aptitude search '~o') - essayer de faire un apt purge *nvidia* pour virer les restes de fichiers de conf' qui doivent encore traîner - si pas plus de succès, envisager une réinstallation propre de Debian (après sauvegarde de tes données), parce que honnêtement, si j'ai bien compris, tu fais des mises-à-jour depuis 20 ans, ça m'étonnerait que ton système ne soit pas bancal ;-)
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 21:32 +0200, Gaëtan Perrier a écrit : > Le vendredi 04 août 2023 à 20:21 +0200, Gaëtan Perrier a écrit : > > Sinon j'ai le même problème de crash de nouveau avec wayland qu'avec xorg. > > Sauf > > qu'avec xorg j'arrive à redémarrer la machine mais pas avec wayland. > > Nouveau crash alors que j'étais sous xorg mais là je suis retourné à gdm > automatiquement. > Du coup j'ai une backtrace dans .local/share/xorg > > [ 1191.889] (EE) > [ 1191.889] (EE) Backtrace: > [ 1191.891] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) > [0x557e886e1d29] > [ 1191.892] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) > [0x7f5ce805a510] > [ 1191.893] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 > (pthread_key_delete+0x14c) > [0x7f5ce80a80fc] > [ 1191.893] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) > [0x7f5ce805a472] > [ 1191.894] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) > [0x7f5ce80444b2] > [ 1191.895] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.895] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f5ce80443d5] > [ 1191.896] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) > [0x7f5ce80533a2] > [ 1191.896] (EE) 7: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0xff) [0x7f5ce79f67ff] > [ 1191.897] (EE) 8: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x63) [0x7f5ce79f6763] > [ 1191.897] (EE) 9: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x17c) [0x7f5ce79f687c] > [ 1191.898] (EE) 10: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0x3f7) [0x7f5ce79f6af7] > [ 1191.898] (EE) 11: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 > (nouveau_pushbuf_data+0xb01) [0x7f5ce79f7201] > [ 1191.899] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.899] (EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) > [0x7f5ce7a21af8] > [ 1191.900] (EE) 13: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x57b9) > [0x7f5ce79e2ae9] > [ 1191.900] (EE) 14: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x5b21) > [0x7f5ce79e2e51] > [ 1191.901] (EE) 15: /usr/lib/xorg/Xorg (miCopyRegion+0x93) [0x557e886beea3] > [ 1191.901] (EE) 16: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x557e886bf5f6] > [ 1191.901] (EE) 17: /usr/lib/xorg/modules/libexa.so > (exaMoveOutPixmap+0x3d95) > [0x7f5ce79e10c5] > [ 1191.902] (EE) 18: /usr/lib/xorg/Xorg (DamageRegionAppend+0x359f) > [0x557e8865222f] > [ 1191.903] (EE) unw_get_proc_name failed: no unwind info found [-10] > [ 1191.903] (EE) 19: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) > [0x7f5ce7a0a5c1] > [ 1191.903] (EE) 20: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0x14a8) > [0x557e8869aab8] > [ 1191.903] (EE) 21: /usr/lib/xorg/Xorg (DRI2CopyRegion+0x6e) > [0x557e8869b36e] > [ 1191.904] (EE) 22: /usr/lib/xorg/Xorg (DRI2GetParam+0xbf5) > [0x557e8869d785] > [ 1191.905] (EE) 23: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) > [0x557e8856e734] > [ 1191.905] (EE) 24: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x557e885726cc] > [ 1191.906] (EE) 25: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_init_first+0x8a) > [0x7f5ce80456ca] > [ 1191.906] (EE) 26: /lib/x86_64-linux-gnu/libc.so.6 > (__libc_start_main+0x85) > [0x7f5ce8045785] > [ 1191.907] (EE) 27: /usr/lib/xorg/Xorg (_start+0x21) [0x557e8855bb71] > [ 1191.907] (EE) > [ 1191.907] (EE) > Fatal server error: > [ 1191.907] (EE) Caught signal 6 (Aborted). Server aborting > [ 1191.907] (EE) > [ 1191.907] (EE) > Please consult the The X.Org Foundation support > > Et des coredump dans journalctl: août 04 21:20:27 reveillon systemd[1]: Created slice system- systemd\x2dcoredump.slice - Slice /system/systemd-coredump. août 04 21:20:27 reveillon systemd[1]: Started systemd-coredump@0-13076-0.service - Process Core Dump (PID 13076/UID 0). août 04 21:20:28 reveillon systemd-coredump[13086]: [🡕] Process 3340 (Xorg) of user 1000 dumped core. Module libsystemd.so.0 from deb systemd-254-1.amd64 Module libudev.so.1 from deb systemd-254-1.amd64 Stack trace of thread 3340: #0 0x7f5ce80a80fc __pthread_kill_implementation (libc.so.6 + 0x8a0fc) #1 0x7f5ce805a472 __GI_raise (libc.so.6 + 0x3c472) #2 0x7f5ce80444b2 __GI_abort (libc.so.6 + 0x264b2) #3 0x557e886e4a0a OsAbort (Xorg + 0x1d5a0a) #4 0x557e886ea073 n/a (Xorg + 0x1db073) #5 0x557e886eb0a5 FatalError (Xorg + 0x1dc0a5)
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 20:21 +0200, Gaëtan Perrier a écrit : > Sinon j'ai le même problème de crash de nouveau avec wayland qu'avec xorg. > Sauf > qu'avec xorg j'arrive à redémarrer la machine mais pas avec wayland. Nouveau crash alors que j'étais sous xorg mais là je suis retourné à gdm automatiquement. Du coup j'ai une backtrace dans .local/share/xorg [ 1191.889] (EE) [ 1191.889] (EE) Backtrace: [ 1191.891] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x557e886e1d29] [ 1191.892] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f5ce805a510] [ 1191.893] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) [0x7f5ce80a80fc] [ 1191.893] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7f5ce805a472] [ 1191.894] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7f5ce80444b2] [ 1191.895] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.895] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f5ce80443d5] [ 1191.896] (EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) [0x7f5ce80533a2] [ 1191.896] (EE) 7: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0xff) [0x7f5ce79f67ff] [ 1191.897] (EE) 8: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x63) [0x7f5ce79f6763] [ 1191.897] (EE) 9: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x17c) [0x7f5ce79f687c] [ 1191.898] (EE) 10: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0x3f7) [0x7f5ce79f6af7] [ 1191.898] (EE) 11: /lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (nouveau_pushbuf_data+0xb01) [0x7f5ce79f7201] [ 1191.899] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.899] (EE) 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f5ce7a21af8] [ 1191.900] (EE) 13: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x57b9) [0x7f5ce79e2ae9] [ 1191.900] (EE) 14: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x5b21) [0x7f5ce79e2e51] [ 1191.901] (EE) 15: /usr/lib/xorg/Xorg (miCopyRegion+0x93) [0x557e886beea3] [ 1191.901] (EE) 16: /usr/lib/xorg/Xorg (miDoCopy+0x466) [0x557e886bf5f6] [ 1191.901] (EE) 17: /usr/lib/xorg/modules/libexa.so (exaMoveOutPixmap+0x3d95) [0x7f5ce79e10c5] [ 1191.902] (EE) 18: /usr/lib/xorg/Xorg (DamageRegionAppend+0x359f) [0x557e8865222f] [ 1191.903] (EE) unw_get_proc_name failed: no unwind info found [-10] [ 1191.903] (EE) 19: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f5ce7a0a5c1] [ 1191.903] (EE) 20: /usr/lib/xorg/Xorg (DRIMoveBuffersHelper+0x14a8) [0x557e8869aab8] [ 1191.903] (EE) 21: /usr/lib/xorg/Xorg (DRI2CopyRegion+0x6e) [0x557e8869b36e] [ 1191.904] (EE) 22: /usr/lib/xorg/Xorg (DRI2GetParam+0xbf5) [0x557e8869d785] [ 1191.905] (EE) 23: /usr/lib/xorg/Xorg (SendErrorToClient+0x3d4) [0x557e8856e734] [ 1191.905] (EE) 24: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x557e885726cc] [ 1191.906] (EE) 25: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f5ce80456ca] [ 1191.906] (EE) 26: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f5ce8045785] [ 1191.907] (EE) 27: /usr/lib/xorg/Xorg (_start+0x21) [0x557e8855bb71] [ 1191.907] (EE) [ 1191.907] (EE) Fatal server error: [ 1191.907] (EE) Caught signal 6 (Aborted). Server aborting [ 1191.907] (EE) [ 1191.907] (EE) Please consult the The X.Org Foundation support signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 11:06 +0200, didier gaumet a écrit : > Le 04/08/2023 à 02:06, Gaëtan Perrier a écrit : > > > Par contre une fois sous Wayland vdpau_info n'est pas content ... > > > > vdpauinfo > > display: :0 screen: 0 > > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > > file: No such file or directory > > Error creating VDPAU device: 1 > > > > alors que ça fonctionnait sous xorg ... > > > > Gaëtan > > je peux me tromper mais je pense que ta désinstallation des pilotes > nvidia n'a pas été complète (pour ça si je comprends bien (je n'ai > jamais eu de nvidia), il aurait fallu employer la procédure de > désinstallation complète nvidia). > En tout cas ça me semble bizarre que ce soit l'absence du backend > libvdpau_nvidia.so dont se plaigne vdpauinfo vu que c'est le backend > pour le pilote proprio, pas pour Nouveau. Oui moi aussi je trouve ça étonnant. Pourtant je n'ai plus de trace de paquets nvidia ... Ce qui est bizarre c'est que sous xorg ça fonctionne ... > > Pour Nouveau: > - VAAPI: vérifier que mesa-va-drivers est installé ou l'installer > - VDPAU: vérifier que vdpau-driver-all est installé ou l'installer Oui c'est bon. > > cf: > le wiki Debian > https://wiki.debian.org/HardwareVideoAcceleration > et, plus détaillé, le wiki Archlinux, qui te détaillera aussi les > couches des traductions entre VAAPI te CDPAU dans un sens et dans > l'autre, parfois utile pour bénéficier d'une accélération sur des > matériels qui ne supportent que certains machins particuliers: > https://wiki.archlinux.org/title/Hardware_video_acceleration > (normalement la série Geforce 500 est directement compatible VAAPI et > VDPAU sans souci) Tout semble pourtant bon ... :( Sinon j'ai le même problème de crash de nouveau avec wayland qu'avec xorg. Sauf qu'avec xorg j'arrive à redémarrer la machine mais pas avec wayland. signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 11:55 +0200, ajh-valmer a écrit : > On Friday 04 August 2023 02:05:09 Gaëtan Perrier wrote: > > > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > > > > X -configure ? > > > Par contre si j'ai bien compris faut la lancer sans que X soit démarré : > Oui, mais est-ce important ? Faire les 2 alors. > As tu bien un fichier xorg.conf ? > (le montrer) Oui j'en ai un ~$ cat /etc/X11/xorg.conf Section "Device" Identifier "MyGPU" Driver "nouveau" EndSection signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Friday 04 August 2023 02:05:09 Gaëtan Perrier wrote: > > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > > > X -configure ? > Par contre si j'ai bien compris faut la lancer sans que X soit démarré : Oui, mais est-ce important ? Faire les 2 alors. As tu bien un fichier xorg.conf ? (le montrer) > > www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038
Re: [testing] passage du pilote proprio à nouveau
Le 04/08/2023 à 02:06, Gaëtan Perrier a écrit : Par contre une fois sous Wayland vdpau_info n'est pas content ... vdpauinfo display: :0 screen: 0 Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory Error creating VDPAU device: 1 alors que ça fonctionnait sous xorg ... Gaëtan je peux me tromper mais je pense que ta désinstallation des pilotes nvidia n'a pas été complète (pour ça si je comprends bien (je n'ai jamais eu de nvidia), il aurait fallu employer la procédure de désinstallation complète nvidia). En tout cas ça me semble bizarre que ce soit l'absence du backend libvdpau_nvidia.so dont se plaigne vdpauinfo vu que c'est le backend pour le pilote proprio, pas pour Nouveau. Pour Nouveau: - VAAPI: vérifier que mesa-va-drivers est installé ou l'installer - VDPAU: vérifier que vdpau-driver-all est installé ou l'installer cf: le wiki Debian https://wiki.debian.org/HardwareVideoAcceleration et, plus détaillé, le wiki Archlinux, qui te détaillera aussi les couches des traductions entre VAAPI te CDPAU dans un sens et dans l'autre, parfois utile pour bénéficier d'une accélération sur des matériels qui ne supportent que certains machins particuliers: https://wiki.archlinux.org/title/Hardware_video_acceleration (normalement la série Geforce 500 est directement compatible VAAPI et VDPAU sans souci)
Re: [testing] passage du pilote proprio à nouveau
Le vendredi 04 août 2023 à 01:20 +0200, Gaëtan Perrier a écrit : > Le jeudi 03 août 2023 à 09:32 +0200, didier gaumet a écrit : > > Le 03/08/2023 à 03:14, Gaëtan Perrier a écrit : > > > Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit : > > [...] > > > > Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, > > > > GDM > > > > te permet de choisir entre quatre possibilités: Gnome/Wayland > > > > (défaut), > > > > Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11? > > > > Donc naviguer entre les quatre possibilités nécessite juste de se > > > > déconnecter/reconnecter à la session en choisissant la bonne option? > > > > > > Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback > > > (Metacity) ... > > > > - ça doit dater d'un précédent ménage que tu as fait pour revenir à X11 > > au lieu de Wayland en pensant que c'était nécessaire. Mais ça me paraît > > une mauvaise idée: même gdm est une mini-session gnome-shell sous > > Wayland, bien que dans ton cas il lance par la suite une session > > ordinaire gnoem-shell sous X11. > > Si tu veux revenir au standard debian, tu peux essayer de purger puis > > réinstaller gdm (vérifie que tu n'as pas crée un fichier > > /etc/apt/preferences dans lequel tu as placé des interdictions pour > > Wayland) > > En fait c'est juste la ligne > WaylandEnable=false > dans /etc/gdm3/daemon.conf qu'il faut commenter pour réactiver Wayland. > > Par contre une fois sous Wayland vdpau_info n'est pas content ... vdpauinfo display: :0 screen: 0 Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory Error creating VDPAU device: 1 alors que ça fonctionnait sous xorg ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le jeudi 03 août 2023 à 11:50 +0200, ajh-valmer a écrit : > On Thursday 03 August 2023 03:57:07 Gaëtan Perrier wrote: > > Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > > > Mise à part les freeze, as tu une bonne résolution sur l'écran, > > > et qu'elle est-elle ? > > > Oui l'affichage est parfait, je suis en 1920x1200 : > C'est déjà un très bon point, mais je ne m'explique pas les "freeze". > > > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > > X -configure ? > Sans doute ? à essayer... Par contre si j'ai bien compris faut la lancer sans que X soit démarré. > > j'ai trouvé ce tuto : > www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038 > Hope it helps... > Oui j'avais déjà du passer dessus. A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le jeudi 03 août 2023 à 09:32 +0200, didier gaumet a écrit : > Le 03/08/2023 à 03:14, Gaëtan Perrier a écrit : > > Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit : > [...] > > > Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, > > > GDM > > > te permet de choisir entre quatre possibilités: Gnome/Wayland > > > (défaut), > > > Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11? > > > Donc naviguer entre les quatre possibilités nécessite juste de se > > > déconnecter/reconnecter à la session en choisissant la bonne option? > > > > Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback > > (Metacity) ... > > - ça doit dater d'un précédent ménage que tu as fait pour revenir à X11 > au lieu de Wayland en pensant que c'était nécessaire. Mais ça me paraît > une mauvaise idée: même gdm est une mini-session gnome-shell sous > Wayland, bien que dans ton cas il lance par la suite une session > ordinaire gnoem-shell sous X11. > Si tu veux revenir au standard debian, tu peux essayer de purger puis > réinstaller gdm (vérifie que tu n'as pas crée un fichier > /etc/apt/preferences dans lequel tu as placé des interdictions pour > Wayland) En fait c'est juste la ligne WaylandEnable=false dans /etc/gdm3/daemon.conf qu'il faut commenter pour réactiver Wayland. > > - pour tes freezes, bien que tu aies déjà supprimé ton xorg.conf, > vérifies qu'il n'y a rien dans /etc/X11/xorg.conf.d/ vide > vérifies aussi que tu n'as pas des options de lancement de ton noyau > (kms, résolution vidéo) dans grub nada > > - sinon pour vérifier que ta carte peut fonctionner correctement avec un > Debian standard et pilote Nouveau, fais tourner sur ton PC une clé USB > Debian live (par défaut Gnome ce sera du Wayland et je ne crois pas que > tu puisses le changer, Plasma je ne sais pas ce que c'est par défaut, > les autres c'est du X11). > Si la clé USB Debian-live fonctionne correctement c'est ton installation > qui est bancale ou Testing qui est bancal à l'instant t (mais je pense > qu de toutes façons tu te traînes quelques scories de manipulations un > peu hasardeuses dans ta config) Possible, j'ai 20 ans d'historique ! :) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Thursday 03 August 2023 03:57:07 Gaëtan Perrier wrote: > Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > > Mise à part les freeze, as tu une bonne résolution sur l'écran, > > et qu'elle est-elle ? > Oui l'affichage est parfait, je suis en 1920x1200 : C'est déjà un très bon point, mais je ne m'explique pas les "freeze". > > > Il y a une commande qui créé le /etc/X11/xorg.conf : > X -configure ? Sans doute ? à essayer... j'ai trouvé ce tuto : www.debian-fr.org/t/nvidia-installation-facile-du-pilote-libre-nouveau/17038 Hope it helps...
Re: [testing] passage du pilote proprio à nouveau
Le 03/08/2023 à 03:14, Gaëtan Perrier a écrit : Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit : [...] Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, GDM te permet de choisir entre quatre possibilités: Gnome/Wayland (défaut), Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11? Donc naviguer entre les quatre possibilités nécessite juste de se déconnecter/reconnecter à la session en choisissant la bonne option? Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback (Metacity) ... - ça doit dater d'un précédent ménage que tu as fait pour revenir à X11 au lieu de Wayland en pensant que c'était nécessaire. Mais ça me paraît une mauvaise idée: même gdm est une mini-session gnome-shell sous Wayland, bien que dans ton cas il lance par la suite une session ordinaire gnoem-shell sous X11. Si tu veux revenir au standard debian, tu peux essayer de purger puis réinstaller gdm (vérifie que tu n'as pas crée un fichier /etc/apt/preferences dans lequel tu as placé des interdictions pour Wayland) - pour tes freezes, bien que tu aies déjà supprimé ton xorg.conf, vérifies qu'il n'y a rien dans /etc/X11/xorg.conf.d/ vérifies aussi que tu n'as pas des options de lancement de ton noyau (kms, résolution vidéo) dans grub - sinon pour vérifier que ta carte peut fonctionner correctement avec un Debian standard et pilote Nouveau, fais tourner sur ton PC une clé USB Debian live (par défaut Gnome ce sera du Wayland et je ne crois pas que tu puisses le changer, Plasma je ne sais pas ce que c'est par défaut, les autres c'est du X11). Si la clé USB Debian-live fonctionne correctement c'est ton installation qui est bancale ou Testing qui est bancal à l'instant t (mais je pense qu de toutes façons tu te traînes quelques scories de manipulations un peu hasardeuses dans ta config)
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 13:31 +0200, ajh-valmer a écrit : > Mise à part les freeze, as tu une bonne résolution sur l'écran, > et qu'elle est-elle ? Oui l'affichage est parfait, je suis en 1920x1200 > Il y a une commande qui créé le /etc/X11/xorg.conf, > je ne sais plus son nom, xorg-config... xorg.conf que l'on peut > compléter ensuite. X -configure ? > On peut aussi ajouter des configs dans /etc/default/grub > Un tutoriel : > https://wiki.archlinux.org/title/nouveau > > Comme déjà dit, j'avais réussi à installer le pilote nouveau, > sans freeze, mais avec une résolution trop faible de 1024X768. > > Si persistence du problème, acheter une nouvelle carte vidéo reconnue > ? Reconnue par les pilotes nvidia ? Je ne sais si les cartes supportées par les pilotes 525 sont compatibles avec ma carte mère qui date de 2011 ... Gaëtan
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 13:35 +0200, didier gaumet a écrit : > Le 02/08/2023 à 13:10, Gaëtan Perrier a écrit : > > > Et comment on fait pour savoir si ma carte est bien gérée ? > > Les infos que j'ai trouvé la-dessus sont très vieille ... > > c'est vieux mais la page semble maintenue: > https://nouveau.freedesktop.org/FeatureMatrix.html > https://nouveau.freedesktop.org/CodeNames.html Oui ce sont les pages que j'avais consultées. Mais je n'étais pas sûr que ce soit à jour. > > > Je suis sur un desktop, aucun suspend aucune hibernation. > > OK > > J'étais passé à Wayland à une époque mais j'avais du revenir à X11 > > parce que ça se passait mal quand je lançais une appli depuis un > > terminal loggué avec un autre user. > > J'ai un peu peur de rechanger car de mémoire le retour à X11 > > n'avait > > pas été super simple ... > > Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, > GDM > te permet de choisir entre quatre possibilités: Gnome/Wayland > (défaut), > Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11? > Donc naviguer entre les quatre possibilités nécessite juste de se > déconnecter/reconnecter à la session en choisissant la bonne option? > Chez moi j'ai juste GNOME, GNOME Classique et GNOME Flashback (Metacity) ... Gaëtan
Re: [testing] passage du pilote proprio à nouveau
Le 02/08/2023 à 13:10, Gaëtan Perrier a écrit : Et comment on fait pour savoir si ma carte est bien gérée ? Les infos que j'ai trouvé la-dessus sont très vieille ... c'est vieux mais la page semble maintenue: https://nouveau.freedesktop.org/FeatureMatrix.html https://nouveau.freedesktop.org/CodeNames.html Je suis sur un desktop, aucun suspend aucune hibernation. OK J'étais passé à Wayland à une époque mais j'avais du revenir à X11 parce que ça se passait mal quand je lançais une appli depuis un terminal loggué avec un autre user. J'ai un peu peur de rechanger car de mémoire le retour à X11 n'avait pas été super simple ... Ben en fait, je ne saisis pas, quand Gnome est installé sur Debian, GDM te permet de choisir entre quatre possibilités: Gnome/Wayland (défaut), Gnome/X11, Gnome-classic/Wayland, Gnome-classic/X11? Donc naviguer entre les quatre possibilités nécessite juste de se déconnecter/reconnecter à la session en choisissant la bonne option?
Re: [testing] passage du pilote proprio à nouveau
Mise à part les freeze, as tu une bonne résolution sur l'écran, et qu'elle est-elle ? Il y a une commande qui créé le /etc/X11/xorg.conf, je ne sais plus son nom, xorg-config... xorg.conf que l'on peut compléter ensuite. On peut aussi ajouter des configs dans /etc/default/grub Un tutoriel : https://wiki.archlinux.org/title/nouveau Comme déjà dit, j'avais réussi à installer le pilote nouveau, sans freeze, mais avec une résolution trop faible de 1024X768. Si persistence du problème, acheter une nouvelle carte vidéo reconnue ?
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 02/08/2023 à 13:11, Gaëtan Perrier a écrit : Le mercredi 02 août 2023 à 10:20 +0200, didier gaumet a écrit : Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à la main, via un autre outil ou via Network-Manager? Via les paquets et c'est nordvpn qui l'utilise. Y a une page OpenVPN sur le wiki Debian j'ai jamais fait mais en gros ils ont l'air de dire que ça peut se paramétrer depuis Network-Manager. Je suis allé dans les paramètres pour créer un VPN: Gnome/Réseau/VPN/+/OpenVPN/Avancé/Configurer le type et le nom du périphérique réseau (je ne suis pas allé au bout, je n'utilise pas OpenVPN) sinon le wiki détaille comment faire ça à la main pour des tests. Je suppose que le wiki Archlinux doit aussi avoir un article intéressant là-dessus (pas cherché)
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mercredi 02 août 2023 à 10:20 +0200, didier gaumet a écrit : > Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : > > > J'aimerai bien mais je n'ai pas trouvé de conf où il manque de > > tun/tap ... > > J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à > la > main, via un autre outil ou via Network-Manager? > > Via les paquets et c'est nordvpn qui l'utilise.
Re: [testing] passage du pilote proprio à nouveau
Le mercredi 02 août 2023 à 11:01 +0200, didier gaumet a écrit : > > J'ai lu en diagonale vu que c'est long et que je n'ai pas les > compétences pour analyser ça correctement > > - (je dis peut-être n'importe quoi sur ce coup) potentiellement > peut-être que les messages sur Nouveau après le reboot proviennent, > non > pas d'un fonctionnement perfectible en condition normale mais d'une > tentative de récupération suite au crash (peut-être que la carte > avait > tenté une économie d'énergie avant plantage et que le système cherche > à > remettre en condition antérieure. J'en sais rien. > > - par contre, vérifier que le pilote Nouveau gère bien l'énergie de > ta > carte graphique (ton modèle) parce que de mémoire, Nouveau ne gère > pas > correctement ou pas du tout certaines cartes pour la gestion > d'énergie. Et comment on fait pour savoir si ma carte est bien gérée ? Les infos que j'ai trouvé la-dessus sont très vieille ... > > => (pure supposition) Ce qui voudrait dire que si on veut éviter les > ennuis avec ces cartes à problème (avec Nouveau), il faudrait s'en > servir à l'ancienne (desktop pas laptop, jamais de suspend/hibernate, > à > paramétrer dans le DE) Je suis sur un desktop, aucun suspend aucune hibernation. > > - en fait aussi, tu utilises Gnome, non? tu peux peut-être utiliser > Gnome Wayland au lieu de Gnome X11? Wayland c'est le fonctionnement > par > défaut ed nos jours et je crois que les anciens problèmes du genre > RDP/Wayland et ce genre de truc c'est plus ou moins résolu. J'étais passé à Wayland à une époque mais j'avais du revenir à X11 parce que ça se passait mal quand je lançais une appli depuis un terminal loggué avec un autre user. J'ai un peu peur de rechanger car de mémoire le retour à X11 n'avait pas été super simple ... > > - kworker de ce que je comprends, c'est des processus attachés à des > machins en espace noyau plutôt qu'utilisateur (pas sûr d'avoir > compris > correctement) et on semble pouvoir les debugger par ftrace. Un peu > plus > d'explications là: > https://medium.com/@boutnaru/the-linux-process-journey-kworker-f947634da73 > Je vais regarder. > Bon courage :-) > Merci ;)
Re: [testing] passage du pilote proprio à nouveau
J'ai lu en diagonale vu que c'est long et que je n'ai pas les compétences pour analyser ça correctement - (je dis peut-être n'importe quoi sur ce coup) potentiellement peut-être que les messages sur Nouveau après le reboot proviennent, non pas d'un fonctionnement perfectible en condition normale mais d'une tentative de récupération suite au crash (peut-être que la carte avait tenté une économie d'énergie avant plantage et que le système cherche à remettre en condition antérieure. J'en sais rien. - par contre, vérifier que le pilote Nouveau gère bien l'énergie de ta carte graphique (ton modèle) parce que de mémoire, Nouveau ne gère pas correctement ou pas du tout certaines cartes pour la gestion d'énergie. => (pure supposition) Ce qui voudrait dire que si on veut éviter les ennuis avec ces cartes à problème (avec Nouveau), il faudrait s'en servir à l'ancienne (desktop pas laptop, jamais de suspend/hibernate, à paramétrer dans le DE) - en fait aussi, tu utilises Gnome, non? tu peux peut-être utiliser Gnome Wayland au lieu de Gnome X11? Wayland c'est le fonctionnement par défaut ed nos jours et je crois que les anciens problèmes du genre RDP/Wayland et ce genre de truc c'est plus ou moins résolu. - kworker de ce que je comprends, c'est des processus attachés à des machins en espace noyau plutôt qu'utilisateur (pas sûr d'avoir compris correctement) et on semble pouvoir les debugger par ftrace. Un peu plus d'explications là: https://medium.com/@boutnaru/the-linux-process-journey-kworker-f947634da73 Bon courage :-)
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 23:36, Gaëtan Perrier a écrit : Concernant les freeze j'ai avancé. Ce soir pendant le freeze je me suis connecté en ssh depuis une autre machine et c'est gnome-shell qui freeze en consommant 100% d'un cœur. Mais les fois d'avant je n'avais pas été assez patient parce que là en attendant je me suis aperçu que ça defreeze ! Et dans journalctl j'ai cette trace qui est apparue à ce moment là: geoclue[46380]: Service not used for 60 seconds. Shutting down.. systemd[1]: geoclue.service: Deactivated successfully. Et 60 s ce n'est pas impossible que ce soit la durée du freeze ... Je peux me tromper mais je pense que le message est seulement le système qui t'informe qu'il met fin au fonctionnement du service de géolocalisation. Et ça ne me paraît pas un truc au sujet duquel s'alarmer: prends l'exemple d'un smartphone: la géolocalisation ne fonctionne pas en permanence parce que 'est énergivore, donc n'est généralement activé qu'à la demande (manuelle ou automatique) et pour une période donnée (généralement aussi)
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 01/08/2023 à 22:31, Gaëtan Perrier a écrit : J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... J'y connais rien mais comment as-tu installé et paramétré OpenVPN? à la main, via un autre outil ou via Network-Manager?
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 23:36 +0200, Gaëtan Perrier a écrit : > Le lundi 31 juillet 2023 à 12:49 +0200, Gaëtan Perrier a écrit : > > Le lundi 31 juillet 2023 à 12:42 +0200, Gaëtan Perrier a écrit : > > > Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des > > > freeze > > > ou > > > pas ... > > > > > > > Pas eu besoin d'attendre longtemps :( > > Freeze juste après l'envoi du message précédent. > > > > Rien dans /var/log/syslog à part une série de ^@ > > > > Gaëtan > > > > Concernant les freeze j'ai avancé. > Ce soir pendant le freeze je me suis connecté en ssh depuis une autre machine > et c'est gnome-shell qui freeze en consommant 100% d'un cœur. Mais les fois > d'avant je n'avais pas été assez patient parce que là en attendant je me suis > aperçu que ça defreeze ! > Et dans journalctl j'ai cette trace qui est apparue à ce moment là: > > geoclue[46380]: Service not used for 60 seconds. Shutting down.. > systemd[1]: geoclue.service: Deactivated successfully. > > Et 60 s ce n'est pas impossible que ce soit la durée du freeze ... > > Gaëtan Bon en fait ce n'était pas un vrai freeze. Je viens d'en avoir un et là y a des logs correspondant mais que je ne sais pas interpréter: août 02 01:07:39 reveillon kernel: INFO: task kworker/0:1H:26028 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/0:1H state:D stack:0 pid:26028 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: ttm ttm_bo_delayed_delete [ttm] août 02 01:07:39 reveillon kernel: Call Trace: août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: __schedule+0x3df/0xb80 août 02 01:07:39 reveillon kernel: schedule+0x61/0xe0 août 02 01:07:39 reveillon kernel: schedule_timeout+0x151/0x160 août 02 01:07:39 reveillon kernel: dma_fence_default_wait+0x22a/0x280 août 02 01:07:39 reveillon kernel: ? __pfx_dma_fence_default_wait_cb+0x10/0x10 août 02 01:07:39 reveillon kernel: dma_fence_wait_timeout+0x10c/0x130 août 02 01:07:39 reveillon kernel: dma_resv_wait_timeout+0x7f/0xe0 août 02 01:07:39 reveillon kernel: ttm_bo_delayed_delete+0x2a/0x80 [ttm] août 02 01:07:39 reveillon kernel: process_one_work+0x1c7/0x3d0 août 02 01:07:39 reveillon kernel: worker_thread+0x51/0x390 août 02 01:07:39 reveillon kernel: ? __pfx_worker_thread+0x10/0x10 août 02 01:07:39 reveillon kernel: kthread+0xf7/0x130 août 02 01:07:39 reveillon kernel: ? __pfx_kthread+0x10/0x10 août 02 01:07:39 reveillon kernel: ret_from_fork+0x2c/0x50 août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: INFO: task kworker/0:2H:26029 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/0:2H state:D stack:0 pid:26029 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: ttm ttm_bo_delayed_delete [ttm] août 02 01:07:39 reveillon kernel: Call Trace: août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: __schedule+0x3df/0xb80 août 02 01:07:39 reveillon kernel: schedule+0x61/0xe0 août 02 01:07:39 reveillon kernel: schedule_timeout+0x151/0x160 août 02 01:07:39 reveillon kernel: dma_fence_default_wait+0x22a/0x280 août 02 01:07:39 reveillon kernel: ? __pfx_dma_fence_default_wait_cb+0x10/0x10 août 02 01:07:39 reveillon kernel: dma_fence_wait_timeout+0x10c/0x130 août 02 01:07:39 reveillon kernel: dma_resv_wait_timeout+0x7f/0xe0 août 02 01:07:39 reveillon kernel: ttm_bo_delayed_delete+0x2a/0x80 [ttm] août 02 01:07:39 reveillon kernel: process_one_work+0x1c7/0x3d0 août 02 01:07:39 reveillon kernel: worker_thread+0x51/0x390 août 02 01:07:39 reveillon kernel: ? __pfx_worker_thread+0x10/0x10 août 02 01:07:39 reveillon kernel: kthread+0xf7/0x130 août 02 01:07:39 reveillon kernel: ? __pfx_kthread+0x10/0x10 août 02 01:07:39 reveillon kernel: ret_from_fork+0x2c/0x50 août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: INFO: task kworker/u8:0:26079 blocked for more than 120 seconds. août 02 01:07:39 reveillon kernel: Tainted: G OE 6.4.0-1- amd64 #1 Debian 6.4.4-1 août 02 01:07:39 reveillon kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. août 02 01:07:39 reveillon kernel: task:kworker/u8:0 state:D stack:0 pid:26079 ppid:2 flags:0x4000 août 02 01:07:39 reveillon kernel: Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau] août 02 01:07:39 reveillon kernel: Call Trace: août 02 01:07:39 reveillon kernel: août 02 01:07:39 reveillon kernel: __schedule+0x3df/0xb80 août 02 01:07:39 reveillon ke
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:49 +0200, Gaëtan Perrier a écrit : > Le lundi 31 juillet 2023 à 12:42 +0200, Gaëtan Perrier a écrit : > > Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des freeze > > ou > > pas ... > > > > Pas eu besoin d'attendre longtemps :( > Freeze juste après l'envoi du message précédent. > > Rien dans /var/log/syslog à part une série de ^@ > > Gaëtan > Concernant les freeze j'ai avancé. Ce soir pendant le freeze je me suis connecté en ssh depuis une autre machine et c'est gnome-shell qui freeze en consommant 100% d'un cœur. Mais les fois d'avant je n'avais pas été assez patient parce que là en attendant je me suis aperçu que ça defreeze ! Et dans journalctl j'ai cette trace qui est apparue à ce moment là: geoclue[46380]: Service not used for 60 seconds. Shutting down.. systemd[1]: geoclue.service: Deactivated successfully. Et 60 s ce n'est pas impossible que ce soit la durée du freeze ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mardi 01 août 2023 à 22:02 +0200, didier gaumet a écrit : > Le 01/08/2023 à 21:27, Gaëtan Perrier a écrit : > > > Probablement lié à un problème avec openvpn: > [...] > > ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP > > device (--dev) > [...] > > unexpected end of data at line 1 column 1 of the JSON data > > gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: > > unexpected end of data at line 1 column 1 of the JSON data > > Ce n'est qu'une impression mais l'erreur openvpn ne me semble pas liée à > l'erreur gnome-shell (je peux me tromper) > > de toute façon, tu peux essayer de solutionner le pb openvpn eb > paramétrant le périphérique TUN/TAP, si tu as de la chance ça résoudra > aussi le pb gnome-shell > J'aimerai bien mais je n'ai pas trouvé de conf où il manque de tun/tap ... Gaêtan signature.asc Description: This is a digitally signed message part
Re: gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le 01/08/2023 à 21:27, Gaëtan Perrier a écrit : Probablement lié à un problème avec openvpn: [...] ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP device (--dev) [...] unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Ce n'est qu'une impression mais l'erreur openvpn ne me semble pas liée à l'erreur gnome-shell (je peux me tromper) de toute façon, tu peux essayer de solutionner le pb openvpn eb paramétrant le périphérique TUN/TAP, si tu as de la chance ça résoudra aussi le pb gnome-shell
gnome-shell erreur JSON (était Re: [testing] passage du pilote proprio à nouveau)
Le mardi 01 août 2023 à 13:55 +0200, didier gaumet a écrit : > Le 01/08/2023 à 13:52, didier gaumet a écrit : > > > apparemment (vu que JSON et moi ça fait deux) ce pourrait être un > > argument vide passé en paramètre qui déclencherait cette erreur. Regarde > > éventuellement dans les lignes précédentes si tu vois où / dans quoi ça > > a lieu (plus précisément que gnome-shell) > > j'ai oublié de précisé que je n'avais pas ce genre d'erreur renvoyé par > journalctl > > Probablement lié à un problème avec openvpn: systemd[1]: openvpn@update-systemd-resolved.service: Scheduled restart job, restart counter is at 226. systemd[1]: Stopped openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: Starting openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved... ovpn-update-systemd-resolved[14381]: Options error: You must define TUN/TAP device (--dev) systemd[1]: openvpn@update-systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE ovpn-update-systemd-resolved[14381]: Use --help for more information. systemd[1]: openvpn@update-systemd-resolved.service: Failed with result 'exit- code'. systemd[1]: Failed to start openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: openvpn@update-systemd-resolved.service: Scheduled restart job, restart counter is at 227. systemd[1]: Stopped openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. systemd[1]: Starting openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved... ovpn-update-systemd-resolved[14404]: Options error: You must define TUN/TAP device (--dev) ovpn-update-systemd-resolved[14404]: Use --help for more information. systemd[1]: openvpn@update-systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: openvpn@update-systemd-resolved.service: Failed with result 'exit- code'. systemd[1]: Failed to start openvpn@update-systemd-resolved.service - OpenVPN connection to update-systemd-resolved. gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data gnome-shell[11345]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 13:52, didier gaumet a écrit : apparemment (vu que JSON et moi ça fait deux) ce pourrait être un argument vide passé en paramètre qui déclencherait cette erreur. Regarde éventuellement dans les lignes précédentes si tu vois où / dans quoi ça a lieu (plus précisément que gnome-shell) j'ai oublié de précisé que je n'avais pas ce genre d'erreur renvoyé par journalctl
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 12:14, Gaëtan Perrier a écrit : Ah je ne savais pas mais je viens de regarder dedans et rien au niveau du freeze d'hier à part des quantités de log gnome-shell[3330]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Mais y en a plein en permanence de ces logs. Gaëtan apparemment (vu que JSON et moi ça fait deux) ce pourrait être un argument vide passé en paramètre qui déclencherait cette erreur. Regarde éventuellement dans les lignes précédentes si tu vois où / dans quoi ça a lieu (plus précisément que gnome-shell)
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 12:14 +0200, didier gaumet a écrit : > Le 01/08/2023 à 12:04, Gaëtan Perrier a écrit : > > > Chez moi ça tourne bien en user sans avoir la ligne needs_root_rights=no > > > > ~$ ps aux | grep Xorg > > gpe 3127 2.5 0.6 460772 109108 tty2 Sl+ 11:44 0:27 > > /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority - > > nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 > > tu utilises gdm avec Systemd donc je crois que tu trouveras ses messages > (ceux de gdm) via journalctl: > https://wiki.archlinux.org/title/Xorg#General > oui c'est celà: gdm et systemd mais rien dans journalctl (voir une de mes autres réponses d'aujourd'hui) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 12:14, didier gaumet a écrit : tu utilises gdm avec Systemd donc je crois que tu trouveras ses messages (ceux de gdm) via journalctl: https://wiki.archlinux.org/title/Xorg#General et en l'occurrence, ceux de Xorg, normalement
Re: [testing] passage du pilote proprio à nouveau
Le 1 août 2023 Michel a écrit : > Effectivement, c'est LightDM que j'utilise ( avec XFCE ). Ah ba oui le postulat de base dont on parlait c'est lancer Xorg sans DE...
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 12:04, Gaëtan Perrier a écrit : Chez moi ça tourne bien en user sans avoir la ligne needs_root_rights=no ~$ ps aux | grep Xorg gpe 3127 2.5 0.6 460772 109108 tty2Sl+ 11:44 0:27 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority - nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 tu utilises gdm avec Systemd donc je crois que tu trouveras ses messages (ceux de gdm) via journalctl: https://wiki.archlinux.org/title/Xorg#General
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 15:15 +0200, Erwan David a écrit : > Le 31/07/2023 à 14:00, didier gaumet a écrit : > > Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : > > > > > Pas eu besoin d'attendre longtemps :( > > > Freeze juste après l'envoi du message précédent. > > > > > > Rien dans /var/log/syslog à part une série de ^@ > > > > Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? > > Pour Wayland il faudra fouiller dans les résultats de journalctl, pour > > Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu > > de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je > > ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas > > sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log > > ou /var/log/Xorg.0.log. > > > > Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les > > chaînes EE pour les erreurs et WW pour les avertissements, le reste je > > crois que c'est principalement II pour info (me rappelle pas bien) > > > > Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous > > parlait de plongée récemment sur cette liste), tu peux essayer de > > debugger tout ça: > > https://x.org/wiki/Development/Documentation/ServerDebugging/ > > > > > En testing ça fait plusieurs mois que les logs users après sddm sont > dans journal, plus dans .xsession-errors > Ah je ne savais pas mais je viens de regarder dedans et rien au niveau du freeze d'hier à part des quantités de log gnome-shell[3330]: failed to decode base64 json SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data Mais y en a plein en permanence de ces logs. Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 11:51, Gaëtan Perrier a écrit : Le lundi 31 juillet 2023 à 14:00 +0200, didier gaumet a écrit : Je suis sous xorg et systemd Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Rien de tel dans mon rép user L'emplacement local que j'ai cité pour du X11 rootless ne semble plus d'actualité. Dans un autre message, Michel Verdier a évoqué un endroit différent (~/.local/share/xorg/Xorg.0.log) et le wiki Archlinux va dans le même sens: https://wiki.archlinux.org/title/Xorg#General
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 08:50 +0200, Michel Verdier a écrit : > Le 1 août 2023 Michel a écrit : > > > > > Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par > > > > défaut, sans modification de startx ou de ~/.xsession ... > > > > > > Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users > > > n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit > > > avoir needs_root_rights=no (du moins si ta carte graphique le permet). > > > > Non, j'ai seulement une ligne non commentée: > > > > allowed_users=console > > Ok donc tu dois tourner en root. Vérifie avec un ps aux | grep Xorg > et si Xorg est en root ajoute needs_root_rights=no dans > /etc/X11/Xwrapper.config. C'est mieux pour la sécurité. > Mais ça peut coincer si tu as une carte graphique qui requiert les droits > root (c'est rare mais il y en a). > Chez moi ça tourne bien en user sans avoir la ligne needs_root_rights=no ~$ ps aux | grep Xorg gpe 3127 2.5 0.6 460772 109108 tty2Sl+ 11:44 0:27 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority - nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3 Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le mardi 01 août 2023 à 07:03 +0200, Michel Verdier a écrit : > Le 31 juillet 2023 Michel a écrit : > > > > Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs > > > mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log > > > > Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par > > défaut, sans modification de startx ou de ~/.xsession ... > > Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users > n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit > avoir needs_root_rights=no (du moins si ta carte graphique le permet). > Chez ce fichier date du 1/4/2014 et contient ceci: # Xwrapper.config (Debian X Window System server wrapper configuration file) # # This file was generated by the post-installation script of the x11-common # package using values from the debconf database. # # See the Xwrapper.config(5) manual page for more information. # # This file is automatically updated on upgrades of the x11-common package # *only* if it has not been modified since the last upgrade of that package. # # If you have edited this file but would like it to be automatically updated # again, run the following command as root: # dpkg-reconfigure x11-common allowed_users=console Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 15:13 +0200, Michel Verdier a écrit : > Le 31 juillet 2023 didier gaumet a écrit : > > > Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? > > Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg > > lancé par un utilisateur avec un DE il faudra regarder le contenu de > > ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me > > souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour > > un > > Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou > > /var/log/Xorg.0.log. > > Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs > mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log Effectivement j'ai bien des fichiers log dans .local/share mais soit d'aujourd'hui soit du mois d'octobre ... Donc rien sur les dates des plantages et aucune erreur dans ceux d'aujourd'hui. Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Tuesday 01 August 2023 07:03:08 Michel Verdier wrote: > Ce ne serait pas parce que Xorg est lancé en root ? > Par défaut les users n'ont pas accès à /var/log. > Vérifie /etc/X11/Xwrapper.config qui doit > avoir needs_root_rights=no (du moins si ta carte graphique le permet). Pour accéder aux configs de Xorg, il faut être root, ils sont dans /etc/X11/ Je ne me suis jamais préoccupé d'un mode Xorg en root ou user...
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 14:00 +0200, didier gaumet a écrit : > Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : > > > Pas eu besoin d'attendre longtemps :( > > Freeze juste après l'envoi du message précédent. > > > > Rien dans /var/log/syslog à part une série de ^@ > > Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? Je suis sous xorg et systemd > Pour Wayland il faudra fouiller dans les résultats de journalctl, pour > Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu > de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne > me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Rien de tel dans mon rép user > Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou > /var/log/Xorg.0.log. Depuis le passage à nouveau les Xorg.*.log ne sont plus créés. > > Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les > chaînes EE pour les erreurs et WW pour les avertissements, le reste je > crois que c'est principalement II pour info (me rappelle pas bien) > > Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous > parlait de plongée récemment sur cette liste), tu peux essayer de > debugger tout ça: > https://x.org/wiki/Development/Documentation/ServerDebugging/ > Pour la plongée je manque de souffle actuellement ;) Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 10:30, didier gaumet a écrit :
> Le 01/08/2023 à 09:22, Michel a écrit :
>
>> Je viens de faire le test, en ajoutant needs_root_rights=no à la fin du
>> fichier /etc/X11/Xwrapper.config.
>> Après un arrêt puis un démarrage de la machine, Xorg est toujours lancé
>> en root. Ma configuration était d'origine et non modifiée ( Xorg n'est
>> pas lancé depuis une console, mais depuis l'écran graphique de connexion ).
>
> certains display managers ("l'écran graphique de connexion") ne
> supportent pas le mode rootless. Parmi les display managers actuellement
> maintenus, GDM et SDDM acceptent le mode rootless, LightDM et XDM ne
> l'accpetent pas, TDM (le DM de Trinity), je ne sais pas mais je suppose
> que non car il doit être dérivé de KDM, abandonné:
> https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
Effectivement, c'est LightDM que j'utilise ( avec XFCE ).
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 09:22, Michel a écrit :
Je viens de faire le test, en ajoutant needs_root_rights=no à la fin du
fichier /etc/X11/Xwrapper.config.
Après un arrêt puis un démarrage de la machine, Xorg est toujours lancé
en root. Ma configuration était d'origine et non modifiée ( Xorg n'est
pas lancé depuis une console, mais depuis l'écran graphique de connexion ).
certains display managers ("l'écran graphique de connexion") ne
supportent pas le mode rootless. Parmi les display managers actuellement
maintenus, GDM et SDDM acceptent le mode rootless, LightDM et XDM ne
l'accpetent pas, TDM (le DM de Trinity), je ne sais pas mais je suppose
que non car il doit être dérivé de KDM, abandonné:
https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 09:00, Michel Verdier a écrit : > Le 1 août 2023 Michel a écrit : > Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par défaut, sans modification de startx ou de ~/.xsession ... >>> >>> Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users >>> n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit >>> avoir needs_root_rights=no (du moins si ta carte graphique le permet). >> >> Non, j'ai seulement une ligne non commentée: >> >> allowed_users=console > > Ok donc tu dois tourner en root. Vérifie avec un ps aux | grep Xorg > et si Xorg est en root ajoute needs_root_rights=no dans > /etc/X11/Xwrapper.config. C'est mieux pour la sécurité. > Mais ça peut coincer si tu as une carte graphique qui requiert les droits > root (c'est rare mais il y en a). Je viens de faire le test, en ajoutant needs_root_rights=no à la fin du fichier /etc/X11/Xwrapper.config. Après un arrêt puis un démarrage de la machine, Xorg est toujours lancé en root. Ma configuration était d'origine et non modifiée ( Xorg n'est pas lancé depuis une console, mais depuis l'écran graphique de connexion ).
Re: [testing] passage du pilote proprio à nouveau
Le 1 août 2023 Michel a écrit : >>> Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par >>> défaut, sans modification de startx ou de ~/.xsession ... >> >> Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users >> n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit >> avoir needs_root_rights=no (du moins si ta carte graphique le permet). > > Non, j'ai seulement une ligne non commentée: > > allowed_users=console Ok donc tu dois tourner en root. Vérifie avec un ps aux | grep Xorg et si Xorg est en root ajoute needs_root_rights=no dans /etc/X11/Xwrapper.config. C'est mieux pour la sécurité. Mais ça peut coincer si tu as une carte graphique qui requiert les droits root (c'est rare mais il y en a).
Re: [testing] passage du pilote proprio à nouveau
Le 01/08/2023 à 07:10, Michel Verdier a écrit : > Le 31 juillet 2023 Michel a écrit : > >>> Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs >>> mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log >> >> Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par >> défaut, sans modification de startx ou de ~/.xsession ... > > Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users > n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit > avoir needs_root_rights=no (du moins si ta carte graphique le permet). Non, j'ai seulement une ligne non commentée: allowed_users=console
Re: [testing] passage du pilote proprio à nouveau
Le 31 juillet 2023 Michel a écrit : >> Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs >> mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log > > Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par > défaut, sans modification de startx ou de ~/.xsession ... Ce ne serait pas parce que Xorg est lancé en root ? Par défaut les users n'ont pas accès à /var/log. Vérifie /etc/X11/Xwrapper.config qui doit avoir needs_root_rights=no (du moins si ta carte graphique le permet).
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:05, didier gaumet a écrit : Le 31/07/2023 à 14:00, didier gaumet a écrit : [...] Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. [...] (je suis pénible à ne pas me relire soigneusement): Pour un Xorg lancé par root ce devrait être /var/log/Xorg.log ou /var/log/Xorg.0.log. Merci à Michel, Michel et Erwan pour les précisions :-) Donc en cas de besoin chercher à tous les endroits mentionnés et pour éviter les erreurs, vérifier les dates incluses dans les logs pour vérifier qu'on regarde bien le bon fichier log, pas un vieux fichier log plus utilisé
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 15:20, Michel Verdier a écrit : > Le 31 juillet 2023 didier gaumet a écrit : > >> Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? >> Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg >> lancé par un utilisateur avec un DE il faudra regarder le contenu de >> ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me >> souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un >> Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou >> /var/log/Xorg.0.log. > > Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs > mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log Sur ma debian de base, les logs sont bien dans /var/log/Xorg.0.log par défaut, sans modification de startx ou de ~/.xsession ...
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:00, didier gaumet a écrit : Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les chaînes EE pour les erreurs et WW pour les avertissements, le reste je crois que c'est principalement II pour info (me rappelle pas bien) Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous parlait de plongée récemment sur cette liste), tu peux essayer de debugger tout ça: https://x.org/wiki/Development/Documentation/ServerDebugging/ En testing ça fait plusieurs mois que les logs users après sddm sont dans journal, plus dans .xsession-errors -- Erwan David
Re: [testing] passage du pilote proprio à nouveau
Le 31 juillet 2023 didier gaumet a écrit : > Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? > Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg > lancé par un utilisateur avec un DE il faudra regarder le contenu de > ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me > souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un > Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou > /var/log/Xorg.0.log. Si on modifie startx, ~/.xsession, etc, on peut avoir les logs ailleurs mais sinon on les a dans ~/.local/share/xorg/Xorg.0.log
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 14:00, didier gaumet a écrit : [...] Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. [...] (je suis pénible à ne pas me relire soigneusement): Pour un Xorg lancé par root ce devrait être /var/log/Xorg.log ou /var/log/Xorg.0.log.
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 12:49, Gaëtan Perrier a écrit : Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Tu es sous Wayland ou Xorg (et tu es bien sous Systemd pax SysV)? Pour Wayland il faudra fouiller dans les résultats de journalctl, pour Xorg lancé par un utilisateur avec un DE il faudra regarder le contenu de ~/.xsession-errors, pour Xorg lancé par un utilisateur sans DE, je ne me souviens plus, c'est peut-être plutôt ~/.xinitquelquechose (pas sûr). Pour un Xorg lancé par root ce devrait être /var/log/Xorg.0.log ou /var/log/Xorg.0.log. Pour tous les fichiers d'erreur Xorg, de mémoire il faut chercher les chaînes EE pour les erreurs et WW pour les avertissements, le reste je crois que c'est principalement II pour info (me rappelle pas bien) Et si tu veux vraiment faire de la plongée (je ne sais plus qui nous parlait de plongée récemment sur cette liste), tu peux essayer de debugger tout ça: https://x.org/wiki/Development/Documentation/ServerDebugging/
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:42 +0200, Gaëtan Perrier a écrit : > Pour l'instant ça semble tourner. Reste à voir si j'ai toujours des freeze ou > pas ... > Pas eu besoin d'attendre longtemps :( Freeze juste après l'envoi du message précédent. Rien dans /var/log/syslog à part une série de ^@ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 12:05 +0200, didier gaumet a écrit : > Le 31/07/2023 à 11:18, Gaëtan Perrier a écrit : > [...] > > Par contre depuis j'ai constaté que si je mets un fichier xorg.cong > > basique: > > > > Section "Device" > > Identifier "MyGPU" > > Driver "nouveau" > > EndSection > > > > Le support des décodeurs en user est ok ... > > Donc problème résolu ou il reste un autre truc qui ne marche pas (j'ai > pas épluché les sorties de commandes que tu as citées) ? > Alors finalement j'ai fait l'extraction depuis le pilote 340.xxx et ça me sort beaucoup plus de firmwares: ~$ ls /lib/firmware/nouveau/ nv106_fuc084nv98_vp nvc0_bsp nvcf_fuc085 nvf1_fuc084 nv106_fuc085nva3_bsp nvc0_fuc084 nvcf_fuc086 nvf1_fuc085 nv106_fuc086nva3_fuc084 nvc0_fuc085 nvd7_fuc084 nvf1_fuc086 nv108_fuc084nva3_fuc085 nvc0_fuc086 nvd7_fuc085 vuc-h264-0 nv108_fuc085nva3_fuc086 nvc0_ppp nvd7_fuc086 vuc-mpeg12-0 nv108_fuc086nva3_ppp nvc0_vp nvd9_fuc084 vuc-mpeg4-0 nv84_bspnva3_vp nvc1_fuc084 nvd9_fuc085 vuc-mpeg4-1 nv84_bsp-h264 nva5_fuc084 nvc1_fuc085 nvd9_fuc086 vuc-vc1-0 nv84_vp nva5_fuc085 nvc1_fuc086 nve0_bsp vuc-vc1-1 nv84_vp-h264-1 nva5_fuc086 nvc3_fuc084 nve0_vp vuc-vc1-2 nv84_vp-h264-2 nva8_fuc084 nvc3_fuc085 nve4_fuc084 vuc-vp3-h264-0 nv84_vp-mpeg12 nva8_fuc085 nvc3_fuc086 nve4_fuc085 vuc-vp3-mpeg12-0 nv84_vp-vc1-1 nva8_fuc086 nvc4_fuc084 nve4_fuc086 vuc-vp3-vc1-0 nv84_vp-vc1-2 nvaa_fuc084 nvc4_fuc085 nve6_fuc084 vuc-vp3-vc1-1 nv84_vp-vc1-3 nvaa_fuc085 nvc4_fuc086 nve6_fuc085 vuc-vp3-vc1-2 nv84_xuc00f nvaa_fuc086 nvc8_fuc084 nve6_fuc086 vuc-vp4-h264-0 nv84_xuc103 nvac_fuc084 nvc8_fuc085 nve7_fuc084 vuc-vp4-mpeg12-0 nv98_bspnvac_fuc085 nvc8_fuc086 nve7_fuc085 vuc-vp4-mpeg4-0 nv98_fuc084 nvac_fuc086 nvce_fuc084 nve7_fuc086 vuc-vp4-mpeg4-1 nv98_fuc085 nvaf_fuc084 nvce_fuc085 nvf0_fuc084 vuc-vp4-vc1-0 nv98_fuc086 nvaf_fuc085 nvce_fuc086 nvf0_fuc085 vuc-vp4-vc1-1 nv98_pppnvaf_fuc086 nvcf_fuc084 nvf0_fuc086 vuc-vp4-vc1-2 Du coup en user vainfo me retourne : ~$ vainfo libva info: VA-API version 1.19.0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_17 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.19 (libva 2.12.0) vainfo: Driver version: Mesa Gallium driver 22.3.6 for NVCF vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc et vdpauinfo retourne toujours en user: ~$ vdpauinfo display: :1 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 42016384 16384 NV12 YV12 42216384 16384 UYVY YUYV 44416384 16384 Y8U8V8A8 V8U8Y8A8 420_16 16384 16384 422_16 16384 16384 444_16 16384 16384 Decoder capabilities: namelevel macbs width height MPEG1 0 8192 2048 2048 MPEG2_SIMPLE3 8192 2048 2048 MPEG2_MAIN 3 8192 2048 2048 H264_BASELINE 41 8192 2048 2048 H264_MAIN 41 8192 2048 2048 H264_HIGH 41 8192 2048 2048 VC1_SIMPLE 1 8190 2048 2048 VC1_MAIN2 8190 2048 2048 VC1_ADVANCED4 8190 2048 2048 MPEG4_PART2_SP 3 8192 2048 2048 MPEG4_PART2_ASP 5 8192 2048 2048 DIVX4_QMOBILE --- not supported --- DIVX4_MOBILE --- not supported --- DIVX4_HOME_THEATER --- not supported --- DIVX4_HD_1080P --- not supported --- DIVX5_QMOBILE --- not supported --- DIVX5_MOBILE --- not supported --- DIVX5_HOME_THEATER --- not supported --- DIVX5_HD_1080P --- not supported --- H264_CONSTRAINED_BASELINE 41 8192 2048 2048 H264_EXTENDED --- not supported --- H264_PROGRESSIVE_HIGH --- not supported --- H264_CONSTRAINED_HIGH --- not supported --- H264_HIGH_444_PREDICTIVE --- not supported --- VP9_PROFILE_0 --- not supported --- VP9_PROFILE_1 --- not supported --- VP9_PROFILE_2
Re: [testing] passage du pilote proprio à nouveau
Le 31/07/2023 à 11:18, Gaëtan Perrier a écrit : [...] Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique: Section "Device" Identifier "MyGPU" Driver "nouveau" EndSection Le support des décodeurs en user est ok ... Donc problème résolu ou il reste un autre truc qui ne marche pas (j'ai pas épluché les sorties de commandes que tu as citées) ?
Re: [testing] passage du pilote proprio à nouveau
Le lundi 31 juillet 2023 à 10:00 +0200, didier gaumet a écrit : > Le 31/07/2023 à 00:20, Gaëtan Perrier a écrit : > > Bonjour, > > > > Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à > > maintenant le pilote proprio nvidia 390.157. Tout fonctionnait > > parfaitement. > > Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré > > de > > debian testing j'ai donc décidé de passer à Nouveau. > > apparemment un autre possibilité serait de garder le pilote proprio en > passant de testing à Sid, le pilote proprio y étant toujours disponible > car des modifications mineures ont été apportées pour que ça puisse être > construit avec les noyaux récents, si j'ai bien suivi. A ce que j'ai compris le support "nouveau noyau" s'arrête au 6.3. Quand le 6.4 est arrivé sur ma machine son installation a échoué à cause des pilotes nvidia ... C'est ce qui a motivé mon passage à Nouveau. > > Après c'est à toi de voir, chacun a une perception différente. Perso, > pour moi Debian c'est intéressant en Stable. Mais j'ai déjà joué avec > Testing et Sid par le passé et même Sid+experimental récemment. Je > préférerais suivre Sid que testing, à titre perso, toujours. Ma perception est effectivement différente. ;) Pour moi stable c'est bien sur un serveur. Pour une machine de bureau les appli ne suivent pas assez vite même avec les backports. Après entre testing et sid je n'ai pas vraiment d'avis mais comme ça doit bien faire 20 ans que je tourne en testing (+ qq morceaux sid) je n'ai jamais changé. > > > Mais depuis j'ai régulièrement des freezes et j'ai des doutes sur le fait > > que > > ma config soit correcte. > > > > Pour passer du pilote proprio à Nouveau j'ai donc supprimé tous les paquets > > nvidia-* et libnvidia* > > J'ai supprimé le xorg.conf. > > t'as supprimé ou purgé? Si tu as seulement supprimé, fais un purge des > mêmes paquets, ça peut aider C'était bien un purge qui a été réalisé. > > > J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer > > les > > firmware du pilote 390.157. > > quelle page? oups j'ai oublié le lien :-( https://nouveau.freedesktop.org/VideoAcceleration.html > > > J'ai réussi, après quelques modif du script > > extract_firmware.py, à récupérer les fichiers suivant: > [...] > > tu as essayé avec simplement les firmwares de testing? > firmware-misc-nonfree firmware-nvidia-gsp ou firmware-nvidia-tesla-gsp > A ce que j'ai compris les gsp ne concernent que les cartes depuis l'archi Turing, la mienne est une Fermi bien plus vieille. Pour misc-nonfree oui j'ai essayé mais je n'ai pas les décodeurs. Par contre depuis j'ai constaté que si je mets un fichier xorg.cong basique: Section "Device" Identifier "MyGPU" Driver "nouveau" EndSection Le support des décodeurs en user est ok ... A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] passage du pilote proprio à nouveau
On Monday 31 July 2023 00:20:58 Gaëtan Perrier wrote: > Mon PC étant assez âgé (i5-2500k et Nvidia GTX550Ti) j'utilisais jusqu'à > maintenant le pilote proprio nvidia 390.157. Tout fonctionnait parfaitement. > Ce pilote n'étant plus maintenu, pas compatible avec kernel 6.4 et retiré de > debian testing j'ai donc décidé de passer à Nouveau. Le pilote 390.157 proposé par Nvidia sur son site est en version 32 bits : www.nvidia.fr/Download/driverResults.aspx/196247/fr Pour créer un pilote Nouveau, il faut semble t-il un xorg.conf. J'ai tenté il y a peu, mais résolution maximum 1024X768, trop insuffisant, mais ça m'a permis d'avoir le mode graphique pour rechercher une solution. Désolé de ne pas t'aider plus...
