Bonjour, utilisateur fan de RaspPi 2, 3, 4 il y a quelques années avec plusieurs applications dédiées à chaque PI, accessibles via SSH/VNC, je ne débute pas !! mais là je cale sur mon problème.
La PI5 étant arrivée chez moi et SCRATCH3 aussi et mon petit-fils aussi, je lui ai donc dédié ce petit bijou, avec son écran Hdmi, son clavier Azerty, sa souris, son wifi et son câble RJ45, bref un PI complet.
Donc installation traditionnelle avec Pi-Imager dernière version et le premier utilisateur (BookWorm et Pi-imager permettent de le définir à l’écriture de la SDCard) avec a priori tous pouvoirs sur tout. Clavier Français = donc passage par l’option de paramétrage pour un clavier ‹ ‹ GENERIC 105 touches › › / Français / UTF-8 en mode AZERTY. Mon utilisateur chef envoie bien un a quand je tape un a et un q quand je tape un q. Donc bonheur total.
Je me mets donc à créer un utilisateur ‹ ‹ ordinaire › › avec les commandes de base UserAdd (système, faut tout bien faire) ou AddUser (script assisté pour opérateur moins affuté).
Et là, HORREUR !!
Quand j’ouvre la session avec ce user ordinaire, le a devient q et le q devient a !!! Invivable !! J’ai essayé tout ce que j’ai pu : mettre le user dans le groupe adm(4) ou dans le groupe de l’utilisateur chef(1000) / le mettre system (mais là plus de login donc moyen moins) / Raspi-config / reconfigurer toutes les options des Locales / lire les blogs Debian en anglais !! >> Rien, aucun effet, même avec. des reboot à chaque modif de la config.
Par contre, quand j’accède au RaspPi en mode distant via SSH/VNC, le clavier déporté envoie bien un a pour le a et un q pour le q. Il s’agirait donc d’un ‹ ‹ défaut › › de la session X11 sur la RaspPi avec son clavier physique.
J’ai essayé avec la même puce sur un PI400, même défaut : le user principal fonctionne bien, tous ceux créés par la suite reste comme si clavier US.Cela ne vient donc pas du clavier autonome puisque le clavier intégré du PI400 ‹ ‹ bugge › ›.
Peut-être le problème est-il plus ancien que la Debian Bookworm mais j’en doute ?
Un peu d’aide serait appréciée.
Cordialement
JF
Après une recherche je suis tombé sur un issu sur le Git Hub de l’OS. Il y a bien un problème de changement de configuration de clavier.
Dans cet exemple, il utilise l’outil raspi-config.
- Il change le clavier de GB à FR, avec l’utilisateur « pi »,
- Il redémarre, il ce log sous pi, le clavier est FR,
- Il crée un utilisateur « myname »,
- Il ce log sous « myname », le clavier est GB, que ce soit après un reboot ou en logout de « pi » et login sous « myname ».
Ce problème affecte aussi « lxinput », il change les paramètre clavier, mais requière un droit admin. Définir « myname » en sudo user, lui permettre de changer via raspi-config, est l’option prédominante. Cependant je ne sais pas si retirer du sudoer permet de garder le paramètre actif, mais perso je ne vois pas pourquoi ça ne le garderais pas.
Il serait possible de régler le problème en passant via « xkb_layout ».
Perso, je n’ai jamais eu besoin de changer ce genre de configuration, vu que je suis QWERTY et que par défaut le EN-US ou EN-GB ressemble beaucoup au CA-EN et CA-FR, je suis également capable de m’adapter au AZERTY avec le FR, alors aucune problème, et besoin de changer la disposition du clavier. Alors mes réponses sont purement théorique.
Bonjour, et GRAND merci à levelKro
Effectivement, après un passage en qualité d’utilisateur sudo et un raspi-config sur la console dans une session, le clavier accepte de passer Azerty et d’y rester pour toute nouvelle session, même si l’utilisateur redevient ‹ ‹ normal › ›.
Je pense - opinion personelle et non étayée - qu’il s’agit d’un bug dans la commande useradd (ou adduser) qui doit ‹ ‹ oublier › › de paramétrer correctement le clavier, peut-être à partir du squelette de création intégrée des comptes.
Est-ce spécifique à la dernière version de Debian ou est-ce un truc plus ancien ? je ne sais.
Pour moi, le problème est fixé, même si la solution n’est que de contournement. Je vais peut-être tenter un petit script pour automatiser la chose pour la suite.
Donc, encore merci à levelKro et à plus sur les ondes du forum France ! 
Accessoirement, et sans aucun rapport, la fenêtre de modification des paramètres du raspi fait toujours référence (dans le pop-up d’aide de controle) à un utilisateur pi (qui n’existe plus de façon automatique maintenant). Peut-être aussi à rechercher de ce côté là.
Le travail du Raspbian est l’oeuvre de plusieurs personnes, il ce peut que certains modules, comme raspi-config, soit un peu ancien comparativement aux autres fonctions. Le changement du config.txt par exemple a été amorcé voila déjà quelques mois et est maintenant implanté.
Bonjour, j’ai bien conscience que la francisation de raspbian est bien un boulot d’ampleur et que certains modules anciens puissent attendre pour s’adapter aux nouvelles contraintes de ‹ ‹ BookWorm › ›. J’ai simplement du mal à mesurer les modifs apportées par cette évolution de l’OS de base.
En particulier, en poursuivant sur la problématique du clavier, j’ai dérivé sur l’utilisation de ‹ ‹ sudo › › et je note que, ayant fait le nécessaire pour mettre (temporairement) les nouveaux comptes ‹ ‹ à franciser › › dans le groupe sudo, la commande ‹ ‹ groups monuser › › - sensée donner la liste des groupes auxquels monuser appartient - ne mentionne pas le groupe sudo, alors qu’elle le fait pour le tout premier user administrateur.
J’en suis à me demander si cette adaptation de BookWorm au rasppi par la disparition de l’utilisateur ancestral pi à la création du système n’est tout simplement qu’un masquage de ce nom ‹ ‹ pi › › par un alias de nom mais en ayant conservé toutes les prérogatives initiales des versions antérieures de l’OS, et, pour tous les utilisateurs standarts créés a postériori, un petit bug qui oublierait tout simplement le ‹ ‹ côté francais › › du clavier physique.
Je continue à chercher d’autres ‹ ‹ anomalies › ›.
A plus
Cordialement.
JF - Caramel13
Depuis les derniers OS, la sécurité du OS a été renforcé. En premier, les sécurité exigé par la modification du Kernel et Os par Debian, la base de Raspbian. Après il y a les changements de politique sur la gestion logiciel du OS par la fondation Raspberry Pi.
Le RPi4 a mené déjà des modifications sur les prédécesseurs. Le RPi5 apporte encore un lot de modifications importante au niveau matériel. Vu que les RPi 0 v1, 1 et 2 sont « obsolète » et que le 3 et 0 v2 sont les derniers « Legacy », les besoins de configuration sont passé en priorité à ceux du RPi 4 et 5.
Depuis plusieurs années, les architecture en 32 bit sont abandonné, l’arrivé de ce dernier OS uniquement en 64 bit (version Debian) doit être porté en 32 bit pour les ancien RPi. Ceci n’est pas pratique et prend plus de temps pour une minorité.
Cependant, pour faciliter la modification du OS Debian en Raspbian, il doivent utiliser un « kitchen kit », soit un script qui modifie de manière automatisé des facettes du OS (un outils qui préconfigure des source et en modifie d’autre pour les besoins spécifique du RPi).
Cet outils a surement été ajusté pour le dernier OS mais doit comporter des facettes encore non travaillé et/ou correctement testé. Comme le cas de figure ici. Peut-être que le script fait la modification demandé, mais rencontre un problème X qui l’empêche de correctement l’appliquer (fichier dans un autre chemin, droit d’écriture, sécurité autres…)
Comme tu as été en mesure de constater, il existe un moyen de contourner le problème, alors l’application est en mesure de faire la modification, mais peut-être la modification n’a pas été apporté pour la partie pour en faire une paramètre de base. Et tout plein d’autres raisons (comme cité plus haut).
Ton cas de figure n’est pas unique, mais pas fréquent, peut d’utilisateurs ont plus d’un compte sur le RPi, et encore moins qui demande de modifier le clavier.
Ce problème sera résolu dans quelques versions, le temps que l’équipe passe en revue les problèmes rapportés. Ceci est courant lors de changement de version du OS et en plus, un changement de prise en main et configurations.
Newer is not necessary better
J,ai jamais opté pour la dernière version des OS dans mes projets, sans être trop ancien. Mis à part ce problème, l’absence de certains package est possible ou de version moins stable. Par exemple FFMpeg a pris quelques semaines avant d’être disponible sur l’ancien version du OS, à son arrivé en « current version ».
L’autre changement est que la majorité des tutoriels deviendront inutilisable avec les nouveaux OS et RPi. Déjà certains projets en souffre. Il faudra alors penser à faire des sauvegarde des OS plus anciens et de quelques package essentiel pour s’en sortir avec no « vieux » RPi.