Si c'est du Windows RT, il faudra tester avec une Fedora ARM et pas x86 / x86_64
Wampyr
- 16 oct. 2013
- Inscrit 29 oct. 2010
- 0 meilleure réponse
- Petit nouveau Adepte du forum Rédacteur potentiel
- Ca fait plaisir à lire, bonne continuation avec Fedora 🙂
- Idem, je ne m'en suis pas trop fait (d'où mon absence de réponse, pardon ^^')
Je passe en résolu ! - Ouf, content que ce ne soit pas de ma faute d'un coté, merci pour les infos ! 🙂
@ Nicosss : Ouaip c'est assez sévère comme bug ^^
PS : 9.2 Go dans /var/log c'est trop non ? :hammer:
[root@Dwarf log]# du -h /var/log 4.0K /var/log/mpd 4.0K /var/log/ppp 4.0K /var/log/samba/old 8.0K /var/log/samba 4.0K /var/log/sssd 8.0K /var/log/mail 27M /var/log/audit 1.1G /var/log/journal/9388a5eb453d59f4fd98567b37061720 1.1G /var/log/journal 4.0K /var/log/lightdm/.config/ibus/bus 8.0K /var/log/lightdm/.config/ibus 12K /var/log/lightdm/.config 24K /var/log/lightdm/.cache/fontconfig 8.0K /var/log/lightdm/.cache/dconf 8.0K /var/log/lightdm/.cache/lightdm-gtk-greeter 44K /var/log/lightdm/.cache 12K /var/log/lightdm/.dbus/session-bus 16K /var/log/lightdm/.dbus 108K /var/log/lightdm 132K /var/log/prelink 1000K /var/log/anaconda 1.3M /var/log/gdm 16K /var/log/cups 4.0K /var/log/chrony 9.2G /var/log
- Modifié
Salut tout le monde,
Je sais pas si le soucis vient d'une de mes bidouilles ou pas (je ne joue pas avec rsyslogd) mais au boot rsyslogd me bouffe 108% d'un coeur :
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
361 root 20 0 749668 8916 5828 S 108.9 0.228 19:35.58 rsyslogd
Ca ne se ressent pas en GUI donc pas facile à voir, quelqu'un d'autre aurait le même soucis ?
Bizarre également, cette commande me rend des messages datant du 23 avril...
[root@Dwarf myu]# cat /var/log/messages | tailcat /var/log/messages | tail
Apr 23 08:58:29 Dwarf systemd: Starting Activation of DM RAID sets...
Apr 23 08:58:29 Dwarf lvm: No volume groups found
Apr 23 08:58:29 Dwarf systemd: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Apr 23 08:58:29 Dwarf systemd: Started Show Plymouth Boot Screen.
Apr 23 08:58:29 Dwarf systemd: Starting Forward Password Requests to Plymouth Directory Watch.
Apr 23 08:58:29 Dwarf systemd: Started Forward Password Requests to Plymouth Directory Watch.
Apr 23 08:58:29 Dwarf systemd: Started Dispatch Password Requests to Console Directory Watch.
Apr 23 08:58:29 Dwarf systemd: Started Activation of DM RAID sets.
Apr 23 08:58:29 Dwarf systemd: Starting Encrypted Volumes.
Apr 23 08:58:29 Dwarf systemd: Reached target Encrypted Volumes.
Edit : Ca devrait être uniquement journald le système de logging non ?- Dans [Résolu] Keymap TTYMerci pour l'info Heldwin ! 🙂
- Dans [Résolu] Keymap TTYPetit up.
- Dans [Résolu] Keymap TTYJ'ai essayé avec une syntaxe pareille sur la ligne vconsole (vconsole.keymap=fr_BE) mais toujours du QWERTY.
Bien vu pour la reconfig de grub2, je ne l'avais pas effectuée mais ca ne change rien. - Dans [Résolu] Keymap TTY
- Modifié
Merci pour les pistes,
Alors, voici les résultats :
EDIT : J'ai modifié /etc/defaut/grub de 2 façons différentes, la keymap était effectivement en "us" mais ni "be" ni "be-latin1" n'ont l'air de fonctionner.[root@Dwarf myu]# cat /etc/X11/xorg.conf.d/00-keyboard.conf # Read and parsed by systemd-localed. It's probably wise not to edit this file # manually too freely. Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "be" EndSection [root@Dwarf myu]# cat /etc/vconsole.conf KEYMAP="be"
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.keymap=be-latin1 rhgb quiet"
- Dans [Résolu] Keymap TTY
- Modifié
Salut à tous,
La F19 ne m'ayant pas proposé de clavier be-latin1 a l'installation, j'ai installé la distro avec une keymap QWERTY.
Le soucis c'est que si en X cela est vite réglé via une petite modifications dans l'interface graphique, en TTY je suis toujours en QWERTY
loadkeys be-latin1 fontionne, de même que system-config-keyboard : les deux passent mon clavier TTY en AZERTY mais je n'arrive pas à en faire la keymap par défaut dés le démarrage, et c'est pas faute de chercher depuis quelques jours (j'aurai approfondi le sujet tiens... :hammer: )
/etc/sysconfig/keyboard me semble bon :
/etc/defaut/keyboard modifié, rien n'y fait ...[root@Dwarf azerty]# cat /etc/sysconfig/keyboard KEYTABLE="be-latin1" MODEL="pc105" LAYOUT="be"
Quelqu'un aurait une idée ?myu Dwarf ~ $ cat /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. XKBMODEL=pc105 XKBLAYOUT=be XKBVARIANT= XKBOPTIONS= KMAP=/lib/kbd/keymaps/i386/azerty/be-latin1.map.gz BACKSPACE=guess
- Modifié
Apparement bcmwl-kernel-source est le pendant Ubuntu (du code source apparemment, questions de licences, redistributions, etc...) du paquetkmod-wlwl-kmod :hammer: ...
Sur la page kmod-wl de RPM Fusion : http://download1.rpmfusion.org/nonfree/fedora/updates/13/i386/repoview/kmod-wl.html je constate un lien "source" qui pointe sur wl-kmod (qui n'est pas listé comme installé chez toi).
wl-kmod semble être le pendant de bcmwl-kernel-source
Si tu arrive à implémenter le workaround Ubuntu avec ce paquet, ca pourrait fonctionner ! 🙂
PS : Pour b43, c'est un driver broadcom que j'avais en tête mais qui ne supporte pas ta carte
PS 2 : Un lien intéressant : http://elrepo.org/tiki/wl-kmod- Modifié
Bonjour,
Si 8.8.8.8 est atteignable et pas google.com, c'est dans le DNS qui est en cause.
Quels sont les paramêtres de /etc/resolv.conf ? Et nslookup google.com renvoie quelque chose de spécial ?- Modifié
Zut...
Effectivement, il devrait arriver dans le noyau, le plus tot sera le mieux 🙂
PS : Tu as essayé le module b43 ?
Edit : Un echange sur RPM Fusion pour un package : http://comments.gmane.org/gmane.linux.redhat.fedora.rpmfusion.devel/13676 : dernière maj du 10/04/2013modprobe -vv b43
- Re,
Alors je suis d'accord, c'est du dernier recours et c'est du bon hack ! 🙂
Je pense néanmoins que les risques sont faibles, c'est plus sécurisant de le faire soi-même à partir d'un DEB qui semble très correct que de tester d'innombrables paquets RPM du fin fond du net.
PS : A recompiler à chaque kernel je pense. - Modifié
Bon, après relecture, j'ai vu que le post parlait de akmod-wl... mea culpa :/
Sur ce, que te donne modprobe -vv wl (-vv afin d'avoir plus d'info sur le chargement du module)
Sinon le plus simple serait de faire fonctionner l'ethernet en premier je pense, le support WiFi sur les PC récents étant toujours délicat (merci les constructeurs...)
EDIT : Il y'a moyen de la faire fonctionner avec cette procédure (ouverture d'un paquet deb et compilation) : http://lists.rpmfusion.org/pipermail/rpmfusion-users/2013-April/000137.html- Modifié
Hello,
Ne te manque t'il pas wl tout court ? (genre pour F18 :
wl.i686 5.100.82.112-7.fc18.4 rpmfusion-nonfree)
Source : https://ask.fedoraproject.org/question/8874/broadcom-bcm43142-wireless-on-fedora-18/ : La personne a su faire fonctionner la même carte sous F18.
Edit : F19 n'a pas (encore) tout les *kmod-wl de disponibles dans les dépots RPM Fusion, il faut voir si wl est dispo sur F18.- Modifié
Yep, j'ai essayé, sans résultats malheureusement.
Ca devient dur de mettre ma Fedora à jour hihi :
yum update --skip-broken --exclude systemd*
- Bonsoir à tous,
Je poste rapidement, n'ayant pas beaucoup de temps :
Serais-je le seul ? Sur une autre F19, je n'ai pas eu de soucis (mais je ne suis pas parti du même LiveCD) :[root@Dwarf myu]# yum update Loaded plugins: auto-update-debuginfo, langpacks Resolving Dependencies --> Running transaction check ---> Package libgudev1.x86_64 0:200-4.fc19 will be updated ---> Package libgudev1.x86_64 0:202-2.fc19 will be updated ---> Package libgudev1.x86_64 0:202-3.fc19 will be an update ---> Package systemd.x86_64 0:200-4.fc19 will be updated ---> Package systemd.x86_64 0:202-2.fc19 will be updated ---> Package systemd.x86_64 0:202-3.fc19 will be an update ---> Package systemd-libs.x86_64 0:200-4.fc19 will be updated ---> Package systemd-libs.x86_64 0:202-2.fc19 will be updated ---> Package systemd-libs.x86_64 0:202-3.fc19 will be an update ---> Package systemd-python.x86_64 0:200-4.fc19 will be updated ---> Package systemd-python.x86_64 0:202-2.fc19 will be updated ---> Package systemd-python.x86_64 0:202-3.fc19 will be an update ---> Package systemd-sysv.x86_64 0:200-4.fc19 will be updated ---> Package systemd-sysv.x86_64 0:202-2.fc19 will be updated ---> Package systemd-sysv.x86_64 0:202-3.fc19 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: libgudev1 x86_64 202-3.fc19 updates-testing 39 k systemd x86_64 202-3.fc19 updates-testing 2.4 M systemd-libs x86_64 202-3.fc19 updates-testing 142 k systemd-python x86_64 202-3.fc19 updates-testing 65 k systemd-sysv x86_64 202-3.fc19 updates-testing 27 k Transaction Summary ================================================================================ Upgrade 5 Packages Total size: 2.7 M Is this ok [y/N]: y Downloading packages: Running transaction check Running transaction test Transaction check error: file /usr/share/bash-completion/completions/udevadm from install of systemd-202-3.fc19.x86_64 conflicts with file from package bash-completion-1:2.0-3.fc19.noarch Error Summary ------------- [root@Dwarf myu]#
Une daily build de F19 mise à jour -> OK
Une Fedora 19 Alpha RC4 mise à jour -> NOK - Modifié
Comparaison très intéressante, merci chepioq !chepioq wrote:Si tu veux un timing à peu près correct, tu as la commande systemd-analyze time, chez moi sur F19 cela donne:
[dominique@host ~]$ systemd-analyze time
Startup finished in 1.077s (kernel) + 723ms (initrd) + 4.337s (userspace) = 6.137s
[dominique@host ~]$
C'est le temps depuis le démarrage de grub et l'arrivée sur ton bureau (kde chez moi)
==EDIT==
A titre de comparaison, la même commande sous F18 :
[dominique@chepioq ~]$ systemd-analyze time
Startup finished in 1255ms (kernel) + 1063ms (initrd) + 10342ms (userspace) = 12661ms
[dominique@chepioq ~]$
F19 est vraiment plus rapide, deux fois moins de temps au démarrage.
Je suis passé sur F19 après avoir du bidoullier à mort ma F18 pour optimiser le boot time et avoir grosso modo rendu ma boot sequence instable.
Ici, out of the box, c'est parfait !- Je la trouve très rapide, elle démarre en 5 secondes chez moi (SSD).
Pour les lenteurs souris, c'est peu-être du à un ancien noyau "DEBUG", met tout a jour vers le Noyau 3.9 RC7, ça a fait cesser les lenteurs chez moi.