Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 16-04-2020 19:59:43

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

bug sur testing apu amd R3 2200G

Bonsoir
le message


su -
Mot de passe :
 



journalctl -r -p err
 


retour


-- Logs begin at Mon 2020-02-17 10:43:16 CET, end at Thu 2020-04-16 20:48:34 CEST. --
avril 16 20:22:03 raven2200g kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
avril 16 20:22:03 raven2200g kernel: amdgpu 0000:08:00.0: firmware: failed to load amdgpu/raven_ta.bin (-2)
avril 16 20:22:03 raven2200g kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
avril 16 20:22:03 raven2200g kernel: pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
-- Reboot --
avril 14 20:46:37 raven2200g kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
avril 14 20:46:37 raven2200g kernel: pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
 


il y a le retour du 16/04  et  du 14/04
il y a eu une mise a jour du noyau pour le 16/04 en autre
sinon rien de particulier le bureau fonctionne

le noyau réclame le "raven_ta.bin"

Dernière modification par robert2a (16-04-2020 20:00:16)

Hors ligne

#2 16-04-2020 20:53:57

Anonyme-11
Invité

Re : bug sur testing apu amd R3 2200G

Salut, smile
je possède le même processeur, mais il tourne avec un système windaub dessus pour le moment (jeu).
Quand j'aurais refais un dual boot avec Debian je te dirais si j'ai le problème.

#3 17-04-2020 11:54:42

èfpé
Membre
Inscription : 10-07-2016

Re : bug sur testing apu amd R3 2200G

Bonjour,

robert2a a écrit :

kernel: amdgpu 0000:08:00.0: firmware: failed to load amdgpu/raven_ta.bin (-2)


D'après Alex Deucher ce firmware (linux-firmware.git le 7 janvier) est optionnel (requis pour HDCP) :

Alex Deucher a écrit :

The ta firmware is optional (only required for HDCP functionality) and
is currently in QA.  It will be released any day now (probably after
the holidays) as well.


QA = quality assurance ; le paquet firmware-amd-graphics est basé sur le snapshot du 20190717...

Dernière modification par èfpé (18-04-2020 10:54:42)

Hors ligne

#4 18-04-2020 03:58:31

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

Bonjour
je touche a rien , on verra si dans le futur le message disparaît .

pour HDCP je suis pas intéressé  roll

ps: debian peu le désactiver dans le noyau qu'il fourni , c'est pas du libre ça  smile

Hors ligne

#5 24-04-2020 05:07:56

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

Bonjour
suite a mise a jour et nouveau noyau rien n'a changé
sur la mise a jour des paquets


update-initramfs: Generating /boot/initrd.img-5.5.0-2-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
 


et les erreurs


-- Logs begin at Mon 2020-02-17 10:43:16 CET, end at Fri 2020-04-24 05:43:25 CEST. --
avril 24 05:42:36 raven2200g kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
avril 24 05:42:36 raven2200g kernel: amdgpu 0000:08:00.0: firmware: failed to load amdgpu/raven_ta.bin (-2)
 



le paquet "rtkit" a été signalé comme contenant un bug , je ne l'ai pas mit a jour .
noyau actuel


Linux raven2200g 5.5.0-2-amd64 #1 SMP Debian 5.5.17-1 (2020-04-15) x86_64 GNU/Linux
 



sinon rien de spécial dans le fonctionnement de la machine

Hors ligne

#6 05-08-2020 04:07:30

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

Bonjour
problème résolu avec mise a jour du firmware , pour ceci "firmware: failed to load amdgpu/raven_ta.bin (-2)"
pour ceci "W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169" pas fait attention , mais il me semble qu'il ne s' affiche plus au démarrage.


par contre cette commande sous testing , me fait un souci dans la mesure ou elle garde chaque commande même après un reboot


journalctl -r -p err
-- Logs begin at Wed 2020-08-05 04:41:12 CEST, end at Wed 2020-08-05 04:50:52 CEST. --
août 05 04:41:12 debian30 kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
 


