Re: [testing] plus de session graphique !

[Gaëtan Perrier]

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 !

[Sébastien NOBILI]

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 !

[Klaus Becker]

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 !

[Gaëtan Perrier]

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 !

[Gaëtan Perrier]

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 !

[Gaëtan Perrier]

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 !

[Gaëtan Perrier]

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 !

[Klaus Becker]

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 !

[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

Re: compatibilité matérielle Debian Testing Asus PRIME B650-Plus + AMD Ryzen 7 8700G + Corsaire VEgeance Black 2x16Go DDR5 5200MHz CL40

[Étienne Mollier]

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

[Basile Starynkevitch]

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=Rechercher_du=_au=_juridiction=all===0=1 
<https://www.courdecassation.fr/decision/65cdbcdf2425a70008258563?search_api_fulltext=licence%20GPL=Rechercher_du=_au=_juridiction=all===0=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

[BERTRAND Joël]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[BERTRAND Joël]

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

[ajh-valmer]

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

[BERTRAND Joël]

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

[Gaëtan Perrier]

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

[BERTRAND Joël]

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

[ajh-valmer]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[Michel Verdier]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[ajh-valmer]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[ajh-valmer]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[ajh-valmer]

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)

[didier gaumet]

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)

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[didier gaumet]

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)

[didier gaumet]

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

[Gaëtan Perrier]

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 

Re: [testing] passage du pilote proprio à nouveau

[Gaëtan Perrier]

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)

[Gaëtan Perrier]

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)

[didier gaumet]

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)

[Gaëtan Perrier]

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

[didier gaumet]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[Michel Verdier]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[ajh-valmer]

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

[Gaëtan Perrier]

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

[Michel]

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

[didier gaumet]

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

[Michel]

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

[Michel Verdier]

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

[Michel]

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

[Michel Verdier]

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

[didier gaumet]

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

[Michel]

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

[Erwan David]

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

[Michel Verdier]

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

[didier gaumet]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[Gaëtan Perrier]

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

[didier gaumet]

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

[Gaëtan Perrier]

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

[ajh-valmer]

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...

Re: [testing] passage du pilote proprio à nouveau

[didier gaumet]

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.


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.



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



J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer les
firmware du pilote 390.157. 


quelle page?


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

[testing] passage du pilote proprio à nouveau

[Gaëtan Perrier]

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.
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.
J'ai essayé de suivre cette page (qui ne semble pas à jour) pour récupérer les
firmware du pilote 390.157. J'ai réussi, après quelques modif du script
extract_firmware.py, à récupérer les fichiers suivant:

/lib/firmware/nouveau]# ls
vuc-h264-0  vuc-vc1-0  vuc-vc1-1  vuc-vc1-2  vuc-vp4-h264-0  vuc-vp4-vc1-0 
vuc-vp4-vc1-1  vuc-vp4-vc1-2

Après reboot en root j'obtiens les résultats en ci-dessous pour vainfo et
vdpauinfo.
Mais en user j'obtiens un résultat différent notamment pour vdpauinfo où les
decoder ne sont pas présent ci-dessous également

glxinfo est similaire dans les 2 cas.

