Suggérer d'utiliser un système déprécié, sans donner d'indications précises, ça me semble être une mauvaise idée.
Surtout quand il y a une alternative entre la version historique et la version nft, et que pour effectivement passer de l'une à l'autre il faut redémarrer le système…
D'après le code en question, il y a tentative d'ioctl avec l'opération VIDIOC_REQBUFS qui échoue, ce qui se propage à start(). Puisque le cas mmap ne semble pas bien se passer, tu pourrais regarder les options V4L2 mentionnées dans le README du projet v4l2rtspserver (ou dans la sortie de -h), pour essayer d'utiliser une autre interface. Notamment -r qui permet de basculer le réglage par défaut V4l2IoType ioTypeIn = IOTYPE_MMAP; à ioTypeIn = IOTYPE_READWRITE;.
Je mets de côté l'éventuelle configuration pare-feu.
Ta machine a deux interfaces différentes avec le même réseau : 192.168.0.0/24.
Si un paquet arrive sur une des IP 192.168.0.29 ou 192.168.0.254, la réponse à destination de l'IP 192.168.0.X va être envoyée… via l'une ou l'autre des interfaces (voir la notion de métrique, visible dans la sortie d'ip route).
Le plus simple est d'utiliser deux réseaux différents. Et seule une des deux IP (celle côté réseau local — enp3s0 — et pas celle du réseau FAI — enp2s0) est à renseigner dans la configuration de tes postes (hors routeur).
Le premier réflexe quand des paquets n'arrivent pas au bon endroit, c'est utiliser tcpdump ou équivalent. Dans le cas présent, tu devrais voir arriver des paquets sur le routeur, les éventuelles réponses et leur destination.
or le packaging du noyau Debian dans la branche bookworm définit ces options de configuration :
debian/config/config:CONFIG_RTL8XXXU=m
debian/config/config:# CONFIG_RTL8XXXU_UNTESTED is not set
Donc non, l'information VID/PID pour ta carte n'est pas dans le module, et c'est normal que charger manuellement le module ne change rien.
C'est également le cas dans la branche master (v6.6-rc1-33-g3669558bdf354 actuellement).
Si tu veux contribuer aux tests, je t'invite à sortir les identifiants de ta carte du #ifdef et à compiler un noyau avec cette modification. Si ta carte fonctionne avec le module ainsi modifié, tu pourras envoyer un patch indiquant les tests effectués, pour une éventuelle activation par défaut (dès lors que CONFIG_RTL8XXXU est activée, quelle que soit l'état de CONFIG_RTL8XXXU_UNTESTED).
À partir de là, tu devrais avoir autant d'entrées dans /dev/mapper qu'il y a de partitions dans l'image. Tu peux ensuite utiliser mount pour récupérer la main sur les fichiers à l'intérieur de chacune.
Histoire de comparer ce qui est comparable, je regarderais du côté des images Debian live publiées pour 12.1.0 (même si ces dernières sont figées dans le temps, et sont plus « vieilles » que ton système, ça devrait permettre de vérifier si un problème matériel est apparu vs. un problème logiciel).
Si le système se charge correctement, j'en profiterais pour regarder ce qu'il y a dans le système de fichiers racine. Notamment /var/log/apt/*.log pour les mises à jour installées « dernièrement » mais non nécessairement appliquées. Dans ton cas, les paquets linux-image-* et assimilés peuvent avoir été mis à jour il y a plusieurs jours ou semaines, mais sans le redémarrage associé, il arrive de se rendre compte d'éventuelles régressions bien plus tard.
Ces derniers temps, les paquets *-microcode ont été mis à jour. Je n'ai pas le détail en tête (et c'est de toute façon souvent compliqué avec les constructeurs qui communiquent peu de détails techniques), mais ça pourrait valoir le coup de supprimer le paquet, rebuilder l'initramfs, et retenter un démarrage sans. Si le problème disparaît, retenter l'installation de la version précédente, vérifier que ça continue à fonctionner, puis ouvrir un rapport de bogue pour signaler la régression.
Quant aux erreurs ACPI, c'est malheureusement très courant, et ça peut ne pas être plus gênant que cela… À nouveau, en accédant à ton système de fichiers racines depuis un système live, tu dois pouvoir vérifier la présence ou non de ce message dans les logs noyau des démarrages passés.
J'ai été un temps chez AXA avec leur offre MRP, dont la base était un peu élevée (800+ euros en 2015)… parce qu'il y avait une promotion « startup » (je rentrais dans les cases pour des raisons qui m'échappent, étant une SASU avec une volonté claire d'être le seul et unique salarié) rendant le tarif abordable (environ la moitié). En quelques années, ça a pris 50 %, tandis que l'agence ne donnait pas satisfaction sur d'autres points. J'ai basculé chez Hiscox, qui semble bien connaître nos métiers, pour un tarif inférieur et des garanties supérieures.
Je n'ai eu besoin de faire jouer ni l'une ni l'autre à ce jour, donc je ne peux pas en dire beaucoup plus.
Sous réserve que ça soit disponible et activé sur les interfaces concernées (LAN et/ou WLAN), il suffit de lancer wakeonlan la:ma:ca:dd:re:ss et la machine revient. Je l'utilise sur des machines complètement éteintes plutôt qu'en sommeil, mais ça ne devrait pas faire de différence.
J'imagine que tu as installé depuis une image « Live ». Celles-ci installent tous les paquets de type firmware, problème qui sera corrigé dans les images 12.1 la semaine prochaine. Les images d'installation classiques (e.g. netinst) n'ont pas ce problème.
Il me semble que la suppression du paquet raspi-firmware n'est pas triviale (à cause d'autres problèmes…), je pense que tu peux supprimer les deux hooks pour éviter de rencontrer ces problèmes à chaque installation/mise à jour de noyau et paquets liés (e.g. initramfs-tools), avant de demander à dpkg de terminer la configuration des paquets concernés :
sudo rm /etc/initramfs/post-update.d/z50-raspi-firmware
sudo rm /etc/kernel/postinst.d/initramfs-tools
sudo dpkg --configure -a
Un cas ultra classique est udev, mais il est de toute façon nécessaire qu'il soit capable de tourner sur la version de noyau disponible dans la distribution précédente, pour être capable de faire la mise à niveau de oldstable à stable… (en revanche pas de garantie de pouvoir « sauter » une version). Je ne pense pas que ça soit délirant en attendant d'avoir un retour de l'équipe noyau sur ton rapport de bogue.
Si tu veux chasser le problème, je t'invite à t'appuyer sur snapshot.debian.org qui va te permettre de bisecter grossièrement sans aucune compilation (attention à ne pas remplir ton /boot). Normalement ça permet d'isoler la dernière version upstream qui fonctionne et la première qui ne fonctionne pas. C'est une information très intéressante pour la gestion du rapport de bogue, je t'invite à indiquer les résultats si tu arrives jusque-là.
À ce stade, si tu veux poursuivre : Quand tu as de la chance, c'est la même version upstream, et c'est juste une modification dans le packaging qui explique la différence. Autrement, j'ai tendance à prendre le tag v5.OK.0 et le tag v5.KO.0 pour vérifier, et ensuite lancer le bisect « linéaire » entre ces deux tags (ça évite de partir dans les branches stables linux-5.OK.y et linux-5.KO.y – mais ça peut être nécessaire si les tests faits sur les tags en question ne donnent pas le même résultat que le bisect sur les binaires). Bien évidemment, vu le modèle de développement de Linux, le bisect « linéaire » implique tout de même de voir des versions bien plus vieilles, puisque master est principalement une succession de merges depuis des branches qui ont été préparées sur des versions inférieures.
OK, désolé pour ce point. N'ayant pas croisé ce genre d'unités dans la nature, j'ai regardé si je pouvais trouver un exemple et monter un PoC localement, et je n'ai pas vérifié sa page de manuel étant donné le comportement que tu décrivais et qui semblait s'expliquer par cette absence (perçue).
L'unité service étant activée pour multi-user.target, elle est bien sûr lancée automatiquement au démarrage. N'étant pas reliée à l'unité path, elle n'est bien sûr pas lancée quand l'unité path est activée.
Ceci semble faire le job — mais je ne vais pas m'amuser à redémarrer mon laptop pour vérifier le comportement au démarrage.
Je commence à ne plus avoir trop d'idées. Tu pourrais essayer d'installer un linux-image depuis unstable, des fois que ça soit une régression dans les noyaux 6.1.y…
Je pense qu'il faut absolument lire la doc sur les types de service. Déclarer un Type=simple implique qu'on s'attend à avoir un démon qui tourne. Or ici une commande est exécutée, bash termine, ce que systemd corrige en redémarrant après un délai de 10 secondes, obéissant aux directives Restart*.
J'imagine que se débarrasser de ces directives, basculer sur Type=oneshot devrait faire ce que tu souhaites. À tout le moins, cela devrait être une meilleure base de travail.
Désolé si la dernière demande n'était pas claire, serait-il possible d'avoir le log complet du dernier boot KO, après avoir tenté le chargement manuel de tous les modules ?
Que se passe-t-il si tu charges à la main tous les modules drm. Oubliant toute subtilité, ceci devrait convenir :
for mod in $(find /lib/modules/$(uname -r)/kernel/drivers/gpu/drm -type f); do name=$(/usr/sbin/modinfo $mod|awk '/^name:/ {print $2}'); sudo modprobe $name; done
Idéalement, poster le paragraphe de l'entrée GRUB démarrée, voir /boot/grub/grub.cfg complet pendant qu'on y est. Et vérifier le contenu de l'initramfs pour le noyau cible (cf. lsinitramfs). Il doit y avoir plein de modules drm/* dedans, et ça doit être chargé automatiquement au démarrage. Vérifier enfin les éventuelles blagues sur les chargements de module via /etc/mod*.
Première étape, comprendre ce que fait initrd=/install/gtk/initrd.gz sur la ligne de commande du noyau, l'enlever, et réessayer avec un initramfs qui n'est pas celui d'une image d'installation.
[^] # Re: faire un routeur avec une box linux facile et rapide
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian sur mini serveur qui ne veut pas faire routeur. Évalué à 3.
Suggérer d'utiliser un système déprécié, sans donner d'indications précises, ça me semble être une mauvaise idée.
Surtout quand il y a une alternative entre la version historique et la version nft, et que pour effectivement passer de l'une à l'autre il faut redémarrer le système…
Debian Consultant @ DEBAMAX
# Erreur dans libv4l2cpp, version mmap
Posté par Cyril Brulebois (site web personnel) . En réponse au message v4l2rtspserver sur webcam arm - not a tty. Évalué à 2.
D'après le code en question, il y a tentative d'
ioctl
avec l'opérationVIDIOC_REQBUFS
qui échoue, ce qui se propage àstart()
. Puisque le casmmap
ne semble pas bien se passer, tu pourrais regarder les options V4L2 mentionnées dans le README du projetv4l2rtspserver
(ou dans la sortie de-h
), pour essayer d'utiliser une autre interface. Notamment-r
qui permet de basculer le réglage par défautV4l2IoType ioTypeIn = IOTYPE_MMAP;
àioTypeIn = IOTYPE_READWRITE;
.Debian Consultant @ DEBAMAX
# Cela ne peut pas fonctionner (correctement) en l'état
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian sur mini serveur qui ne veut pas faire routeur. Évalué à 10.
Je mets de côté l'éventuelle configuration pare-feu.
Ta machine a deux interfaces différentes avec le même réseau :
192.168.0.0/24
.Si un paquet arrive sur une des IP 192.168.0.29 ou 192.168.0.254, la réponse à destination de l'IP 192.168.0.X va être envoyée… via l'une ou l'autre des interfaces (voir la notion de métrique, visible dans la sortie d'
ip route
).Le plus simple est d'utiliser deux réseaux différents. Et seule une des deux IP (celle côté réseau local — enp3s0 — et pas celle du réseau FAI — enp2s0) est à renseigner dans la configuration de tes postes (hors routeur).
Le premier réflexe quand des paquets n'arrivent pas au bon endroit, c'est utiliser
tcpdump
ou équivalent. Dans le cas présent, tu devrais voir arriver des paquets sur le routeur, les éventuelles réponses et leur destination.Debian Consultant @ DEBAMAX
[^] # Re: Identifiants dans le pilote
Posté par Cyril Brulebois (site web personnel) . En réponse au message clé usb wifi (dongle wifi) supportée mais pas détecté par le pilote. Évalué à 7.
Je ne sais pas quelles vérifications tu as faites, mais je ne suis pas d'accord avec tes conclusions.
On voit bien 0109 et 0108 mais pas 0107.
Côté
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
(au moins dansstable/linux-6.1.y
), il y a bien cette entrée :mais elle est gardée par ceci :
or le packaging du noyau Debian dans la branche
bookworm
définit ces options de configuration :Donc non, l'information VID/PID pour ta carte n'est pas dans le module, et c'est normal que charger manuellement le module ne change rien.
C'est également le cas dans la branche
master
(v6.6-rc1-33-g3669558bdf354
actuellement).Si tu veux contribuer aux tests, je t'invite à sortir les identifiants de ta carte du
#ifdef
et à compiler un noyau avec cette modification. Si ta carte fonctionne avec le module ainsi modifié, tu pourras envoyer un patch indiquant les tests effectués, pour une éventuelle activation par défaut (dès lors queCONFIG_RTL8XXXU
est activée, quelle que soit l'état deCONFIG_RTL8XXXU_UNTESTED
).Bons tests !
Debian Consultant @ DEBAMAX
# NBD ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message [résolu] éditer un fichier .qcow2. Évalué à 5.
Ces temps-ci j'ai tendance à utiliser des volumes logiques (LVM) mais j'ai conservé quelques notes à propos de NBD pour les images QCOW2 :
À partir de là, tu devrais avoir autant d'entrées dans
/dev/mapper
qu'il y a de partitions dans l'image. Tu peux ensuite utilisermount
pour récupérer la main sur les fichiers à l'intérieur de chacune.Après démontage :
Debian Consultant @ DEBAMAX
# Debian Live ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Écran noir un peu après GRUB.. Évalué à 3.
Histoire de comparer ce qui est comparable, je regarderais du côté des images Debian live publiées pour 12.1.0 (même si ces dernières sont figées dans le temps, et sont plus « vieilles » que ton système, ça devrait permettre de vérifier si un problème matériel est apparu vs. un problème logiciel).
Si le système se charge correctement, j'en profiterais pour regarder ce qu'il y a dans le système de fichiers racine. Notamment
/var/log/apt/*.log
pour les mises à jour installées « dernièrement » mais non nécessairement appliquées. Dans ton cas, les paquetslinux-image-*
et assimilés peuvent avoir été mis à jour il y a plusieurs jours ou semaines, mais sans le redémarrage associé, il arrive de se rendre compte d'éventuelles régressions bien plus tard.Ces derniers temps, les paquets
*-microcode
ont été mis à jour. Je n'ai pas le détail en tête (et c'est de toute façon souvent compliqué avec les constructeurs qui communiquent peu de détails techniques), mais ça pourrait valoir le coup de supprimer le paquet, rebuilder l'initramfs, et retenter un démarrage sans. Si le problème disparaît, retenter l'installation de la version précédente, vérifier que ça continue à fonctionner, puis ouvrir un rapport de bogue pour signaler la régression.Quant aux erreurs ACPI, c'est malheureusement très courant, et ça peut ne pas être plus gênant que cela… À nouveau, en accédant à ton système de fichiers racines depuis un système live, tu dois pouvoir vérifier la présence ou non de ce message dans les logs noyau des démarrages passés.
Bon courage.
Debian Consultant @ DEBAMAX
# Hiscox ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Recherche assurance pro pour SASU en conseil et informatique. Évalué à 2.
J'ai été un temps chez AXA avec leur offre MRP, dont la base était un peu élevée (800+ euros en 2015)… parce qu'il y avait une promotion « startup » (je rentrais dans les cases pour des raisons qui m'échappent, étant une SASU avec une volonté claire d'être le seul et unique salarié) rendant le tarif abordable (environ la moitié). En quelques années, ça a pris 50 %, tandis que l'agence ne donnait pas satisfaction sur d'autres points. J'ai basculé chez Hiscox, qui semble bien connaître nos métiers, pour un tarif inférieur et des garanties supérieures.
Je n'ai eu besoin de faire jouer ni l'une ni l'autre à ce jour, donc je ne peux pas en dire beaucoup plus.
Debian Consultant @ DEBAMAX
# Wake-on-LAN
Posté par Cyril Brulebois (site web personnel) . En réponse au message sortir un ordi de veille à distance, via wifi. Évalué à 7.
Sous réserve que ça soit disponible et activé sur les interfaces concernées (LAN et/ou WLAN), il suffit de lancer
wakeonlan la:ma:ca:dd:re:ss
et la machine revient. Je l'utilise sur des machines complètement éteintes plutôt qu'en sommeil, mais ça ne devrait pas faire de différence.L'article Wikipedia est très complet.
:)
Debian Consultant @ DEBAMAX
[^] # Re: raspi-firmware + linux-image-6.1.0-10-amd64 ?
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian 12 : dpkg - problème récurent. Évalué à 4.
Il s'agit d'un PC mais #1035382.
Debian Consultant @ DEBAMAX
[^] # Re: Problème connu
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian 12 : dpkg - problème récurent. Évalué à 4.
Non, il s'agit de supprimer les hooks déployés par le paquet
raspi-firmware
donc les deuxz50-raspi-firmware
.Encore désolé pour la confusion dans la première réponse.
Debian Consultant @ DEBAMAX
[^] # Re: Problème connu
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian 12 : dpkg - problème récurent. Évalué à 6.
Désolé, un des deux chemins n'était pas le bon :
et il va falloir repêcher le fichier que je t'ai fait supprimer par erreur…
Comme il s'agit d'un fichier de configuration, une simple réinstallation du paquet ne suffit pas. Tu peux utiliser ceci :
(Tu peux ensuite enlever le paquet téléchargé et le répertoire où son contenu a été extrait.)
Debian Consultant @ DEBAMAX
# Problème connu
Posté par Cyril Brulebois (site web personnel) . En réponse au message Debian 12 : dpkg - problème récurent. Évalué à 5.
J'imagine que tu as installé depuis une image « Live ». Celles-ci installent tous les paquets de type firmware, problème qui sera corrigé dans les images 12.1 la semaine prochaine. Les images d'installation classiques (e.g.
netinst
) n'ont pas ce problème.Il me semble que la suppression du paquet
raspi-firmware
n'est pas triviale (à cause d'autres problèmes…), je pense que tu peux supprimer les deux hooks pour éviter de rencontrer ces problèmes à chaque installation/mise à jour de noyau et paquets liés (e.g.initramfs-tools
), avant de demander àdpkg
de terminer la configuration des paquets concernés :Debian Consultant @ DEBAMAX
[^] # Re: try this ...
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème sed. Évalué à 2.
Recherche web : « opengroup sed » → #1
Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
Un cas ultra classique est
udev
, mais il est de toute façon nécessaire qu'il soit capable de tourner sur la version de noyau disponible dans la distribution précédente, pour être capable de faire la mise à niveau deoldstable
àstable
… (en revanche pas de garantie de pouvoir « sauter » une version). Je ne pense pas que ça soit délirant en attendant d'avoir un retour de l'équipe noyau sur ton rapport de bogue.Si tu veux chasser le problème, je t'invite à t'appuyer sur snapshot.debian.org qui va te permettre de bisecter grossièrement sans aucune compilation (attention à ne pas remplir ton
/boot
). Normalement ça permet d'isoler la dernière version upstream qui fonctionne et la première qui ne fonctionne pas. C'est une information très intéressante pour la gestion du rapport de bogue, je t'invite à indiquer les résultats si tu arrives jusque-là.À ce stade, si tu veux poursuivre : Quand tu as de la chance, c'est la même version upstream, et c'est juste une modification dans le packaging qui explique la différence. Autrement, j'ai tendance à prendre le tag
v5.OK.0
et le tagv5.KO.0
pour vérifier, et ensuite lancer le bisect « linéaire » entre ces deux tags (ça évite de partir dans les branches stableslinux-5.OK.y
etlinux-5.KO.y
– mais ça peut être nécessaire si les tests faits sur les tags en question ne donnent pas le même résultat que le bisect sur les binaires). Bien évidemment, vu le modèle de développement de Linux, le bisect « linéaire » implique tout de même de voir des versions bien plus vieilles, puisquemaster
est principalement une succession de merges depuis des branches qui ont été préparées sur des versions inférieures.Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
En ayant redémarré sur le noyau fourni dans Debian 12,
reportbug
est ton ami (cf. https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-bugs.html#s9.2).Debian Consultant @ DEBAMAX
[^] # Re: synthèse des réponses
Posté par Cyril Brulebois (site web personnel) . En réponse au message [RÉSOLU] synchroniser les changements dans /boot vers /mnt/boot[23]. Évalué à 3.
OK, désolé pour ce point. N'ayant pas croisé ce genre d'unités dans la nature, j'ai regardé si je pouvais trouver un exemple et monter un PoC localement, et je n'ai pas vérifié sa page de manuel étant donné le comportement que tu décrivais et qui semblait s'expliquer par cette absence (perçue).
Debian Consultant @ DEBAMAX
[^] # Re: synthèse des réponses
Posté par Cyril Brulebois (site web personnel) . En réponse au message [RÉSOLU] synchroniser les changements dans /boot vers /mnt/boot[23]. Évalué à 3.
Il n'y a ni condition ni relation déclarées.
L'unité service étant activée pour
multi-user.target
, elle est bien sûr lancée automatiquement au démarrage. N'étant pas reliée à l'unité path, elle n'est bien sûr pas lancée quand l'unité path est activée.Ceci semble faire le job — mais je ne vais pas m'amuser à redémarrer mon laptop pour vérifier le comportement au démarrage.
Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 2.
OK. Je préférais vérifier…
Je commence à ne plus avoir trop d'idées. Tu pourrais essayer d'installer un
linux-image
depuisunstable
, des fois que ça soit une régression dans les noyaux 6.1.y…Debian Consultant @ DEBAMAX
# Lecture de systemd.service(5)
Posté par Cyril Brulebois (site web personnel) . En réponse au message [RÉSOLU] synchroniser les changements dans /boot vers /mnt/boot[23]. Évalué à 4.
Je pense qu'il faut absolument lire la doc sur les types de service. Déclarer un
Type=simple
implique qu'on s'attend à avoir un démon qui tourne. Or ici une commande est exécutée,bash
termine, ce que systemd corrige en redémarrant après un délai de 10 secondes, obéissant aux directivesRestart*
.J'imagine que se débarrasser de ces directives, basculer sur
Type=oneshot
devrait faire ce que tu souhaites. À tout le moins, cela devrait être une meilleure base de travail.Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 2.
Oui, ça apparaissait dans le log OK.
Désolé si la dernière demande n'était pas claire, serait-il possible d'avoir le log complet du dernier boot KO, après avoir tenté le chargement manuel de tous les modules ?
Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
Que contient le fichier
modesetting.conf
?Que se passe-t-il si tu charges à la main tous les modules
drm
. Oubliant toute subtilité, ceci devrait convenir :Nouveaux logs noyau appréciés.
Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
Il s'agit d'un (seul si je me souviens bien) essai parmi beaucoup d'autres, sans ces options.
Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
Idéalement, poster le paragraphe de l'entrée GRUB démarrée, voir
/boot/grub/grub.cfg
complet pendant qu'on y est. Et vérifier le contenu de l'initramfs pour le noyau cible (cf.lsinitramfs
). Il doit y avoir plein de modulesdrm/*
dedans, et ça doit être chargé automatiquement au démarrage. Vérifier enfin les éventuelles blagues sur les chargements de module via/etc/mod*
.Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 3.
Première étape, comprendre ce que fait
initrd=/install/gtk/initrd.gz
sur la ligne de commande du noyau, l'enlever, et réessayer avec un initramfs qui n'est pas celui d'une image d'installation.Debian Consultant @ DEBAMAX
[^] # Re: Portes attention aux lignes contenant "EE"
Posté par Cyril Brulebois (site web personnel) . En réponse au message Problème pilote radeon depuis passage à Bookworm. Évalué à 2.
C'est dur de t'aider si tu regardes les logs noyau pour toi…
Debian Consultant @ DEBAMAX