Marcet

  • 3 avr. 2022
  • Inscrit 10 nov. 2004
  • 0 meilleure réponse
  • Posteur fou+ 4 de plus
  • fgland wrote:Un grand merci, cela marche.
    J'utilisais gftp en attendant mais fillezilla permet la mise à jour d'un fichier édité sans avoir à le fermer ce qui est bien pratique...

    Gérard
    Pas de problèmes. Content d'avoir aidé 😉
  • Un petit coup de
    su -c 'dnf install filezilla-3.29.0-2.fc27 --enablerepo=updates-testing'
    Et vous êtes sortis d'affaire 😉
  • chepioq wrote:Maintenant que plasma 5.7 est passé dans updates, j'ai fait les mises à jour et je n'ai plus ce problèmes de 1m30s d'attente lors de l'extinction (ou du re-démarrage) de mon portable.
    Merci pour l'info. Je vais mettre à jour et tester.

    Ed: Effectivement, le problème semble résolu.
  • Tomulus wrote:ok merci, c'est déjà bien !
    Je referai le point sur ce problème à la rentrée. Si je trouve quelque chose, je reviendrai vers vous.
  • Tomulus wrote:salut,
    je me permets de relancer le sujet parce que j'ai le même soucis, saut que l'attente est plutôt de 4 minutes, et que le message n'est pas exactement le même. Le voici ;
    A stopjob is running for firewalld : dynamic firewall daemon (compte rebours)

    une solution a-t-elle été trouvée ?
    merci
    Pour l'instant, j'utilise encore l'astuce que j'ai trouvé pour diminuer le temps d'attente.
  • VINDICATORs wrote:+1, mais ce n'est pas le but (en fait cela à l'air d'être le cas depuis le passage à DRI3...). Bien la peine d'avoir des processeurs graphiques aussi performant si c'est pour faire du rendu "logiciel" 😉.
    Tiens, je pensais qu'en xrender c'était quand même du rendu matériel. Je me trompe ?
    Bon au passage avec wayland pas de souci (bien d'autres, mais pas celui là) et utilisation de l'openGL 4.1 :-P! Par contre ce n'est pas encore au niveau et n'empêche pas le bogue du délai de fermeture trop long.
    J'ai pas fait l'essai avec wayland. Ca vaut le coup de tester ou c'est encore prématuré au quotidien ?
  • J'ai eu des petits bugs graphiques mais depuis que je suis passé sous Xrender plus de problèmes.
  • VINDICATORs wrote:Le souci c'est qu'en fait on ne sait pas ce qu'il fait.

    Mais bon c'est mieux qu'un reboot sauvage comme il m'arrive de le faire quand j'ai autre chose à faire... J'ai fait sauté ma partition /boot/efi avec ce genre de chose (Rah les joies du Fat16...).

    Merci pour l'astuce, il faudra qu'un jour je prenne le temps pour améliorer mes connaissances avec systemd.
    Je pense que c'est temporaire de toute manière.
    Toutes les distributions semblent touchées par ce bug.
    Ca devrait se résoudre assez vite 😉
  • En attendant que le bug soit corrigé. Voici un WorkAround :

    Editer : /etc/systemd/system.conf
    DefaultTimeoutStopSec=10s
    
    On obtient 10 secondes d'attente au lieu de 90 sec, ce qui est quand même mieux 😉

    Je ne sais pas si il est raisonnable de mettre moins.
  • nouvo09 wrote:Ca serait l'époque Halloween j'aurais pu formuler une idée, mais là, non.
    Dommage ça aurait peut-être aidé 😉
    VINDICATORs wrote:+1, même avec le livecd/usb que ce soit en boot sur la machine ou en virtuel.

    Comme je sais qu'il y a des soucis avec kinit5 (qui on failli bloquer la sortie de Fedora, mais non accepté), je me demande si ça ne vient pas de lui.
    Je vais continuer à creuser dans cette direction.
  • nouvo09 wrote:et tu as essayé un ps aux ?
    Pas d'utilisateur avec l' UID 1000, alors je ne sais pas trop quoi chercher.
  • Bonjour à tous,

    J'ai systématiquement un délai d'attente de 90 secondes lors d'un reboot ou d'un shutdown.

    Le message visible sur la console est le suivant :
    A stop job is running for User Manager for UID 1000
    Un compte à rebours de 1 min 30 sec est affiché et le reboot ou shutdown n'est exécuté que lorsque le compte à rebours est terminé.

    J'ai trouvé de vieux bugs faisant état de problèmes avec systemd pour d'autres distributions.
    Est-ce que que l'un d'entre vous a rencontré ce problème ?

    PS: J'utilise KDE. Je n'ai pas testé avec Gnome.
  • J'ai fais la mise à jour sur deux machines en utilisant :
    fedup --network 24
    A priori, ça c'est bien passé.
  • C'est bon, ça fonctionne :-D
  • Salut à tous,

    Visiblement, les dépôts rpm-fusion ne sont pas encore finalisés pour F22.

    Je cherche à installer le driver wifi pour mon laptop équipé en Broadcom.
    Est-ce qu'un autre dépôt propose kmod-wl, akmod-wl ou broadcom-wl ?
  • A priori, wget a été supprimé dans Fedora au profit de curl.
    Mais je fais partie de ceux qui préfèrent la simplicité de wget.
  • Au niveau du protocole DHCP, un octet nommé "Vendor class identifier" peut permettre d'identifier le type de client qui cherche à se connecter. On peut, dès lors, imaginer qu'on puisse établir un filtre sur cet octet.

    Mais de la même manière qu'il est possible de modifier son adresse MAC, on doit pouvoir modifier ce "Vendor class identifier". Fait une recherche sur ces termes, tu trouveras peut-être une méthode.

    Hope this helps.