Bref je suis un peu perdu et les infos sur https://nouveau.freedesktop.org
semblent vraiment pas à jour :(

Qu'en pensez ? Qu'est-ce que j'ai loupé ?

Gaëtan

root

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  --- not supported ---
MPEG2_SIMPLE   --- not supported ---
MPEG2_MAIN --- not supported ---
H264_BASELINE  --- not supported ---
H264_MAIN  --- not supported ---
H264_HIGH  --- not supported ---
VC1_SIMPLE --- not supported ---
VC1_MAIN   --- not supported ---
VC1_ADVANCED   --- not supported ---
MPEG4_PART2_SP --- not supported ---
MPEG4_PART2_ASP--- not supported ---
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  --- not supported ---
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  --- not supported ---
VP9_PROFILE_3  --- not supported ---
HEVC_MAIN  --- not supported ---
HEVC_MAIN_10   --- not supported ---
HEVC_MAIN_STILL--- not supported ---
HEVC_MAIN_12   --- not supported ---
HEVC_MAIN_444  --- not supported ---
HEVC_MAIN_444_10   --- not supported ---
HEVC_MAIN_444_12   --- not supported ---
AV1_MAIN   --- not supported ---
AV1_HIGH   --- not supported ---
AV1_PROFESSIONAL   --- not supported ---

Output surface:

name  width height nat types

B8G8R8A8 16384 16384y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010
P016 A4I4 I4A4 A8I8 I8A8 
R8G8B8A8 16384 16384y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010
P016 A4I4 I4A4 A8I8 I8A8 
R10G10B10A2  16384 16384y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010
P016 A4I4 I4A4 A8I8 I8A8 
B10G10R10A2  16384 16384y  NV12 YV12 UYVY YUYV Y8U8V8A8 V8U8Y8A8 P010
P016 A4I4 I4A4 A8I8 I8A8 

Bitmap surface:

name  width height
--
B8G8R8A8 16384 16384
R8G8B8A8 16384 16384
R10G10B10A2  16384 16384
B10G10R10A2  16384 16384
A8   16384 16384

Video mixer:

feature namesup

DEINTERLACE_TEMPORAL y
DEINTERLACE_TEMPORAL_SPATIAL -
INVERSE_TELECINE -
NOISE_REDUCTION  y
SHARPNESSy
LUMA_KEY y
HIGH QUALITY SCALING - L1y
HIGH QUALITY SCALING - L2-
HIGH QUALITY SCALING - L3

Re: Signature des dépôts externes (was: Re: Étrange réponse de apt après passage de testing à stable)

[didier gaumet]

Bonjour,

pas lu les liens, pressé ce matin,

par contre la clé à récupérer est in diquée sur le site rasbpian:
http://raspbian.org/RaspbianRepository

c'est la ligne "wget...", il faut juste l'adapter pour utiliser 
directement gpg au lieu de apt-key (commande rendue obsolète).


voir le wiki Debian:
https://wiki.debian.org/DebianRepository/UseThirdParty

ça doit te donner un truc (en root) du style (attention, sur une seule 
ligne, ne pas se fier au formatage dû aux mails/news):
curl https://archive.raspbian.org/raspbian.public.key | gpg -o 
/usr/share/keyrings/raspbian.public.key --dearmor


à la louche, hein, j'ai pas testé :-)

Signature des dépôts externes (was: Re: Étrange réponse de apt après passage de testing à stable)

[yamo']

Salut,
yamo' a écrit :
> Salut,

> J'ai la commande  apt full-upgrade qui me réponds :
> ...
> 0 mis à jour, 0 nouvellement installés, 760 remis à une version
> inférieure, 0 à enlever et 0 non mis à jour.
> Il est nécessaire de prendre 237 Mo dans les archives.
> Après cette opération, 80,9 Mo d'espace disque seront libérés.
> Souhaitez-vous continuer ? [O/n]

En fait, j'ai l'impression que c'est par ce que les dépôts raspbian sont 
refusés à cause d'une erreur de stockage de clé qui n'est plus acceptée 
sur Debian 12.

Comme c'était un simple warning, je ne pensais pas que ça avait des 
conséquences...

http://al.howardknight.net/?STYPE=msgid=%3CAABkmVWhMG0AAkjf.A3.flnews%40yamo.pasdenom.info%3E

https://news2web.pasdenom.info/article.php?id=35401=fr.comp.os.linux.configuration


Par contre, je n'ai pas encore réussi à corriger le problème. J'avoue 
avoir du mal à suivre les pistes trouvées :

 
 

 

-- 
Stéphane 

Re: Étrange réponse de apt après passage de testing à stable

[didier gaumet]

Le 23/06/2023 à 12:53, yamo' a écrit :

Salut,

Merci pour la réponse.

C'est une machine que j'ai passé en bookworm aux environ le 8 juin et
qui depuis était éteinte (elle me sert pour la montée de version d'une
autre machine).


OK


Et j'utilise dans les sources.list les noms de version et pas stable.


OK


Comme j'ai écrit dans le post d'origine, je pense que c'est un faux
downgrade ; je découvre que apt sais faire ça alors que la dernière fois
que j'avais vu ça c'était sur une CentOS ( 6 ou 5?).

Mais je n'ai pas moyen de le vérifier pour tous les paquets, je suspecte
un autre fichier de configuration que les sources.list mal édité mais je
ne connais pas assez bien Debian ou alors une opération non faite lors
du précédent full-upgrade...
Vérifie, ça ne mange pas de pain, que non seulement tu n'as, 
exclusivement que des références à bookworm,

- non seulement dans ton /etc/apt/sources.list
- mais aussi dans d'éventuels fichiers présents dans le répertoire 
/etc/apt/sources.list.d/
(par exemple chez moi il y a un fichier teamviewer.list qui fait 
référence à "stable": si je n'avais pas un apt update depuis le 10 juin, 
sortie de Bookworm, il y aurait peut-être (pas sûr) des soucis aussi)

Re: Étrange réponse de apt après passage de testing à stable

[yamo']

Salut,

Merci pour la réponse.

didier gaumet a tapoté le 23/06/2023 12:30:
> Le 23/06/2023 à 10:53, yamo' a écrit :

>> J'ai la commande  apt full-upgrade qui me réponds : ... 0 mis à
>> jour, 0 nouvellement installés, 760 remis à une version inférieure,
>> 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 237
>> Mo dans les archives. Après cette opération, 80,9 Mo d'espace
>> disque seront libérés. Souhaitez-vous continuer ? [O/n]
>> 
>> Comment corriger ça?
> [...] Bonjour,
> 
> Ben en fait, si tu as fait des mises à jour de ta distro depuis la 
> sortie de Debian 12 Bookworm, ton système (testing) correspondait à 
> l'état actuel de la future Debian 13 Trixie, pas à Debian 1é
> Bookworm, donc quand tu modifies ton sources.list pour y mettre (quoi
> d'abord? "stable"? "bookworm"?) apt te dit que c'est un downgrade,
> pas un upgrade.

C'est une machine que j'ai passé en bookworm aux environ le 8 juin et
qui depuis était éteinte (elle me sert pour la montée de version d'une
autre machine).
Et j'utilise dans les sources.list les noms de version et pas stable.

> Tu peux accepter un downgrade mais ce n'est pas supporté (les scripts
> ne sont pas prévus pour), donc même en cas de succès apparent, tu
> risques de galérer plus tard avec des problèmes dont tu auras du mal
> à tracer l'origine et qui seront potentiellement difficiles à
> solutionner. Dans ces cas là, une réinstallation propre est
> généralement conseillée...

Comme j'ai écrit dans le post d'origine, je pense que c'est un faux
downgrade ; je découvre que apt sais faire ça alors que la dernière fois
que j'avais vu ça c'était sur une CentOS ( 6 ou 5?).

Mais je n'ai pas moyen de le vérifier pour tous les paquets, je suspecte
un autre fichier de configuration que les sources.list mal édité mais je
ne connais pas assez bien Debian ou alors une opération non faite lors
du précédent full-upgrade...


-- 
Stéphane

Re: Étrange réponse de apt après passage de testing à stable

[didier gaumet]

Le 23/06/2023 à 10:53, yamo' a écrit :

Salut,

J'ai la commande  apt full-upgrade qui me réponds :
...
0 mis à jour, 0 nouvellement installés, 760 remis à une version
inférieure, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 237 Mo dans les archives.
Après cette opération, 80,9 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n]

Comment corriger ça?

[...]
Bonjour,

Ben en fait, si tu as fait des mises à jour de ta distro depuis la 
sortie de Debian 12 Bookworm, ton système (testing) correspondait à 
l'état actuel de la future Debian 13 Trixie, pas à Debian 1é Bookworm, 
donc quand tu modifies ton sources.list pour y mettre (quoi d'abord? 
"stable"? "bookworm"?) apt te dit que c'est un downgrade, pas un upgrade.


C'est pour ça qu'il est préférable, à moins de comprendre les dangers 
associés, de mettre dans le sources.list des noms de versions (bullseye, 
bookworm, trixie...) plutôt que stable ou testing


Tu peux accepter un downgrade mais ce n'est pas supporté (les scripts ne 
sont pas prévus pour), donc même en cas de succès apparent, tu risques 
de galérer plus tard avec des problèmes dont tu auras du mal à tracer 
l'origine et qui seront potentiellement difficiles à solutionner.

Dans ces cas là, une réinstallation propre est généralement conseillée...

Étrange réponse de apt après passage de testing à stable

[yamo']

Salut,

J'ai la commande  apt full-upgrade qui me réponds :
...
0 mis à jour, 0 nouvellement installés, 760 remis à une version
inférieure, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 237 Mo dans les archives.
Après cette opération, 80,9 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n]

Comment corriger ça?

Je ne vois pas comment vérifier les 760 paquets, j'en ai pris quelques
uns au hasard et apt policy me dit qu'en fait ça ne change pas de numéro
de version...

C'est sur une raspbian sur bookworm (j'étais passé de bullseye à testing
début juin).
Vu que c'est sur raspbian, j'ai forcément des paquets en double pour les
rares cas où il faut du spécifique à mon raspberry mais je n'ai jamais
eu de soucis avec ça (j'applique juste deux fois les mises à jours de
sécurité).

