Migration buster (debian 10.11) vers bullseye (11.2) = bullshit

Tags: #<Tag:0x00007fb995716780>

Bonjour,

Environnement LXDE debian 10.11 (buster)
Hier j’ai fait la migration vers debian 11.2 (bullseye), en suivant un tuto chez Debian.org (lien trouvé ici, merci, :slightly_smiling_face:) et ma foi, tout s’est bien passé, sauf après le reboot où j’ai pu constater que des paramètres que j’avais mis un certain temps à tuner/twicker pour avoir un debian 10 (buster) aux petits oignons ont… sauté, hé ouais !

Va falloir reparamétrer/reconfigurer, avec les outils antédiluviens toujours fournis avec la distro et auxquels on ne comprend rien, enfin, moi, puisqu’il n’y a ni infobulle ni clic-droit disponibles. Quelqu’un a déjà réussi à configurer sa machine avec « Préférences / Applications par défaut pour LXSession » ? Chez moi, pratiquement tout est décoché et pourtant ça fonctionne, genre le navigateur web, le gestionnaire de fichiers, le gestionnaire de capture d’écran, etc., ces zones sont vides mais les outils sont là et opérationnels,

Et donc, dans les « Préférences / Paramètres de la session de bureau », quelque part dans la liste :
« Mise à jour des dossiers utilisateur »
et presque tout en bas :
« user folders update »
Ça ne serait pas la même chose ? Comment savoir ? Que faire ?
Allez, je les vire, comme conseillé ici et puisque je ne sais pas à quoi ça sert.

Dans la même liste, « PulseAudio System Tray » n’est pas coché mais l’icône est présente et fonctionnelle en bas à droite à côté de l’heure, peut-être parce que « Système de son PulseAudio » (tout en haut de la liste) est coché ?
Ce qui est navrant c’est que maintenant l’icône indique systématiquement « muet » alors qu’avant ça fonctionnait normalement (c-à-d sur 3 pattes, venant de PulseAudio).
C’est pénible car je comptais sur ça pour jouer un petit son « à la Windows » m’indiquant que tout allait bien à la fin du démarrage et maintenant c’est fichu…

Encore dans cette liste, le « Verrouilleur d’écran » (ScreenLock) n’est pas coché mais est cependant présent en bas à droite, donc cette liste et ses actions ce n’est plus fiable, on est loin, très loin des Debian de mes débuts (une vingtaine d’années).
Et pour accéder à sa fenêtre pour arrêter/verrouiller/changer d’utilisateur/etc., il faut compter 50 secondes après le clic sur l’icône !
50 secondes avant son affichage, oui, vous avez bien lu…

Et je ne sais pas comment me dépatouiller de ces problèmes car cette d11, je l’ai testée avant avec une clé live et la fenêtre de logout s’y est affichée instantanément.

Autre chose : j’ai une ancienne machine qui me propose, dans la fenêtre de login, un bouton Default Xsession qui a disparu de la nouvelle, aussi bien en debian 10 (buster) qu’en debian 11 (bullseye) maintenant, donc impossible de savoir quel est l’environnement de bureau.

Alors si vous avec des idées, c’est le moment, parce que moi, en regardant cette machine toute neuve et son écran, je suis comme une poule qui aurait trouvé un couteau, je ne sais plus quoi faire.
Merci,

Salut, peux-tu reformater ton message stp? Il faut beaucoup scroller à droite et gauche, c’est illisible (ça veut dire que peu de gens s’y intéresseront :wink: )

Ben aurais-tu une bouse comme pc?

Je ne pense pas que ce soit la source du problème, mais ça dépend de ce que tu as fait pour, euh, personnaliser ton système sur la version 10.
Par exemple, que donne le retour de la commande suivante :

