Re bonsoir,

Que de problème depuis le passage de Buster 32 bits à Bullseye 64 bits... ! (par une complète nouvelle installation à neuf).

1- DCOPserver (messages d'erreur),

2- ICEauthorithy (messages d'erreur),

3- /udev/rules.d/ inexistant,

4- maintenant, la carte Wifi realtek 2500 pourtant opérationnelle,
moults messages d'erreur sans connexion après "ifup <nom de l'interface>"
et m'efface sans arrêt le fichier "/etc/network/interfaces".

5 -Le boot est très très lent,

6 -La commande "/etc/init.d/networking restart" également.

Bref, c'est la déception. Buster marchait impeccable.

Ça fait beaucoup et je n'ai plus le temps d'y passer des heures...

Bonne soirée.

A. Valmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Ne le prends pas mal, je ne cherche aucunement à t'être désagréable,
mais je pense que c'est toi-même qui te crées inutilement des problèmes
:-)

Tu tiens à réappliquer des mesures que tu as prises par le passé, sans forcément bien en comprendre la portée, alors que, a minima, le
contexte a changé et que ce n'est pas forcément opportun.

De mémoire (perfectible chez moi):

- tes erreurs DCOP* et ICE* sont dues à ton installation de Trinity
Desktop. Si tu tiens à ce DE non supporté par Debian, tu gères les problèmes que tu introduis ainsi, tu ne les reportes pas sur Debian,
ils n'ont rien à voir avec Debian

- un répertoire /etc/udev/rules.d vide n'est pas un dysfonctionnement
mais le signe d'une absence de personnalisation des règles udev (seules
sont présentes les règles standard). Tu cherches simplement à te
rassurer en repeuplant ce répertoire parce que tu l'as connu peuplé
(par toi) par le passé. Répètons-le: tu n'as pas besoin de t'alarmer,
c'est une situation *normale*.

- tes aventures avec le wifi ont un schéma récurrent: tu cherches systématiquement à utiliser un gestionnaire de connexion (installé par
le DE) mais à paramétrer aussi /etc/network/interfaces. Parce que là
encore, ça te rassure. Dans mon fichiers interfaces, vu que j'utilise
un DE, il n'y a que l'interface lo (c'est-à-dire que je ne l'ai pas
modifié après installation). C'est le fonctionnement conseillé depuis
des lustres.

- le boot lent, sans autres infos, je n'ai pas d'idées, mais ça
pourrait être lié au point suivant

- La commande "/etc/init.d/networking restart" lente ou
dysfonctionnelle: soit tu as volontairement choisi de te passer de
Systemd au profit d'une initialisation à la Sysv et tu dois comprendre
les problèmes que tu vas avoir à résoudre, soit tu n'as touché à rien,
tu utilises systemd par défaut mais tu continues à utiliser des
commandes de l'ancien monde inadaptés dans le nouveau (à mon sens,
telinit, dans un contexte Systemd, peut engendrer des problèmes dus à
des traductions approximatives voire manquantes Systemd/Sysv).
a) Utilise donc la commande Systemctl au lieu de telinit: systemctl
restart networking au lieu de /etc/init.d/networking restart
b) tu n'en as, de plus, pas besoin: c'est le gestionnaire de connexion
qui gère ça et il fonctionne généralement bien si tu ne l'empêches pas
de fonctionner correctement

Donc, conclusion, selon tes propres mots, oui, "ça fait beaucoup" de problèmes que, selon moi, tu te crées :-)

Si tu me permets ce conseil: fais une installation *standard* de Debian
(à partir d'un medium comprenant les firmwares pour te faciliter la
vie), sans chercher à la personnaliser. lors de cette installation,
choisis le DE qui te plaît parmi ceux qui te sont proposés. Cela
devrait te procurer un système Debian fonctionnel. Si ensuite tu
rencontres des problèmes, reviens nous voir mais commence par les
problèmes principaux (réel fonctionnement) plutôt que les problèmes secondaires (personnalisation pour adéquation à tes goûts)

Bonne journée et bon Noël (avec un peu de retard) :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Sat, 25 Dec 2021 22:53:03 +0100,
"ajh-valmer" <ajh.valmer@free.fr> a écrit :

Re bonsoir,

Que de problème depuis le passage de Buster 32 bits à Bullseye 64
bits... ! (par une complète nouvelle installation à neuf).