C'est sur un raspberry pi2 mais je doute que cette dernière information
soit utile.

Je précise que j'ai auparavant mis à jour les correctifs de sécurité qui
étaient bloqués par ce bug. En effet, la commande suivante me disait
quoi installer :
apt list --upgradable |  awk -F\/ '{ print $1 }'

-- 
Stéphane
Merci de répondre à la liste ou au newsgroup linux.debian.user.french

[regle] Re: [testing] crash firefox 114.0-1

[Gaëtan Perrier]

Le jeudi 22 juin 2023 à 22:33 +0200, Gaëtan Perrier a écrit :
> Bonjour,
> 
> Depuis ce soir suite aux mises à jours de testing du jour, firefox crash au
> démarrage même en --safe-mode.
> 
> ~$ firefox --safe-mode 
> ExceptionHandler::GenerateDump cloned child
> ExceptionHandler::WaitForContinueSignal waiting for continue signal...
> 16491
> ExceptionHandler::SendContinueSignalToChild sent continue signal to child
> Exiting due to channel error.
> Exiting due to channel error.
> ~$ Failed to open curl lib from binary, use libcurl.so instead
> ~$ 
> 
> Est-ce de même pour vous ?
> 
> Gaêtan

Bonjour,

Ce matin ça refonctionne ...

