Pas de problèmes. Content d'avoir aidé 😉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
- Un petit coup de
Et vous êtes sortis d'affaire 😉su -c 'dnf install filezilla-3.29.0-2.fc27 --enablerepo=updates-testing'
- Le bug est déjà référencé : https://bugzilla.redhat.com/show_bug.cgi?id=1513241
Une version plus récente de FileZilla est dans testing...
Je vais jeter un oeil.
Ca fonctionne pour moi également. Merci.llaumgui wrote:Bonjour,
https://bugzilla.redhat.com/show_bug.cgi?id=1400041
Pour moi la solution marche :dracut --regenerate-all --force
Merci pour l'info. Je vais mettre à jour et tester.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.
Ed: Effectivement, le problème semble résolu.
Je referai le point sur ce problème à la rentrée. Si je trouve quelque chose, je reviendrai vers vous.Tomulus wrote:ok merci, c'est déjà bien !
Pour l'instant, j'utilise encore l'astuce que j'ai trouvé pour diminuer le temps d'attente.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
Tiens, je pensais qu'en xrender c'était quand même du rendu matériel. Je me trompe ?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" 😉.
J'ai pas fait l'essai avec wayland. Ca vaut le coup de tester ou c'est encore prématuré au quotidien ?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 eu des petits bugs graphiques mais depuis que je suis passé sous Xrender plus de problèmes.
Je pense que c'est temporaire de toute manière.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.
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
On obtient 10 secondes d'attente au lieu de 90 sec, ce qui est quand même mieux 😉DefaultTimeoutStopSec=10s
Je ne sais pas si il est raisonnable de mettre moins.
Dommage ça aurait peut-être aidé 😉nouvo09 wrote:Ca serait l'époque Halloween j'aurais pu formuler une idée, mais là, non.
Je vais continuer à creuser dans cette direction.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.
Pas d'utilisateur avec l' UID 1000, alors je ne sais pas trop quoi chercher.nouvo09 wrote:et tu as essayé un ps aux ?- 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 :
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é.A stop job is running for User Manager for UID 1000
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 :
A priori, ça c'est bien passé.fedup --network 24
- Dans [Résolu] kmod-wlC'est bon, ça fonctionne :-D
- Dans [Résolu] kmod-wlSuper, merci !!
- Dans [Résolu] kmod-wlSalut à 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.