1- DCOPserver (messages d'erreur),

2- ICEauthorithy (messages d'erreur),

3- /udev/rules.d/ inexistant,

Hum... tu as KDE je suppose ? il y a peut-être des problème avec les
configs et je n'ai pas d'expérience sur le passage 32-64bits. Et puis
quelles erreurs d'abord ? Moi j'essayerais de recréer un utilisateur
pour se débarrasser des très nombreuses scories de l'ancien KDE, ou au
moins tester la chose avec un profil neuf.

4- maintenant, la carte Wifi realtek 2500 pourtant opérationnelle,
moults messages d'erreur sans connexion après "ifup <nom de
l'interface>"

Quelles erreurs ?

< et m'efface sans arrêt le fichier

"/etc/network/interfaces".

C'est fait exprès, c'est ce qu'on appelle le progrès, quand on utilise
des outils de configuration automatique beaucoup plus souples et
opérationnels avec les configurations de plus en plus mouvantes
actuelles. Ça peut avoir son intérêt de lire de temps en temps les docs
et les changelog. Tu peux encore repasser en tout statique, mais
le choix de l'évolution de Debian (et de la plupart des distributions) a
été d'intégrer systemd et tout ça et d'avoir des configs
"plug'n play" adaptées aux usages actuels. On perd beaucoup en
simplicité de conception, on gagne beaucoup en souplesse
d'utilisation.

5 -Le boot est très très lent,

6 -La commande "/etc/init.d/networking restart" également.

C'est un peu délicat de répondre à ça sans aucune information précise.

Bref, c'est la déception. Buster marchait impeccable.

Bullseye marche impeccable chez moi et j'en suis très content, j'utilise
Mate par habitude, parce que je le connais sur le bout des doigts et
parce qu'il fait tout ce que je veux comme je veux; KDE je trouve que
c'est séduisant sur papier mais beaucoup trop complexe et lourd et me
fait perdre du temps plus qu'autre chose; Gnome3 a fait beaucoup de
progrès mais je suis plus a l'aise avec mate. XFCE n'a pas assez de différence pour que je change, et j'ai un usage trop "graphique" pour
utiliser i3.

Ça fait beaucoup et je n'ai plus le temps d'y passer des heures...

Je crois quand même qu'il faut accepter de perdre un peu de temps pour
en gagner ensuite. Comme je disais se tenir au courant au fur et à
mesure des évolutions (s'abonner à la mailing-list des news ?) et passer
un peu de temps à lire les docs... et ne pas oublier que c'est un
projet communautaire et non un produit commercial comme windows.

Bonne soirée.

A. Valmer

J'arrive un peu tard pour le bonne nuit, mais bonnes fêtes.

Amicalement
--
Jérôme Dautzenberg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sur ma Debian Bullseye,

je viens d'installer une machine virtuelle Debian Bullseye minimale
(juste "utilitaires du système" dans Tasksel à la fin de
l'installation, donc pas d'environnement graphique, dans ce cas le
réseau de la machine cible est configuré par l'installateur dans /etc/network/interfaces)

ensuite j'ai installé Trinity suivant les instructions de Trinity: https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions

j'ai juste rajouté l'environnement français (dans les paquets, tâches environnement français et bureau français) et le paquet kde-i18n-fr-
trinity (nom approximatif, je ne me souviens pas bien)

Résultat: pas de messages d'erreurs DCOP* ou ICE*, pas de pb de démarrage/arrêt lents.
La seule anomalie que j'ai remarquée est que en laissant la config
réseau dans /etc/network/interfaces j'avais accès à internet alors que
quand j'ai commenté l'interface dans /etc/network/interfaces,
impossible, même en mode super-utilisateur, de configurer le réseau à
partir des outils de configuration Trinity: l'interface était invisible
alors qu'elle était parfaitement visible depuis un terminal
(l'interface virtuelle de virt-manager/Qemu vue comme une interface
ethernet)

Donc à mon avis, Trinity, à part cette anomalie réseau (mais c'est peut-être moi qui n'ai pas suivi une procédure nécessaire mais non- documentée) est parfaietemnt viable sous Debian Bullseye

Bon courage :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday 26 December 2021 20:49:51 didier.gaumet@gmail.com wrote:

Sur ma Debian Bullseye,
je viens d'installer une machine virtuelle Debian Bullseye minimale
(juste "utilitaires du système" dans Tasksel à la fin de
l'installation, donc pas d'environnement graphique, dans ce cas le
réseau de la machine cible est configuré par l'installateur dans /etc/network/interfaces)
ensuite j'ai installé Trinity suivant les instructions de Trinity: wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions
j'ai juste rajouté l'environnement français (dans les paquets, tâches environnement français et bureau français) et le paquet kde-i18n-fr- trinity (nom approximatif, je ne me souviens pas bien)
Résultat: pas de messages d'erreurs DCOP* ou ICE*, pas de pb de démarrage/arrêt lents.
La seule anomalie que j'ai remarquée est que en laissant la config
réseau dans /etc/network/interfaces j'avais accès à internet alors que quand j'ai commenté l'interface dans /etc/network/interfaces,
impossible, même en mode super-utilisateur, de configurer le réseau à partir des outils de configuration Trinity: l'interface était invisible alors qu'elle était parfaitement visible depuis un terminal
(l'interface virtuelle de virt-manager/Qemu vue comme une interface
ethernet)
Donc à mon avis, Trinity, à part cette anomalie réseau (mais c'est peut-être moi qui n'ai pas suivi une procédure nécessaire mais non- documentée) est parfaietemnt viable sous Debian Bullseye
Bon courage :-)

Merci, j'en ai besoin.
Bonne idée d'avoir fait une MV Debian Bullseye.
Ce n'est pas très viable si les outils graphiques Trinity sont inopérants. Comment expliquer que tu n'as pas les messages DCOP, ICE,
et moi oui. Pourtant j'ai installé Bullseye 64 bits + buro Trinity,
à neuf, sur une partition effacée et reformatée sans mauvaises manip.

J'ai encore des soucis :
- Carte Nvidia Geforce 218, module pas ou mal installé,
résolution trop faible (1024x768) impossible de la monter à 1024x1024.
Avant ça marchait avec le pilote proprio Nvidia.
Si je tente de le lancer, refus car le système dit que je dois désinstaller un module nvidia, ce que je fais, et le message revient.

- Au boot, j'ai ce message : "Failed to start kernel module" (Quid ?).

Pour moi, le passage à Bullseye est pas fini et problèmatique...
Help !

A. Valmer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le lundi 27 décembre 2021 à 19:24 +0100, ajh-valmer a écrit :

[...]

Ce n'est pas très viable si les outils graphiques Trinity sont
inopérants.

ça fait tellement longtemps que j'ai utilisé KDE3 que j'ai un peu
oublié comment ça marchait. Donc j'ai cherché à créer paramétrer une interface ethernet sans trouver mais je n'ai peut-être pas regardé au
bon endroit, ou Trinity a changé la façon de faire. J'ai pas creusé, je voulais faire rapide. 

En tout cas ça a fini par faire remonter des souvernirs: KDE3 avait son
propre gestionnaire de connexion wifi (Kwifimanager ou un nom de ce
genre). Du coup il ne faut pas installer un gestionnaire de connexion
(wicd, network-manager, connman...) sauf à vouloir des problèmes. Et ne
*pas* paraméter le wifi dans le fichier interfaces

Comment expliquer que tu n'as pas les messages DCOP, ICE,
et moi oui. Pourtant j'ai installé Bullseye 64 bits + buro Trinity,
à neuf, sur une partition effacée et reformatée sans mauvaises manip.

Mais tu as gardé ta partition /home, je suppose. ça pourrait venir de
là: comme précisé dans un lien Trinity que je t'ai indiqué auparavant,
il peut y avoir du ménage à faire mais il faut le faire depuis une
console (un terminal ne suffit pas). Ou alors créer un utilisateur
secondaire pour te connecter et faire le ménage dans le compte
utilisateur principal.
(parce que si tu essaies de supprimer des fichiers temporaires créés
lors d'une session Trinity ça risque de ne pas être efficace, il faut
le faire hors session Trinity si tu utilises un seul compte
utilisateur)

J'ai encore des soucis :
- Carte Nvidia Geforce 218, module pas ou mal installé,
résolution trop faible (1024x768) impossible de la monter à
1024x1024.
Avant ça marchait avec le pilote proprio Nvidia.
Si je tente de le lancer, refus car le système dit que je dois
désinstaller
un module nvidia, ce que je fais, et le message revient.

- Au boot, j'ai ce message : "Failed to start kernel module" (Quid
?).

Pour moi, le passage à Bullseye est pas fini et problèmatique...
Help !

A. Valmer

Il te faut commencer par savoir si tu veux un pilote proprio ou libre: 

perso sauf besoin particulier, je pense que je prendrais le libre vu
qu'il est installé par défaut (pilote "nouveau").
Pour désinstaller le pilote proprio "nvidia", la procédure est indiquée
là:
https://wiki.debian.org/fr/NvidiaGraphicsDrivers#D.2BAOk-sinstallation

Si au contraire tu veux utiliser le pilote proprio nvidia, la procédure
est là: https://wiki.debian.org/fr/NvidiaGraphicsDrivers

Décharger un module par modprobe -r ou rmmod n'est effectif qu'en cours
de session: au prochain redémarrage c'est perdu. Si tu veux empêcher un module noyau (ici pilote proprio ("nvidia") ou libre ("nouveau") pour
ta carte graphique), il faut le mettre en liste noire comme suit:
soit un module toto, créer un fichier /etc/modprobe.d/toto-
blacklist.conf qui contient une ligne unique:
blacklist toto

Je suppose que tu disposes d'un écran plat LCD relié par un câble HDMI
ou DVI, pas d'un écran LCD relié par un câble VGA, ni d'un vieil écran cathodique (CRT)?
Si tu as un LCD raccordé en VGA, passe en câble HDMI ou DVI, tu
t'éviteras des emmerdes (double conversion numérique-analogique et analogique-numérique inutile et qui fait perdre au PC des informations
sur l'écran, et augmente la distortion)

Pour un écran plat LCD, il faut utiliser sa résolution native, pas
comme un viel écran CRT.



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)