sur buster elle n'affiche qu'une ligne comme ci dessus
sur testing elle cumule toutes les commandes précédentes (avec la date et l'heure) et entre chaque retour de commande "reboot"
normalement ça ne doit afficher que les erreurs depuis le dernier démarrage
si quelqu'un a remarquer ceci aussi et peut être une solution .
ps: sous buster "journalctl" écrit en mémoire vive , et sous testing sur le disque par exemple , ce qui explique ceci

=>  https://manpages.debian.org/testing/sys … .1.en.html

a priori l'option "-r" écrit les plus récentes en premier , l'option "-p err" n' affiche que les erreurs
c'est sous la forme d un journal , mais écrit je sais pas ou  roll

=> https://manpages.debian.org/testing/sys … .8.en.html

je vais regarder ceci :


Le service de journal stocke les données de journal de manière persistante sous / var / log / journal
ou de manière volatile sous / run / log / journal / (dans ce dernier cas, elles sont perdues au redémarrage).
Par défaut, les données du journal sont stockées de manière persistante si / var / log / journal / existe pendant le démarrage,
avec un retour implicite vers le stockage volatile dans le cas contraire.
Utilisez Storage = dans journald.conf (5) pour configurer l'emplacement des données de journal,
indépendamment de l'existence de / var / log / journal /.
 



sous buster /var/log/journal  n'existe pas (stockage persistant , a vérifier sous testing)
sous buster /run/log/journal existe ( stockage volatile)

je pense que j'ai trouver le pourquoi  smile

j'ai effacé /var/log/journal sous testing , le problème est résolu mais il me reste ceci


journalctl -r -p err
-- Logs begin at Wed 2020-08-05 05:47:25 CEST, end at Wed 2020-08-05 05:48:25 CEST. --
août 05 05:47:34 raven2200g systemd[1060]: Excess arguments.
août 05 05:47:25 raven2200g kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
août 05 05:47:25 raven2200g kernel: pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
 



ceci => août 05 05:47:34 raven2200g systemd[1060]: Excess arguments
trop d' argument dans quoi ?  tongue

Dernière modification par robert2a (05-08-2020 05:16:31)

Hors ligne

#7 05-08-2020 16:44:58

--gilles--
Membre
Lieu : Orléans - La Source
Distrib. : debian 11
Noyau : Linux 5.8.0-2-amd64
(G)UI : mutter 3.38.0-2
Inscription : 15-02-2016

Re : bug sur testing apu amd R3 2200G

robert2a a écrit :

Bonjour[...]


a priori l'option "-r" écrit les plus récentes en premier , l'option "-p err" n' affiche que les erreurs
c'est sous la forme d' un journal , mais écrit je sais pas où


Le service de journal stocke les données de journal de manière persistante sous / var / log / journal
ou de manière volatile sous / run / log / journal / (dans ce dernier cas, elles sont perdues au redémarrage).
Par défaut, les données du journal sont stockées de manière persistante si / var / log / journal / existe pendant le démarrage,
avec un retour implicite vers le stockage volatile dans le cas contraire.
Utilisez Storage = dans journald.conf (5) pour configurer l'emplacement des données de journal,
indépendamment de l'existence de / var / log / journal /.
 



sous buster /var/log/journal  n'existe pas (stockage persistant , à vérifier sous testing)
sous buster /run/log/journal existe ( stockage volatile)

je pense que j'ai trouver le pourquoi  smile

j'ai effacé /var/log/journal sous testing , le problème est résolu.



Bonjour, tu as ces commandes de journalctl :

Pour savoir l'emplacement des fichiers journaux et vérifier si les fichiers journaux ne sont pas détériorés :

journalctl --verify




Pour voir la place que prennent les fichiers journaux :

journalctl --disk-usage



Pour ne garder que les fichiers journaux des 3 derniers jours : ( Pas la peine d'effacer )

journalctl --vacuum-time=3d


La liberté est liée à la qualité du langage, et les bureaucrates qui veulent détruire la liberté ont tous tendance à mal écrire et à mal parler, à se servir d’expressions pompeuses ou confuses, à user de clichés qui occultent ou oblitèrent le sens. Georges Orwell

Hors ligne

#8 08-08-2020 00:25:48

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

Bonsoir
je ne veut pas archiver le journal "systemctl" (volatil)
les commandes que tu propose sur ma machine


journalctl --verify
 



PASS: /run/log/journal/69f7d959d71c487987d5993ec420c0da/system.journal                                                                            
PASS: /run/log/journal/69f7d959d71c487987d5993ec420c0da/system@4779835857634bc48915af1ab618c86f-0000000000000001-0005ac516a877552.journal          
 



journalctl --disk-usage
 



Archived and active journals take up 16.0M in the file system.
 



journalctl --vacuum-time=3d
 



Vacuuming done, freed 0B of archived journals from /run/log/journal/69f7d959d71c487987d5993ec420c0da.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
 



journalctl --disk-usage
 



Archived and active journals take up 16.0M in the file system.
 



journalctl -r -p err
 



-- Logs begin at Sat 2020-08-08 00:49:23 CEST, end at Sat 2020-08-08 01:17:01 CEST. --
août 08 00:49:30 raven2200g systemd[1108]: Excess arguments.
août 08 00:49:23 raven2200g kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
août 08 00:49:23 raven2200g kernel: pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
 



c'est ceci que je voudrais résoudre


août 08 00:49:30 raven2200g systemd[1108]: Excess arguments.
 


ps:c'est suite a une mise a jours (testing)

mais merci toujours bon a savoir  smile

Dernière modification par robert2a (08-08-2020 00:29:36)

Hors ligne

#9 08-08-2020 01:06:31

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

re,
un autre problème résolu , mais un autre survient  tongue   (les joies de testing roll  )


journalctl -r -p err
 



-- Logs begin at Sat 2020-08-08 01:51:44 CEST, end at Sat 2020-08-08 01:53:13 CEST. --
août 08 01:51:44 raven2200g kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
août 08 01:51:44 raven2200g systemd[1]: /lib/systemd/system/blk-availability.service:10: Neither a valid executable name nor an absolute path: ${exec_prefix}/bin/true
août 08 01:51:44 raven2200g kernel: pci 0000:00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
 



systemctl status blk-availability.service
 



● blk-availability.service - Availability of block devices
     Loaded: bad-setting (Reason: Unit blk-availability.service has a bad unit file setting.)
     Active: inactive (dead)

août 08 01:51:45 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:51:45 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:51:45 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:51:53 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:51:53 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:52:42 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:52:42 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:52:42 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:52:43 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
août 08 01:52:43 raven2200g systemd[1]: blk-availability.service: Cannot add dependency job, ignoring: Unit blk-availability.service has a bad unit file setting.
 



le fichier de systemd


[Unit]
Description=Availability of block devices
Before=shutdown.target
After=lvm2-activation.service iscsi-shutdown.service iscsi.service iscsid.service fcoe.service rbdmap.service
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=oneshot
ExecStart=${exec_prefix}/bin/true
ExecStop=/sbin/blkdeactivate -u -l wholevg -m disablequeueing -r wait
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target
 



je sais pas si je peu virer le paquet "LVM2"  sans danger
je n'ai jamais utilisé , a priori une nouveauté de bullseye

nota: lvm (lvm2) est installé sur le système , fichier de conf dans /etc/lvm/
que ce soit le noyau qui demande la dépendance  hmm

pour l'instant j'ai désactivé


systemctl disable blk-availability.service

Removed /etc/systemd/system/sysinit.target.wants/blk-availability.service.
 



nota:
j'ai viré les paquets "lvm2" , la librairie "libblkid1" ne peut être enlevé , le service n'existe plus "blk-availability.service"
je n'ai plus d'erreur
je sais pas ce qui est prévu dans le futur  hmm

Dernière modification par robert2a (08-08-2020 02:00:03)

Hors ligne

#10 08-08-2020 06:49:41

--gilles--
Membre
Lieu : Orléans - La Source
Distrib. : debian 11
Noyau : Linux 5.8.0-2-amd64
(G)UI : mutter 3.38.0-2
Inscription : 15-02-2016

Re : bug sur testing apu amd R3 2200G

Bonjour robert2a.

lvm2, c'est pour utiliser les volumes logiques à la place des partitions classiques, c'est ce que j'utilise, pratique pour agrandir ou rétrécir en cas d'urgence. Mais je ne suis pas un expert de ces manipulations. lvm2 n'est pas nouveau, mais peut-être que nous serons incités fortement à utiliser cette solution dans l'avenir, une intuition vu que tu écris que les développeurs mettent ce paquet d'office dans bullseye.

Le bug est du à ce que /bin/true doit être remplacé partout dans les scripts par /bin/false et la ré-écriture des conditions associées, j'ai lu ceci dans les messages apt-list bug ou apt-list-change avant la mise à jour d'un paquet. Et comme cette expression est encore présente dans le script /lib/systemd/system/blk-availability.service journalctl râle. Mais apparemment encore aucune conséquence visible de cette erreur à part sa dénonciation dans journalctl.

Bonne journée

La liberté est liée à la qualité du langage, et les bureaucrates qui veulent détruire la liberté ont tous tendance à mal écrire et à mal parler, à se servir d’expressions pompeuses ou confuses, à user de clichés qui occultent ou oblitèrent le sens. Georges Orwell

Hors ligne

#11 08-08-2020 14:59:15

robert2a
Membre
Distrib. : debian 11
(G)UI : Mate
Inscription : 15-11-2014

Re : bug sur testing apu amd R3 2200G

Bonjour
tous les gens qui n'utilise pas lvm et sont en testing ou sid peuvent confirmer si présent ou pas sur leur système.
moi jamais utilisé , je me débrouille autrement .

pour les dossier oui c'est la pagaille , je vois passer moi aussi des avertissements comme quoi le dossier doit être modifier , normalement c'est au responsable du paquet a le faire .
je fais la chasse aux erreurs pour éviter de remplir les logs inutilement sinon oui pas bien grave.

et pour lvm , il est dans l' installateur debian depuis longtemps , au choix de l'utilisateur au moment de l'installation . (il me semble bien )

sinon globalement ça se passe bien bullseye , ça tourne bien  smile

Hors ligne

Pied de page des forums