grep -v "^#" /etc/apt/sources.list{,.d/*}

Bonjour à tous,
@Almtech
copier/coller de la sortie de ta commande :

/etc/apt/sources.list:deb http://deb.debian.org/debian bullseye main contrib non-free
/etc/apt/sources.list:deb-src http://deb.debian.org/debian bullseye main contrib non-free
/etc/apt/sources.list:
/etc/apt/sources.list:deb http://deb.debian.org/debian bullseye-updates main contrib non-free
/etc/apt/sources.list:deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free
/etc/apt/sources.list:
/etc/apt/sources.list:deb http://security.debian.org/debian-security bullseye-security main contrib non-free
/etc/apt/sources.list:deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free
/etc/apt/sources.list:
/etc/apt/sources.list:
/etc/apt/sources.list:deb [arch=amd64] https://download.virtualbox.org/virtualbox/debian/ bullseye contrib
grep: /etc/apt/sources.list.d/*: Aucun fichier ou dossier de ce type

EDIT

On est d’accord. C’était juste pour préciser qu’après de longues séances de prises de tête afin d’avoir une babasse à mon goût, voilà-t-y pas qu’une mise à jour vient casser mon taf, grrrr !
/EDIT

Oh, rien de bien tordu, juste virer le démarrage des choses qui me sont inutiles (gestionnaire de presse-papiers, accessibilité, etc.) et bricoler une configuration pointue pour (cette cochonnerie de) systemd qui se permettait d’identifier mes disques à la one again, en fonction de critères qui lui sont propres, résultat des fois le dossier « data » était monté sur le petit disque ssd système et l’arborescence système était montée sur un gros hdd classique – jamais compris comment il pouvait s’y retrouver et comment ça pouvait booter comme ça, bref j’ai figé tout ça par la construction d’un nouveau noyau basé sur le kernel 5.7.10 où les pilotes disque sont chargés statiquement et les disques montés par des scripts rigoureux.
Depuis c’est bon.

Bah nan, d’autant plus que ce problème n’existait pas en 10.x et pas plus avec une clé live 11.2.
Dans l’ensemble, tout se lancerait bien, jusqu’à preuve du contraire, il n’y a que cette fenêtre de « Logout » qui prend son temps.

Oui, je m’en suis bien rendu compte, et je n’ai pas la moindre idée de comment reformater le texte, je n’ai rien trouvé dans les options d’édition.
EDIT : mais je suis en train de réaliser que cette réponse se met correctement en forme (visible à droite, chose que je n’avais pas lors de la première rédaction) donc probablement qu’il me suffirait d’éditer mon post. Je teste et je reviens vous dire.
EDIT2 : il semblerait que sans avoir rien fait, mon post soit maintenant correct. Ah, les mystères de l’informatique…

systemD ne fait rien de bizarre par rapport à ça, il s’appuie sur ce qui est indiqué dans le fichier /etc/fstab (ou éventuellement une configuration interne, mais il n’y en a pas par défaut).
Identifie toujours tes partition à l’aide de leur identifiant unique ou d’une étiquette que tu peux leur attribuer. Tu peux retrouver ces informations dans le retour de la commande blkid.

Bonsoir,

C’est par là que j’avais commencé, suivant les précieux conseils de raleur et deux ou trois autres gars sympa jusqu’à ce que je me fasse bannir (pour encore 6 mois) chez DF et crois-le si tu veux ou pas mais j’ai tout essayé et ça n’a jamais été fiable à 100%.
(il y a une discussion là-bas de 4 pages environ, où je parle du changement de nom des disques, qui m’a bien fait me prendre la tête).

Bon, cet aprème j’ai essayé de comprendre un peu ce délai de malade au shutdown et donc après examen des journaux, pour moi il y a bien un souci dans d11 :
L’idée d’examiner le journal vient de Ubuntu Linux Taking Too Long to Shutdown? Here's How to Fix!
Je n’ai mis que ce qui concerne le ralentissement de l’arrêt et ça se lit à l’envers, le plus récent en haut donc juste ci-dessous :

janv. 09 16:34:10 debox64 systemd-logind[769]: System is powering down.
  un trou de 8 secondes 
janv. 09 16:34:02 debox64 dbus-daemon[761]: [system] Failed to activate service 'org.freedesktop.UPower': timed out (service_start_timeout=25000ms)
  un trou de 24 secondes
janv. 09 16:33:38 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:38 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:38 debox64 systemd[1]: upower.service: Start request repeated too quickly.
janv. 09 16:33:38 debox64 systemd[1]: Stopped Daemon for power management.
janv. 09 16:33:38 debox64 systemd[1]: upower.service: Scheduled restart job, restart counter is at 5.
janv. 09 16:33:38 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:38 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:38 debox64 systemd[1]: upower.service: Main process exited, code=exited, status=217/USER
janv. 09 16:33:38 debox64 systemd[7180]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: Invalid argument
janv. 09 16:33:38 debox64 systemd[7180]: upower.service: Failed to set up user namespacing: Invalid argument
janv. 09 16:33:38 debox64 systemd[1]: Starting Daemon for power management...
  supprimé les entrées 2 à 4
janv. 09 16:33:37 debox64 systemd[1]: Stopped Daemon for power management.
janv. 09 16:33:37 debox64 systemd[1]: upower.service: Scheduled restart job, restart counter is at 1.
janv. 09 16:33:37 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:37 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:37 debox64 systemd[1]: upower.service: Main process exited, code=exited, status=217/USER
janv. 09 16:33:37 debox64 systemd[7162]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: Invalid argument
janv. 09 16:33:37 debox64 systemd[7162]: upower.service: Failed to set up user namespacing: Invalid argument
janv. 09 16:33:37 debox64 systemd[1]: Starting Daemon for power management...
janv. 09 16:33:37 debox64 dbus-daemon[761]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' requested by ':1.59' (uid=0 pid=7085 comm="lxsession-logout --banner /usr/share/lxde/images/l")
et il recommence une séance de 5
janv. 09 16:33:37 debox64 dbus-daemon[761]: [system] Failed to activate service 'org.freedesktop.UPower': timed out (service_start_timeout=25000ms)
  un trou de 24 secondes
janv. 09 16:33:13 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:13 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:13 debox64 systemd[1]: upower.service: Start request repeated too quickly.
janv. 09 16:33:13 debox64 systemd[1]: Stopped Daemon for power management.
janv. 09 16:33:13 debox64 systemd[1]: upower.service: Scheduled restart job, restart counter is at 5.
janv. 09 16:33:13 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:13 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:13 debox64 systemd[1]: upower.service: Main process exited, code=exited, status=217/USER
janv. 09 16:33:13 debox64 systemd[7108]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: Invalid argument
janv. 09 16:33:13 debox64 systemd[7108]: upower.service: Failed to set up user namespacing: Invalid argument
janv. 09 16:33:13 debox64 systemd[1]: Starting Daemon for power management...
  supprimé les entrées 2 à 4
janv. 09 16:33:12 debox64 systemd[1]: Stopped Daemon for power management.
janv. 09 16:33:12 debox64 systemd[1]: upower.service: Scheduled restart job, restart counter is at 1.
janv. 09 16:33:12 debox64 systemd[1]: Failed to start Daemon for power management.
janv. 09 16:33:12 debox64 systemd[1]: upower.service: Failed with result 'exit-code'.
janv. 09 16:33:12 debox64 systemd[1]: upower.service: Main process exited, code=exited, status=217/USER
janv. 09 16:33:12 debox64 systemd[7089]: upower.service: Failed at step USER spawning /usr/libexec/upowerd: Invalid argument
janv. 09 16:33:12 debox64 systemd[7089]: upower.service: Failed to set up user namespacing: Invalid argument
janv. 09 16:33:12 debox64 systemd[1]: Starting Daemon for power management...
janv. 09 16:33:12 debox64 dbus-daemon[761]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service' requested by ':1.59' (uid=0 pid=7085 comm="lxsession-logout --banner /usr/share/lxde/images/l")

(j’ai taggué tout le journal avec ‹ texte préformaté › mais l’éditeur ne se sent pas concerné, :thinking:, MicP au secours !)
Donc 8 + 24 + 24 = 56 secondes, j’étais un peu mais pas trop loin du compte mais surtout, ça ne correspond pas à la valeur notée dans /etc/systemd/system.conf qui est de 90 sec pour DefaultTimeoutStopSec.
Ce qui est vraiment navrant, c’est de trouver dans les erreurs de ce bout de journal des lignes genre « Failed to set up user namespacing: Invalid argument » ou « Failed at step USER spawning /usr/libexec/upowerd: Invalid argument » ou même « Failed with result 'exit-code' » qui montre que certains bouts de code ne sont pas finis, les deux précédents étant un mystère pour moi.
J’en suis là et je ne vois pas ce qu’il me faudrait faire pour surmonter cet écueil, à part arrêter la machine en L2C, qui fait qu’elle s’arrête quasi instantanément (et sans problèmes), ssd oblige.
EDIT : j’ai oublié la commande pour sortir cette liste :
journalctl -rb -1
avec -r pour reverse, le + récent tout en haut, et -b -1 pour n’avoir que les logs du dernier boot. /EDIT

Je le fais aussi. Pour savoir comme faire pour que ça fonctionne, n’hésite pas à regarder les modification effectuées par l’équipe de modération. Tu peux regarder ce qui a été modifié en cliquant sur le crayon dans la partie supérieure du message et afficher la différence en brut ou cliquer sur le crayon qui se trouve en bas pour voir le code que j’ai mis à la place et faire pareil la prochaine fois.
Des fois, l’éditeur ne fonctionne pas correctement pour la mise en forme préformatée.

Ça veut dire quoi ça ? Je ne connais pas.

Ligne 2 Commande,
:rofl:

Désolé, j’ai été retenu.

Un autre petit truc pour que la personne concernée puisse s’apercevoir
au moment de la connexion, que quelqu’un l’a citée et dans quel message,
il suffit de faire précéder son nom par un caractère arobase
comme ça : @jipete

on dit CLI pour la ligne de commande.

Bonjour,

dans le titre j’ai parlé de bullshit, malheureusement je suis très près de la vérité, hélas, et je peux en fournir la preuve.

D’abord, en regardant le lien ci-dessous (le 1er, pas l’encadré), on constate que des gens depuis quelques mois s’interrogent sur le fait qu’un bug est toujours présent, et moi aussi puisque mes recherches (/lib/systemd/system/plymouth-start.service:16: Unit configured to use KillMode=none) datent de ce matin :
https://linux.debian.bugs.dist.narkive.com/Z8tFPZdv/bug-967047-plymouth-start-service-unit-configured-to-use-killmode-none
puis

Ensuite en découvrant des messages d’erreur (file not found en général) dans les logs au boot de ma machine et de fil en aiguille,

janv. 10 10:36:37 debox64 systemd-xdg-autostart-generator[1429]: 
  Exec binary 'wicd-gtk' does not exist: No such file or directory

cat ~/.config/autostart/wicd-tray.desktop
[Desktop Entry]
Categories=Application;Network;
Exec=wicd-gtk --tray
GenericName=Network Manager
Icon=wicd-gtk
Icon[en_US]=wicd-gtk
Name=Wicd Network Manager Tray
Name[en_US]=Wicd Network Manager Tray
Comment=Display network connection status in the system tray
Comment[en_US]=Display network connection status in the system tray
Comment[he]=הצגת מצב חיבור רשת במגש מערכת
Terminal=false
Type=Application
Version=1.0
X-GNOME-Autostart-enabled=true
X-KDE-autostart-after=panel
NotShowIn=LXDE;

$ apt-show-versions wicd
wicd not installed (not available)
$ apt-show-versions wicd-gtk
wicd-gtk not installed (not available)

En résumé, des outils de la distro veulent des outils que la distro ne fournit plus. Elle est pas belle la vie ?

Allez, pour rire un peu, j’ai trouvé une ligne de log si on me l’avait dit je ne l’aurais pas cru, alors j’ai vite fait un copier/coller que je m’empresse de partager :
janv. 10 10:36:37 debox64 systemd[1416]: gpgconf: erreur d'exécution de « /usr/lib/gnupg/scdaemon » : il n'est sans doute pas installé
Le commentaire est en français dans le log du journal ! Incroyable ! ! !
Mais sinon c’est vrai, cet outil n’était pas installé, ce que j’ai corrigé, donc adieu le message.

Allez, j’y retourne, après cette petite récréation,

Yop !

Le hasard fait bien les choses, j’ai trouvé ça en fouinant pour mes pbs ce matin :
$ ps -e | grep tty7
1026 tty7 00:00:01 Xorg

Et sinon, bonne nouvelle !

J’ai été obligé de compiler un nouveau noyau, vu qu’il lui manquait une option (première piste pour débugger les problèmes de upower [janv. 09 16:33:13 debox64 systemd[7108]: upower.service: Failed to set up user namespacing: Invalid argumentcontainers - How to check if Linux user namespaces are supported by current OS kernel - Stack Overflow], la valeur concernée c’est General Setup / Namespaces Support / User namespace, que j’ai passée à True) et hop, compil (50 minutes…), reboot, test en cliquant sur l’icône « Déconnexion » en bas à droite, la fenêtre s’affiche instantanément ! Ça change la vie !

Maintenant, est-ce que ça a un rapport ? D’autant plus que j’ai désinstallé Pipewire (dont je n’ai rien à faire) mais qu’à l’opposé j’ai installé scdaemon (une erreur de moins dans les logs) et apt-show-versions que tout le monde utilise sur le web mais qui n’est pas installé par défaut.

Mais il y a de nouvelles erreurs, par exemple
janv. 10 17:17:23 debox64 pulseaudio[762]: W: [pulseaudio] authkey.c: Failed to open cookie file '/var/run/pulse/.config/pulse/cookie': Aucun fichier ou dossier de ce type
janv. 10 17:17:23 debox64 pulseaudio[762]: W: [pulseaudio] authkey.c: Failed to load authentication key '/var/run/pulse/.config/pulse/cookie': Aucun fichier ou dossier de ce type
janv. 10 17:17:23 debox64 pulseaudio[762]: W: [pulseaudio] authkey.c: Failed to open cookie file '/var/run/pulse/.pulse-cookie': Aucun fichier ou dossier de ce type
janv. 10 17:17:23 debox64 pulseaudio[762]: W: [pulseaudio] authkey.c: Failed to load authentication key '/var/run/pulse/.pulse-cookie': Aucun fichier ou dossier de ce type
ou
janv. 10 17:58:47 debox64 pulseaudio[1326]: After module unload, module 'module-null-sink' was still loaded!
ou
janv. 10 17:58:47 debox64 lightdm[1389]: gkr-pam: unable to locate daemon control file
janv. 10 17:58:47 debox64 lightdm[1389]: gkr-pam: stashed password to try later in open session
c’est quoi gkr-pam ? Première fois que je vois ça, et c’est inconnu de synaptic.

Il y en a d’autres, qui ont l’air mineures, mais à chaque jour suffit sa peine, et là j’en ai ma claque, alors bonne soirée !