Wampyr

  • 16 oct. 2013
  • Inscrit 29 oct. 2010
  • 0 meilleure réponse
  • Petit nouveau Adepte du forum Rédacteur potentiel
  • Si c'est du Windows RT, il faudra tester avec une Fedora ARM et pas x86 / x86_64
  • 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
    
  • 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...
    cat /var/log/messages | tail
    [root@Dwarf myu]# cat /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 ?
  • Merci pour l'info Heldwin ! 🙂
  • J'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.
  • Merci pour les pistes,

    Alors, voici les résultats :
    [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"
    
    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.
    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"
    
  • 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 :
    [root@Dwarf azerty]# cat /etc/sysconfig/keyboard 
    KEYTABLE="be-latin1"
    MODEL="pc105"
    LAYOUT="be"
    
    /etc/defaut/keyboard modifié, rien n'y fait ...
    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
    
    
    Quelqu'un aurait une idée ?
  • Apparement bcmwl-kernel-source est le pendant Ubuntu (du code source apparemment, questions de licences, redistributions, etc...) du paquet kmod-wl wl-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
  • 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 ?
  • 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.
  • 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
  • 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 :
    [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]# 
    
    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) :

    Une daily build de F19 mise à jour -> OK
    Une Fedora 19 Alpha RC4 mise à jour -> NOK
  • 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.
    Comparaison très intéressante, merci chepioq !

    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.