Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Avant les modifs que tu m'as conseillées, il m'était demandé le mote de passe administrateur (je te rappelle que je n'ai pas de sudo). Depuis les modifications l'ouverture est directe sans demande de mot de passe.
L'USB fonctionne bien sûr toujours dans les MV, le gestionnaire de MV s'ouvre toujours sans demande de mot de passe administrateur Par curiosité j'ai fait de même pour le comte utilisateur, là le mot de passe root m'est à nouveau demandé pour l'ouverture de KVM, et sans surprise, les périphériques USB ne fonctionnent plus.
J'ai donc rétabli les groupes pour le compte utilisateur uniquement et ça fonctionne parfaitement, ce qui est le but recherché.
Pour valider le bon fonctionnement sans droit et group, on va supprimer les commandes que je t'ai donné a effectuer
Pour résumer donc, le fonctionnement de l'USB dans KVM peut se faire sans que root fasse partie des groupes libvirt et kvm, par contre il reste bien obligatoire que le compte utilisateur lui en fasse toujours partie.
Citer
Tu m'as donné du travail 😀, mais c'était très intéressant, ça fera certainement l'objet d'un article pour mon blog.
Oui, et je te remercie encore pour ton temps et ton savoir. Content que tout ceci puisse te donner matière à nourrir ton blog. Je pense que ceci devrait rendre service à plus d'un, car ça me semble un peu, pour ne pas dire beaucoup, dommage que ce genre de chose ne soit pas configuré dès l'installation, ce qui se fait de plus dans d'autres distributions. Si OpenSuse Linux veut vraiment être plus adopté, alors il faut passer par une plus grande simplicité d'installation. Mais ça n'est que mon avis.
@Yoman Voilà, j'ai testé le résultat sur les machines virtuelles.
Et j'ai retrouvé le fonctionnement de celles-ci avec les périphériques USB, tels que je l'avais avec la Alma Linux et tel que je l'ai avec la Fedora sur mon portable.
En fait je n'ai rien eu à faire d'autre que de démarrer une machine (la Fedora puisque c'est sur celle-ci que j'avais découvert le problème), puis ensuite connecter une clef USB, celle-ci a été capturée par la MV instantanément, j'ai pu naviguer dans ses dossiers, ouvrir les fichiers, l'éjecter et après retrait de la clef redémarrer la MV sans blocage.
De plus, j'ai également le copier/coller qui fonctionne, ce qui n'était pas le cas mais que j'avais omis afin de ne pas faire un post de plus pour cette chose de moindre importance.
Je vais passer ce sujet en résolu.
Avant cela juste une question si tu permets : Vu que dans ma bourde j'ai ajouté le root aux groupes libvirt et kvm, faut-il faire la manœuvre inverse ? Si oui, comment STP, si non, laisser en l'état ne risque-t-il pas de faire une faille de sécurité ?
Un grand merci à toi Yoman pour ton aide précieuse et tes explications.
Lancer sa session en root, ce n'est pas du tout conseillé, mais...
Non, je n'ai pas lancé ma cession en root, c'est juste dans le terminal que je me logue en root quand c'est nécessaire. En l'occurrence pour rentrer les commandes nécessitant les privilèges de root. Tu as raison de rappeler ce principe, je connais des personnes qui s'obstinent, malgré mes avertissements, à le faire...
qemu : c'était pour kvm en ligne de commade (au cas oû) et wheel : c'était pour les droits admin/sudo ,mais opensuse le fait directement dans le fichier sudoers (au cas oû aussi)
Je ne les aies pas mis dans la commande , car à ce stade c'était inutile.
eric@localhost:~> groups $USER eric : eric libvirt kvm eric@localhost:~>
Du coup il ne me reste plus qu'à tester le résultat avec les machines virtuelles. Je ferai ça plus tard dans la journée, là je dois partir, mais je tenais à te répondre au plus vite. Je te fais donc très vite un compte rendu.
Bonjour @Yoma, merci pour ta réponse. J'ai donc supprimé le périphérique USB créé précédemment, ce qui a permis de pourvoir démarrer correctement la machine virtuelle (Fedora). J'ai ensuite rentré la commande que tu m'as donnée :
- Question au sujet de cette ligne : dans ton message tu énumère les groupes libvirt; kvm; qemu; wheel, cependant dans ta commande seuls les deux premiers sont inclus. Est-ce normal, dans ce cas pourquoi ? Ou est-ce un simple oubli ?
De toute façon, après introduction de la commande et un retour au prompt SANS erreur, j'ai donc rebooté le bestiau.
Dans la gestion des groupes avec Yast, rien n'est changé, seul mon user apparaît :
eric@localhost:~> groups $USER eric : eric eric@localhost:~>
Est-ce normal ? Je parie que non, car même si effectivement il s'agit d'un oubli pour les deux derniers groupes dont tu parle, il devrait normalement y avoir les deux premiers dans ce retour de commande, vrai ou faux ?
Désolé que les choses ne se passent pas comme prévu.
Je veux préciser deux choses : 1 - La commande pour l'ajout des groupes je l'ai faite en root, je n'ai pas de sudo puisque j'ai activé le compte root à l'installation. 2 - Comme précisé dans mon premier post, j'ai fait l'installation de la virtualisation (KVM) lors de l'installation du système en ajoutant le module depuis l'installeur (Logiciels ==> sélection de KVM pour la virtualisation. Ceci serait-il à l'origine du souci ? Perso je ne pense pas, mais je peux me tromper. Dans ce cas, si c'est l'origine du problème, c'est un sacré bug !!!
Dans la console de ta VM, ajoute ta clé USB en tant que périphérique, et non en tant que redirection USB.
Je m'étais effectivement trompé de manip. Après démarrage d'une MV, dans la console j'ai cliqué sur le bouton «Afficher les détail du matériel...» Dans la fenêtre en bas à gauche j'ai cliqué sur «Ajouter un matériel», dans la liste j'ai cliqué sur «Périphérique hôte USB», après sélection de la clef USB j'ai cliqué sur «Terminer». Et là effectivement j'ai pu utiliser la clef USB dans la machine virtuelle (Fedora 43). En effet ta solution fonctionne. Cependant, alors que j'ai démonté proprement la clef USB dans la Fedora en l'éjectant, il s'avère qu'au redémarrage de la même MV, clef absente du port USB j'ai le message d'erreur suivant :
Erreur lors du démarrage du domaine: erreur interne : N'a pas trouvé le périphérique USB 0781:5581
Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 67, in cb_wrapper callback(asyncjob, *args, **kwargs) ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb callback(*args, **kwargs) ~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/object/domain.py", line 1467, in startup self._backend.create() ~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.13/site-packages/libvirt.py", line 1390, in create raise libvirtError('virDomainCreate() failed') libvirt.libvirtError: erreur interne : N'a pas trouvé le périphérique USB 0781:5581
Il faut maintenant que la clef soit présente pour que je puisse utiliser cette VM.
S'il faut aller fouiller à nouveau dans la console pour enlever ce périphérique, le moins que l'on puisse en dire c'est que ça complique sérieusement l'utilisation des MV !
Je comprends ceci d'autant moins qu'avec la Alma Linux que j’utilisais précédemment, de même qu'avec la Fedora 43 installée sur mon ordinateur portable, je n'ai qu'à brancher un périphérique USB quand je suis sur une MV, celui-ci est monté automatiquement, se démonte de même et ne bloque pas la MV quand le port USB est vide. Et je n'ai jamais eu à configurer quoi que ce soit pour ça, d'où mon incompréhension face à ce problème.
Quelle autre manip faut-il faire pour que ça fonctionne simplement, automatiquement et correctement ? Est-ce possible avec Open Suse ?
eric@localhost:~> groups $USER eric : eric eric@localhost:~>
Il semble donc que je fais bien partie du groupe user.
Merci pour les précisions sur les UID et les GID. Je vais aller étidier ça plus sereinement dès que je le pourrai, il ne faut jamais perdre une occasion de s'instruire. 😉 Je n'ai pas changé les valeurs, quand j'ai vu les erreurs, j'ai cliqué sur «annuler» afin de rien casser. Bonne soirée Yoman.
Bonjour @Yoman . La reconnaissance des périphériques USB depuis ma session se fait parfaitement, dès que j'introduit une clef USB ou autre, j'ai le son caractéristique de Gnome qui m'indique l'action et la reconnaissance du périphérique. Si je suis dans une machine virtuelle c'est à ce moment là que j'ai le message d'erreur, preuve donc que le périphérique est bien vu par la MV. Je n'ai aucun souci avec mon clavier et ma souris qui sont en USB. J'ai été dans les modules Yast, dans la gestion des utilisateurs et des groupes. Dans l'onglet «groupe» j'ai deux utilisateurs qui apparaissent. En premier : moi - id du groupe 1000 - membres du groupe : moi. En deuxième : users - id du groupe 100 - membres du groupe : c'est vide
J'ai fait un double clic sur moi, ce qui a ouvert une lista de groupes, tous son décochés. Sauf erreur de ma part c'est bien KVM qui gère les machines virtuelles, c'est en tout cas ce que j'ai sélectionné dans «logiciels» au moment de l'installation. J'ai cherché dans la liste de groupe une groupe «kvm», je n'ai rien trouvé, ni d’ailleurs dans la liste de groupes pour users.
Citer
Sinon, au pire, vérifie si tu es dans le groupe kvm :
Code: [Sélectionner] groups $USER
J'ai cherché dans la liste des groupes pour users si «moi» apparaissait dans la liste afin de l'ajouter au groupe. Je l'ai effectivement trouvé, j'ai donc coché la case «moi» et validé mon choix. Instantanément j'ai obtenu l'erreur suivante :
L'ID de groupe sélectionné n'est pas autorisé. Sélectionnez un nombre entier valide compris entre 1000 et 60000.
Question : users a une id de groupe de 100, est-ce cela qui entraîne cette erreur ? Mais dans ce cas pourquoi la configuration à l'installation est-elle définie à 100 ? Je loupe donc quelque chose...
Bonjour à tout le monde. Merci à vous qui m'avez répondu. @Yoman : Oui, je pense aussi que c'est un problème de droits, pour ça justement je n'ai hélas pas de «point de départ» précis à donner, je ne me suis rendu compte que récemment de ce problème, n'ayant bêtement pas pensé à tester l'USB après l'installation des machines virtuelles. Mais je pense que ce souci date de l'installation de mon système, il me semble mi-septembre. Je suis sur SlowRoll. Pour les machines virtuelles, installées dans Virtual Machine Manager, j'ai Fedora, Solus, Mint, Ubuntu et Windows 11. L'USB 2 ou 3, ne fonctionne pas quelle que soient les distributions en MV.
@sobkowiak : comme l'a précisé Yoman, je n'utilise pas Virtual Box, mais Virtual Machine Manager que j'utilisais déjà dans la Alma Linux installée avant cette SlowRoll. Je n'avais rien eu à faire pour avoir l'USB dans les machines virtuelles, une fois dans ma machine virtuelle je n'avais qu'à brancher une clef USB ou un SSD externe pour qu'il soit automatiquement monté dans la VM en cours. C'est ce qui fait que je n'ai pas testé immédiatement l'USB en MV.
J'ai donc été voir dans les modules Yast, mais je n'ai pas su trouver comment et où corriger ce souci. Merci par avance pour votre aide.
Bonjour à vous, je me suis rendu compte il y a quelques temps qu'il m'est impossible d'utiliser un périphérique USB dans mes machines virtuelles, clefs, SSD externes, imprimante...
J'ai fais le tour sur les modules Yast sans y trouver de solution. Je n'ai rien trouvé non plus sur l'Internet qui m'apporte une solution.
Mon message d'erreur est toujours le même quelle que soit la distribution installée en MV ou le protocole USB2 ou USB3 ainsi que le périphérique USB) est :
Citer
g-exec-error-quark: Could not auto-redirect USB DISK 2.0 [13fe:1a23] at 1-5: L'exécution su processus fils « usr/bin/spice-client-glib-usb-acl-helper » a échoué (permission non accordée) (3) Détails : Erreur de redirection USB
Bonsoir Mahanand, Une fois que tu auras démarré comme tu le sais, avec le problème rencontré tu vas te retourve avec un écran noir à la place de ton écran de login. C'est là que pour passer en TTY tu clique ensemble sur 'ctrl' 'alt' 'F3', tu vas alors arriver sur un autre écran noir, lequel lui, te proposera une «prompt». tu tape ton login, puis ton mot de passe. Une fois que tu es dans ton compte utilisateur tu tape 'su -' puis ton mot de passe (comme dans le terminal, rien ne s'affiche) puis tu seras alors logué en root. Là tu tape la commande :
Il semble que cette solution a marché pour plusieurs utilisateurs...
Et cette solution n'a, dans un premier temps, pas fonctionné. En fait après renommage de nsswitch.conf en nsswitch.conf.back et le redémarrage j'en était au même point. Puis, ne voulant pas en resterr là je suis rentré en TTY et j'ai refait un :
suivi d'un redémarrage. Et là ça a fonctionné, j'ai sélectionné le kernel 6.17 et j'ai retrouvé le GDM et mon espace graphique tel que je l'avais laissé. En fait, dans les mises à jours présentes il y avait du downgrade des paquets GDM. Du coup je ne sais pas si c'est le renommage de nsswitch ou la seconde mise à jour qui a corrigé le problème. Perso je pense pour la seconde raison. Donc, Mahanand tu devrais avoir la solution à ton souci sur la Tumbelweed. Merci denebe pour ta réponse.
Et un grand merci renouvelé à Chalut. Je passe le sujet en résolu.
effectué bien sûr en root. Même si ceci est pour l'instant loin de me convaincre, d'où mon hésitation à la tenter.
Cette galère tombe bien mal, ayant besoin de l'ordi actuellement, mais bon, mal tomber c'est le propre d'un emm... 🤣
Ce que je ne comprends pas, c'est que le bug étant connu depuis le 25 septembre 2025, et n'étant manifestement pas résolu, les MAJ soient toujours poussées comme si de rien n'était.
Quand j'ai choisi Slowroll c'était justement parce que, me semblait-il, les MAJ étaient mieux préalablement testées avant d'être intégrées afin d'augmenter la stabilité, mais visiblement ça n'est pas le cas. C'est bien dommage...
En tout cas c'est sympa de m'avoir répondu.
Mon souci c'est qu'actuellement je n'ai pas le temps de réinstaller un système et j'ai vraiment besoin de l'ordi, en plus je crains un peu de faire des manips sui puissent entraîner une inutilisation totale de l'ordi. En ce moment je tourne sur un snaphot, comme dit dans mon premier message.
Bonjour, je viens de faire la mise à jour de ma SlowRoll ce matin. Plus de 800 paquets et passage au kernel 6.17 ainsi, je suppose, qu'à Gnome 49.
Téléchargement impeccable, aucun message d'erreur, tout semblait s'être bien passé.
Première chose curieuse, au redémarrage le dernier kernel, 6.17 en haut de la liste du Grub n'est pas sélectionné, Surpris je n'ai pas eu le temps de réagir et l'ordi démarre donc sur le kernel de la ligne du dessous, sélectionnée automatiquement au démarrage. Je rentre ma passphrase, le démarrage se lance et au bout de quelques secondes, au lieu d'arriver à la connexion graphique pour me loguer, j'ai un écran noir, juste un curseur qui clignote en haut à gauche. J'attends un long moment vu que le voyant disque clignotait. Rien... Je bascule en TTY (F2) et j'ai un prompt, je me logue, je passe en root (compte root activé sur mon installation) et tape un "reboot".
Pensant que l'erreur était due au fait que l'ordi avait démarré sur l'ancien kernel 6.16, cette fois je sélectionne bien le nouveau kernel 6.17 sur la première ligne. Même problème, redémarrage avec la même méthode, là je sélectionne un snapshot précédent, avec le kernel 6.16 et je peux me loguer normalement. Bien entendu j'ai perdu ma modification sur les machines virtuelles, mais c'est sans importance actuellement.
N'ayant jamais vécu ce genre de problème, que dois-je faire pour retrouver un système normalement fonctionnel SVP
J'espère que vous lirez ce message matinal AVANT de faire vos mise à jour, ceci afin de vous éviter cette mésaventure. Merci par avance pour vos réponses et votre aide que j'attends avec impatience.
[EDIT] J'avais lu un jour sur le forum que quelqu'un avait eu ce problème avec Tumbleweed, mais je n'ai pas réussi à retrouver ce fil, désolé.
Bonsoir guiv, je te remercie pour ton message. En fait ta commande établit une activation automatique par défaut de la connexion. Et la connexion créée automatiquement à l'installation de VMM était déjà activée (case «connexion automatique au démarrage» déjà cochée) Mais ça ne fonctionnait pas chez moi. Cependant tout ça m'a donné l'idée de créer une nouvelle connexion pour VMM avec démarrage automatique bien sûr. Et maintenant ça fonctionne parfaitement. En tout cas merci pour l'idée. 😉
Bonjour à tout le monde. J'ai installé des machines virtuelles, par Virtual Machine Manager, et tout fonctionnait parfaitement. À chaque démarrage d'une machine, j'avais une fenêtre pop up qui me signalait que le réseau par défaut était désactivé et me proposait de démarrer celui-ci, ce que je faisais et alors la machine demandée démarrait normalement. Ceci qu'elle que soit ma connexion, directe ou derrière un VPN.
Mais voilà, depuis quelques jours, ça ne fonctionne plus, et il ne m'est plus demandé si je souhaite activer le réseau au lancement d'une machine virtuelle. Rien à faire, ça ne fonctionne plus. Voici les détails du problème que me donne VMM :
Erreur lors du démarrage du domaine: L'opération demandée n'est pas valide : le réseau 'default' n'est pas actif
Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper callback(asyncjob, *args, **kwargs) ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/asyncjob.py", line 107, in tmpcb callback(*args, **kwargs) ~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/object/domain.py", line 1414, in startup self._backend.create() ~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.13/site-packages/libvirt.py", line 1390, in create raise libvirtError('virDomainCreate() failed') libvirt.libvirtError: L'opération demandée n'est pas valide : le réseau 'default' n'est pas actif
Rien n'y fait, même un redémarrage de l'ordi. Curieusement, si je créé une nouvelle machine, alors j'ai la demande d'activation du réseau pour VMM, et après avoir répondu OK pour l'activation du réseau, l'installation de la nouvelle machine se passe bien, mais en plus je peux alors utiliser toutes les autres machines virtuelles normalement. Mais bon, je ne peux pas rester avec ce problème et devoir créér une nouvelle VM chaque fois que j'ai besoin de VMM. Je n'ai pas trouvé comment faire en sorte que le réseau pour VMM soit actif par défaut dès le démarrage de VMM ou forcer l'apparition de la pop up demandant de connecter le réseau comme avant ce problème.
Bonsoir chalu, au final c'est ce que j'ai fait et du coup ça me donne la possibilité de les lire les vidéos demandant les codecs cités plus haut. VLC n'est pas mon lecteur préféré, mais là en version Flatpack il me permet de résoudre ce souci lorsque je le rencontre.
Bonsoir manchette, du coup j'ai laissé la version de Packman dont tu m'avais envoyé le lien. Ça fonctionne bien à ce jour, du coup je vais appliquer le bon vieil adage : «si ça fonctionne comme ça, alors on ne touche à rien».