Gaëtan


signature.asc
Description: This is a digitally signed message part

[testing] crash firefox 114.0-1

[Gaëtan Perrier]

Bonjour,

Depuis ce soir suite aux mises à jours de testing du jour, firefox crash au
démarrage même en --safe-mode.

~$ firefox --safe-mode 
ExceptionHandler::GenerateDump cloned child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
16491
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
~$ Failed to open curl lib from binary, use libcurl.so instead
~$ 

Est-ce de même pour vous ?

Gaêtan


signature.asc
Description: This is a digitally signed message part

Re: [testing] shadow drive et debian

[Gaëtan Perrier]

Le samedi 15 avril 2023 à 19:01 +0200, Haricophile a écrit :
> Le Wed, 12 Apr 2023 23:10:01 +0200,
> Gaëtan Perrier  a écrit :
> 
> > Bonjour,
> > 
> > Je viens d'essayer d'installer le paquet deb shadow 8.0.10059 sur ma
> > debian testing.
> > Y a eu une erreur à la fin de l'installation du paquet mais ça s'est
> > installé quand même. Ensuite quand je lance l'appli shadow PC ça
> > m'ouvre une fenêtre me proposant de me logger via un navigateur. Ce
> > que je fais et là j'ai une erreur me disant "Connection failed" et me
> > disant que je n'ai pas de plan souscrit. Pourtant j'ai bien un shadow
> > drive. Est-ce quelqu'un rencontre le même soucis ou a réussi à se
> > connecter ?
> > 
> > Gaëtan
> 
> Plusieurs choses: 
> 
> - Ne pas confondre Shadow (l'ordinateur «cloud») et Shadow Drive (le
>   stockage cloud) !  Le paquet Debian n'est pas pour Shadow Drive, mais
>   pour l'ordinateur virtuel.
>   Donc avec la version appimage de Shadow DRIVE ça fonctionne très bien
>   chez moi.

Aahh !! C'est super pas clair sur la page de
téléchargement !
Maintenant ça fonctionne nickel ! :)

Merci beaucoup !

A+

Gaëtan





signature.asc
Description: This is a digitally signed message part

Re: [testing] shadow drive et debian

[Haricophile]

Le Wed, 12 Apr 2023 23:10:01 +0200,
Gaëtan Perrier  a écrit :

