wildtruc

  • 30 janv. 2024
  • Inscrit 7 nov. 2016
  • 0 meilleure réponse
  • Petit nouveau
  • Pour info : avec les derniers patch le script est désormais stable (à ce que j’en sache).

    Note : il possible d’ajouter la prise en charge des pilotes installés par rpmfusion. n’ayant jamais utilisé ces pilotes (sauf il y a très longtemps et avec une expérience fâcheuse), je n’ai pas d’idée de leur mode d’installation dans l’arborescence.

    Cette prise en charge ne peut donc avoir lieu qu’avec de l’assistance (non, je ne compte pas les installer, j’en suis encore traumatisé).

    Bonne journée o/

  • Bonsoir 🙂

    Après moultes péripéties que ma honte m’empêche de dévoiler (mais pas le changelog). La dernière mise à jour s’installe cette fois normalement et tous les droits sont enfin correctes. Enfin !
    Il risque d’apparaitre une petit alerte si lancé depuis un terminal, c’est inoffensif et corrigé dans l’upload de demain avec d’autres changements.

    La vague de téléchargeurs a dû être deçu et j’espère qu’ils retenteront l’expérience. Changer de méthode de préconfiguration n’est pas sans heurs, moi et mes 2 neurones vaillants l’avont appris à nos dépends.

    Note : personne n’est à l’abris d’une erreur, moi peut être plus que les autres, c’est pourquoi le feeback est important. Il permet de corriger rapidement ce qui sans cela pourrait mettre des mois à être détecté.

    Si je prends cela sur le ton de l’ironie, c’est uniquement pour éviter de me donner des claques 🙂.

  • Nicosss Désolé, je ne t’ai pas répondu, tellement surpris que j’étais d’avoir un feedback 🤣.

    Non, en fait ça ne m’a pas apporté de contributeur, qques utilisateurs obstinés qui n’ont pas peur de mes erreurs, sans plus. D’un autre coté, ceux qui l’avait déjà installé ne devait pas vraiment souffrir de certaines erreurs puisque tout était déjà en place.

    Nicosss Je ne pourrais pas t’apporter plus de tests car j’ai abandonné Nvidia depuis très très longtemps pour ma santé mentale

    Comme je te comprends. Ce n’est pas pour rien que j’ai lancé se projet à l’origine, ma santé mentale étant aussi à rude épreuve à l’époque. Sans compter que les développeurs de Nvidia fond tjrs les choses … à leur manière au point qu’on pourrait se croire dans un vieux film des années 90.

    Note pour @NovFedo : la prise en charge des pilotes mis à jour par rédémarrage de session n’est pas pris en charge pour KDE, hélas. KDE utilise un système par fichier desktop et n’utilise pas de service pour démarrer la session.
    Je n’ai pas KDE, ce qui fait que je n’ai sait pas trop comment me débrouiller avec.

    Note pour @Nicosss : Mon firefox ne veut pas charger le re-capcha à la connexion. Le Tor Browser n’a pas ce soucis. Il faudrait voir avec les devs du site ce qui ne va pas, ce js étant tout simplement en interdiction.

    • NovFedo Merci.
      Tu es le premier feedback que j’ai depuis des lustres, grace à toi j’ai pu fixer des petites choses qui m’avaient échappées parce que je n’y avais pas remis le nez malgré les très gros changements dans le codes. Notament sur les privilèges à l’installation.

      J’envoies le fix comme cadeau de fin d’année 🙂

      J’espère que j’aurais d’autres retours.

    • C’est un projet que j’ai lancé il y a très longtemps puis interrompu pour raison de santé. N’étant pas un codeur de profession, j’avais juste partagé mon travail sur GIT sans ambition d’aucune sorte.
      À l’arrivé des pilotes open source, j’ai remis les mains dans le cambouis pour me permettre de faire un switch entre les 2 versions sans réel ambition de le partager, mon cerveau ne s’étant pas franchement remis des états connexes de mon état de santé, les erreurs, coquilles, fautes de frappe ou effacements involontaire étant légion.
      J’ai mis plusieurs années à réécrire ce qui était mal fait, corriger mes erreurs et apprendre encore et encore, votre humble serviteur étant très lent, vraiment très lent à la détente.

      Non content d’être à la fois lent et plein de lacunes en code bash, j’ai enfoncé le clou en ajoutant de plus en plus de fonction avec tous les bugs, oublies et j’en passe, qui m’ont causés des grands moments de honte qui m’ont donnés parfois l’envie de rester caché dans un trou.

      Si je me permet d’en faire écho ici, c’est que le code est enfin propre et que la traduction en français pointe le bout de son nez (dieu que c’est long !). Il n’est toujours pas à l’abri des erreurs de mon cerveau mal foutu, mais ça se corrige …. (sic)

      L’icône de Zenvidia est un couteau suisse. Le script qui a abandonné zenity en faveur de yad fait à peu près tout ce qu’on voudrait pour un gestionnaire des pilotes Nvidia, y compris une mise en œuvre des pilotes au redémarrage de la session et non du pc pour les mise à jour (pas pour un fresh, faut pas rêver non plus) et le switch entre open et propriétaire (ce qui était le but original de la reprise, ça a un peu dérapé).
      Il prend aussi en charge le PRIME display (PRIME et PRIME offload, d’autres serez possible mais pas sans feedback)

      Je vous l’offre au test parce qu’il est désormais facile à enlever tout comme les pilotes Nvidia installé par son entremise. J’espère seulement que vous le trouverez aussi pratique que moi 🙂 et en sachant qu’il n’est pas à l’abri d’un urgent fix inopiné (ce qui est déjà arrivé . . . )

      https://github.com/wildtruc/zenvidia

      • Après lecture du bug report, c'est apparemment un problème d'UEFI.
        Je n'aime pas trop l'UEFI, je suis en dual boot bios legacy et pas de soucis.
        Mais bon, si tu as pu rétrograder...
      • Nicosss wrote:Parfait, il devait s'agir d'une régression quelque part dans le kernel.
        Apparemment, le kernel a été rapidement mis à jour. Je vais sans doute tenté la maj de ostree finalement en espérant qu'l n'y aura pas de soucis.
        Ce sera peut être un [résolu] pour moi aussi.
      • Ça dépend aussi de ta config Xorg.conf, à partir d'un certain nombre d'écran il est souvent préférable de les déclarer séparément. Xrandr ne résout pas toujours tout.
        Ça peut aussi dépendre de ta carte graphique (nvidia ? radeon? intégrée ? etc)
      • @Jules; c'est reste pas impossible, il m'a fallu fouiller pour trouver la cause possible à l'origine.
        Et puis ta liste de paquet est la même que la mienne à l'exception de ostree.
        Si tu as toujours les droits en écriture sur le système, fais une vérification de la version d'ostree et ostree-libs :
        dnf info ostree
        dnf info ostree-libs
        Si ta version est 2022-5 fais un downgrade, ça coute rien.
        dnf downgrade ostree ostree-libs
        Il se peut aussi qu'il y est eu un défaut de mise à jour et que la version d'ostree-libs ne soit pas la même que celle d'ostree (je n'ai pas eu l'occasion de vérifié), dans ce cas cqfd.
        De mon coté le kernel n'était pas en cause, un démarrage sur l'ancien a généré le même problème.
      • Si tu as copié sur une SSD mieux vaut éviter trop de journalisation que les SSD n'apprécient que moyennement.
        UUID=d96ec408-ee50-48a4-80fc-4c148ba992d5  /home         ext4	noatime,nodiratime		1 2
      • Rien de matériel, j'ai juste relancé après la maj.
        Après le premier problème, j'ai exploré tout les logs. Rien trouvé nul part sauf que c'était lié à la mise à jour.
        J'ai été de contraint de faire une fresh.
        le premier lancement pas de soucis. Je fais l'update et redémmarre. Ça me le refait à l'identique. plymouth calle et ne permet pas à lightdm de lancer l'interface de base. Je suis en lecture seule.
        Je re-refais une fresh.
        Cette fois je fais l'update étape par étape, en évitant les paquets de la dernière maj et réservant ostree que je suspecte déjà. Tout passe et le pc fonctionne sans soucis.
        Je l'ai mis à jour à la fin, mais aucune envie de refaire une fresh, j'ai donc fais un downgrade du paquet avant de relancer.
        Depuis plus de soucis.

        C'est pas une preuve à 100%, mais à 98.

        La raison peut être multiple, mais je suspecte le fais que je sois en intallation classique sur partitionnement classique. Pas de btrfs, lvm.
        Elle peut affecté des gens ou pas, c'est la magie de l'informatique.

        Paquet en cause :
        ostree x86_64 2022.5-2.fc36 updates 234 k
        ostree-libs x86_64 2022.5-2.fc36 updates 435 k

        Notes que sur la maj en cause à l'origine, seul ostree sans les libs était indiqué dans l'historique. Ceci peut être aussi cela.
        Le downgrade :
        Upgrade ostree-2022.5-2.fc36.x86_64 @updates
        Upgraded ostree-2022.1-2.fc36.x86_64 @@System
        Upgrade ostree-libs-2022.5-2.fc36.x86_64 @updates
        Upgraded ostree-libs-2022.1-2.fc36.x86_64 @@System
      • A la dernière mise à jour, j'ai eu un plantage intégral du système qui la rendu inaccessible en écriture.
        Mon installation est une Fedora spin Mate-Compiz.

        La mise en jour en cause est "ostree" et "ostree-libs"

        Je n'ai pas trouvé d'autre solution que de réinstaller le système celui-ci n'étant accessible qu'en lecture seule, un 'dnf downgrade' n'a pas pu résoudre le problème.

        si vous confronter à ce problème :
        - réinstallé en fresh.
        - faite un : dnf update
        - puis à la suite un : dnf downgrade ostree ostree-libs

        Surtout NE PAS REDÉMARRER avant cela.

        J'espère que mon soucis est anecdotique et tout le monde n'en a pas souffert.

        My2cents.

        RÉSOLU AVEC LA MISE À JOUR D'URGENCE DU KERNEL-5.18.16-200
        C'était apparemment un micmac entre les paquets.
      • J'ai dernièrement mis en ligne un bloc-note suite à mon long périple pour résoudre le problème du pci-passthrough entre 2 Nvidia sous Qemu-KVM avec virt-manager.
        Ce type de VM étant principalement dédié aux jeux, je me suis dit que c'était un bon endroit où le faire atterrir. Il peut être cependant ajouté/lié à d'autre bases de topics réclamant des ressources graphiques importantes pour les machines virtuelles.

        Toutes contributions est bien sûr la bienvenue.
      • Projet mis à jour.

        Un seul soucis, cependant. Au redémarrage de session, le champ de mot de passe semble se recharger 2 fois et peut mettre jusq'à 40s pour s'afficher correctement. Le reboot, lui ne pose pas de problème.
        Peut être un problème avec le policy-kit.

        Je n'ai pu tester que lightdm. Du debug est donc peut être à prévoir pour gdm, kdm ou sddm.
      • Deux ans, c'était trop vieux. les variables ont beaucoup changées entre temps et on demandé un rewrite complet.
        Ce jour, l'opé est presque terminer. Ce sera mis en ligne après test en réel.

        Mon Homard, tu es sous KDE, il me semble?
        Les autostarts de KDE sont bien dans ~/.kde/share/autostart?
        Je sais que ça varie parfois d'une distro à l'autre (ou variait, je n'ai pas testé KDE depuis très longtemps).
      • Merci, mais déjà essayé. Et en effet, ne marche que pour nouveau.
        De toute manière, je suis sous Fedora Mate, pas de wayland même si j'aimerai bien.

        J'ai quand même un brèche grace à un thead sur le nvidia dev talk. si tout ce passe bien, ce sera fix d'ici la fin de la semaine. 😉
      • Après avoir mis à niveau la Fedroa 24 vers la 27 ce We sur mon laptop Optimus, J'ai découvert que la méthode employé pour la permutation de PRIME est cassée.
        Xrandr ne détecte plus la provider nvidia.

        J'essaye actuellement d'explorer qui du pilote (390.48), du kernel (4.15) ou de xrandr est en cause.
        la dernière expérimentation tendrait à pointer vers le pilote stable de nvidia, mais rien n'est si sûr.

        Si je trouve qque chose (ou si qqu'un trouve qque chose), je posterai ici jusqu'à je l'epère résolution du problème.
      • modesetting est un 'pilote' de mesa qui permet de basculer entre la discret card et la principale. Et il semble en effet qu'il y est des soucis avec le pilote proprio.

        par exemple, voici la conf xorg.conf.d lors du basculement d'intel vers nvidia avec nvidia-prime:
        Section "Module"
          Disable "glamoregl"
          Load "modesetting"
        EndSection
        Section "Device"
          Identifier "nvidia"
          Driver "nvidia"
          BusID "PCI:1:0:0"
          Option "AllowEmptyInitialConfiguration"
          Option "DPI" "96 x 96"
        EndSection
        
        Section "Files"
          ModulePath   "/usr/lib64/nvidia/xorg"
          ModulePath   "/usr/lib64/xorg/modules"
        EndSection
        le pilote modestting est alors chargé pour informer le system que ce n'est plus intel qui manage (en gros) et du coup, ne reste plus qu'à paramétrer xrandr, genre :
        xrandr --setprovideroutputsource modesetting NVIDIA-0
        xrandr --output LVDS1 --mode 1920x1080 -pos0x0
        contrairement à DRI_PRIME qui fait:
        xrandr --setprovideroutputsource Intel NVIDIA-0
        puis la def du moniteur.
        Y en a-t-il un meilleurs que l'autre, faut voir et tester. d'un autre côté, mon fork a déjà près de 2 ans; il peut être tout à fait outdated :s.
        Je laisserai un petit post ici dès que je l'aurai fait. Ça risque de me prendre un petit peu de temps par contre.
      • Je crois que j'ai compris DRI_PRIME.
        C'est la configuration pré-modsetting. Donc, oui, nvidia-prime est en effet mieux puisqu'il prends en compte l'évolution de DRI3 et de la fonction modsetting et utilise le pilote modesetting d'intel.
      • Merci pour la coquille, ce n'est pas la première ni la dernière. Mon clavier et moi, c'est une très longue histoire de "je t'aime, moi non plus".

        Je ne connaissais pas la variable DRI_PRIME, comme quoi je n'ai pas mis mon nez là-desdas depuis un moment.
        Pour faire court, nvidia-prime-select bascule de l'intel vers la nvidia et vice-versa via un simple redémarrage de session. La différence avec Fedora prime est qu'on à la possibilité de n'utiliser que la nvidia même après redémarrage. la seconde différence est que si l'on a les pilotes proprio installer de manière un peut étrange (vive moi!), on peut facilement les déclarer et les utiliser. La dernière différence, et pas des moindres, nvidia-prime-select est multi distros, Fedore-prime, hé bien, c'est dans le nom.

        Je viens de lire rapidement l'article de Arch consacré à DRI_PRIME, ça semble plus un concept proche de bumblebee, mais en plus simple. J'ai toujours mon laptop optimus, je jetterai un œil pour voir la différence.