> Bonjour,
> 
> Je viens d'essayer d'installer le paquet deb shadow 8.0.10059 sur ma
> debian testing.
> Y a eu une erreur à la fin de l'installation du paquet mais ça s'est
> installé quand même. Ensuite quand je lance l'appli shadow PC ça
> m'ouvre une fenêtre me proposant de me logger via un navigateur. Ce
> que je fais et là j'ai une erreur me disant "Connection failed" et me
> disant que je n'ai pas de plan souscrit. Pourtant j'ai bien un shadow
> drive. Est-ce quelqu'un rencontre le même soucis ou a réussi à se
> connecter ?
> 
> Gaëtan

Plusieurs choses: 

- Ne pas confondre Shadow (l'ordinateur «cloud») et Shadow Drive (le
  stockage cloud) !  Le paquet Debian n'est pas pour Shadow Drive, mais
  pour l'ordinateur virtuel.
  Donc avec la version appimage de Shadow DRIVE ça fonctionne très bien
  chez moi.

- Si tu as des problème de connexion avec Firefox, essaye avec un
  profil vierge ou essaye avec Chromium. Je n'ai pas analysé finement,
  mais les container de Firefox ou des extensions peuvent
  éventuellement bloquer la procédure d'identification.

- Pour conserver le mot de passe sans ouvrir systématiquement le
  navigateur, ça fonctionne avec kwallet lancé, mais pas avec le truc
  de gnome, ou en tout cas pas out-of-box.

En dehors de ça j'utilise Shadow Drive de manière très satisfaisante,
ça marche autrement mieux que ce foutu Hubic !

Re: [testing] shadow drive et debian

[didier gaumet]

Je ne vais pas pouvoir être précis, ju n'utilise pas shadow et je n'ai
pas de souscription non plus

Il y a ici une liste de messages d'erreurs:
https://support.shadow.tech/hc/fr/articles/4763938067356-Codes-et-messages-d-erreur

Et particulièrement les L102/L104 qui pourraient s'appliquer:
https://support.shadow.tech/hc/fr/articles/360023594573-L-102-L-104-Le-launcher-n-a-pas-r%C3%A9ussi-%C3%A0-se-connecter-%C3%A0-Shadow

(info pas forcément utile pour toi) Au cas où tu voudrais passer par
d'autres clients que le clientb Shadow pour accéder à ton compte, on
peut y accéder par WebDav
https://support.shadow.tech/hc/fr/articles/6822936446364-Comment-connecter-un-logiciel-tiers-%C3%A0-Shadow-Drive-en-utilisant-le-protocole-WebDAV
-

sino ils ont un support, je pense que tu peux y faire appel, surout si
tu paies un abonnement ;-)
https://support.shadow.tech/hc/fr/categories/360001379574-Contacter-le-support

Re: [testing] shadow drive et debian

[Gaëtan Perrier]

Le jeudi 13 avril 2023 à 12:17 +0200, didier gaumet a écrit :
> Le mercredi 12 avril 2023 à 23:10 +0200, Gaëtan Perrier a écrit :
> > Bonjour,
> > 
> > Je viens d'essayer d'installer le paquet deb shadow 8.0.10059 sur ma
> > debian
> > testing.
> > Y a eu une erreur à la fin de l'installation du paquet mais ça s'est
> > installé
> > quand même. Ensuite quand je lance l'appli shadow PC ça m'ouvre une
> > fenêtre me
> > proposant de me logger via un navigateur. Ce que je fais et là j'ai
> > une erreur
> > me disant "Connection failed" et me disant que je n'ai pas de plan
> > souscrit.
> > Pourtant j'ai bien un shadow drive.
> > Est-ce quelqu'un rencontre le même soucis ou a réussi à se connecter
> > ?
> > 
> > Gaëtan
> 
> Bonjour,
> 
> tu as installé le paquet par dpkg ou apt (apt me semble préférable
> parce qu'il installe les dépendances)? quel était le message d'erreur?
> à la milite, purge et réinstalle pour avoir le message d'erreur parce
> que par définition, si il y a un message d'erreur, ça peut être un
> problème...
> (mais bon j'en sais rien, je ne connais pas Shadow (la société derrière
> et l'outil), j'ai juste lu que l'outil est basé sur Nextcloud)  
> 

J'ai purgé et réinstallé mais plus d'erreur mais ça ne fonctionne pas mieux
pour autant ...
Sinon shadow c'est le remplaçant de Hubic et c'est OVH derrière.

A+

Gaëtan


signature.asc
Description: This is a digitally signed message part