- Fedora-Fr
- À propos de Fedora-Fr
- Historique
- Statistiques
- Télécharger
- Obtenir Fedora
- Toutes les méthodes de téléchargement
- Support
- Aide sur IRC
- Forums
- Documentation
- Sous-projets
- Plateforme de blog
Dernière news : Clap de fin pour Fedora Linux 35 !
Merci beaucoup
Ça Boot !!
ACER C720P sur Fedora 29.
"Là où le maître échoue, que peut faire l'élève ? ... s'il a toujours obéi! ..."
Wagner
Hors ligne
de rien :)
tu verras avec le poste de Yannick ça va aller tout seul la configuration :)
(moi je cherche les mêmes infos pour debian parce que je suis plus un enfant du .deb que du .rpm :p)
Hors ligne
Après la réinstallation complète, j'ai eu beaucoup de crashs de Gnome. Cette mise à jour a rendu Gnome stable :
yum update --enablerepo=fedora --enablerepo=updates-testing mutter-wayland-3.10.1-2.fc20 gnome-shell-3.10.3-3.fc20 mutter-3.10.3-2.fc20
Le temps qu'elle arrive dans stable...
Hors ligne
j'ai fait une réinstallation pour ma part et lorsque le touchpad n'est pas encore installé, il ne réveille pas la machine ...
Il faut que je trouve un moyen de décharger le module qui fait marcher le touchpad lors de la mise en veille, et de le recharger au réveil !
Hors ligne
Mes aventures avec coreboot...(version Google)
LISEZ ATTENTIVEMENT CE MESSAGE JUSQU'A LA FIN SI VOUS TENTEZ CETTE MANIPULATION ET NOTEZ QUE JE DECONSEILLE FORTEMENT DE FAIRE PAREIL !
Carmy42 et moi avons changé la façon dont coreboot est configuré et nous avons maintenant notre coreboot qui s'affiche 1 seconde et passe automatiquement à seabios qui lance ensuite notre distribution. Il n'y a plus d'intervention manuelle de notre part (le fameux CTRL + L).
Je n'ai pas voulu en arriver là, mais Carmy42 avait un soucis, j'ai voulu l'aider. Il voulait une copie du coreboot et il s'est avéré qu'il fallait ouvrir la machine pour enlever une vis afin que coreboot ne soit plus protégé en écriture ceci afin d'avoir une copie complète. En effet, il semble acquis par ceux qui travaille sur ce genre de chose que même pour une simple copie il soit nécessaire d'obtenir le droit en écriture.
J'ai donc troué l'autocollant de garantie, dévissé le paneau arrière, enlevé la vis de protection de coreboot et j'ai booté la machine.
Là j'ai eu une surprise : coreboot avait, de lui-même, changé sa configuration : l'accès à seabios avait disparu. Ayant supprimé Chrome OS du SSD, je me suis retrouvé avec une machine qui ne me permettait plus que d'avoir l'écran blanc de coreboot ! Là, on commence à stresser un peu...
J'ai trouvé étrange que la configuration de coreboot change alors que je l'avait seulement mis en écriture. J'ai donc tenté de remettre la vis, mais cela n'a rien changé à la situation. Alors j'ai tenté la seule option que me restait : réinstaller Chrome OS et tout reprendre depuis la début à partir de Chrome OS qui allait très certainement effacer le SSD lors de son installation. Après tout j'avais une copie journalière de mon home, donc à part le temps perdu, je me suis dit que ça devrait bien se passer.
Google fournit un petit script pour Linux que j'ai utilisé à partir d'Ubuntu 12.04 pour me faire une clé USB. Il est bien fait : on lui donne le modèle exacte de notre machine (celui en bas de l'écran blanc de coreboot) et il vous fait la clé USB. Mais étrangement, ma clé etait très difficilement reconnu par coreboot : il la prenait 1 foir sur 10, peut-être moins et je devait tenter toutes sortes de choses (hard reset, dev mode, activer/désactiver secure boot...) pour que de temps en temps il boot dessus. Les rares fois où il la trouvait, l'installation semblait bien se passer mais au bout d'un moment cela se terminait toujours par "unexpected error". (erreur inatendue).
J'ai donc commencé à chercher de l'aide à droite, à gauche, et on m'a dit que certains modèles de clé USB étaient mal reconnus. En effet, je suis aller acheter deux autres modèles et une clé emtec a été parfaitement reconnue. J'avais bon espoir ! Cette fois, c'était la bonne ! Mais je suis retombé sur l'unexpected error...
A force de me gratter la tête j'ai remarqué que le système de réinstallation (recovery) mentionnait un log. Je suis allé voir dans la clé et il avait bien de fichiers de log ! J'y ait trouvé ceci :
Dans "recovery.log", sur l'une des nombreuses partitions de la clé, avant un ensemble de diagnostiques, il y avait cette erreur :
"Touch(/mnt/stateful_partition/.install_completed) FAILED
Starting firmware updater
(/tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate
--mode=recovery)
Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate
--mode=recovery
Starting Peppy firmware updater v4 (recovery)...
- Updater package: [Google_Peppy.4389.81.0 / peppy_v1.5.114-5d52788]
- Current system: [RO:Google_Peppy.4389.78.0 ,
ACT:Google_Peppy.4389.78.0 / peppy_v1.5.113-2d79820]
- Write protection: Hardware: ON, Software: Main=off EC=ON
Upgrading from early-MP firmware.
RW firmware update is not compatible with current RO firmware.
Starting full update...
ERROR: You need to first disable hardware write protection.
ERROR: Execution failed: ./updater4.sh (error code = 4)
Finished after 2 seconds.
Failed
Command: /tmp/install-mount-point/usr/sbin/chromeos-firmwareupdate
--mode=recovery - Exit Code 4
RO Firmware needs update, but is really marked RO. (error code: 4)
Rolling back update due to failure installing required firmware.
Successfully updated GPT with all settings to rollback.
PostInstall Failed"
Le système de réinstallation de Chrome OS exigeait une mise à jour de coreboot, mais j'avais remis la vis de protection en écriture en place dans l'espoir qu'un système identique à l'origine aiderait alors que c'était en fait bloquant pour la réinstallation ! J'ai, une fois encore, réouvert la machine, retiré la vis, pris la clé qui marche bien, et là j'ai enfin pu réinstaller Chrome OS. Avant, j'ai remis coreboot en configuration de base avec secureboot activé.
Au point où j'en étais, j'ai décidé de tenter configurer ce coreboot mis à jour pour qu'il boot automatiquement sur seabios, puis sur ma distribution.
On lance Chrome OS, on passe en console directement :
"ctrl" + "alt" + "F2(->)"
On se logue avec:
localhost login: chronos
On passe superutilisateur (attention le clavier est en qwerty) :
$ sudo bash
On active seabios :
# crossystem dev_boot_usb=1 dev_boot_legacy=1
On configure coreboot pour qu'il passe automatiquement en 1 seconde à seabios :
# set_gbb_flags.sh 0×489
Là j'ai éteint le machine, réouvert le paneau arrière et remis la vis en place, car je n'aime pas l'idée que coreboot soit en accès libre en écriture par root.
Puis on reboot en ayant mis la clé USB avec la distribution Linux.
Carmy42 et moi avons donc une version mise à jour de coreboot (il a cependant utilisé une procédure différente de mise à jour de coreboot, mais je pense que ça revient au même), cela marche avec celle-ci. Il est quasi-certain que coreboot détecte et garde une trace du fait qu'on ait déverouillé l'accès en écriture sur lui. On a un trou sur l'autocollant de garantie. Il est donc probable que la garantie ait sautée. Le procédé en lui-même n'est pas "naturel" car tout le monde semble s'accorder pour dire que la réinstallation de Chrome OS n'a pas besoin d'une mise à jour de coreboot, et à partir de là on vous regarde un peu comme un cas presque désespéré. Pourtant c'est une exigeance du système et on se retrouve surement dans les 1% de cas qui sont les moins testés alors qu'ils sont les plus dangereux car on réécrit le firmware de boot (coreboot). Enfin, il faut réinstaller complètement Fedora après.
POUR TOUTES CES RAISONS, JE VOUS DECONSEILLE DE LE FAIRE !
Dernière modification par Yannick@ekiga (08/02/2014 12:01:55)
Hors ligne
j'ai fait une réinstallation pour ma part et lorsque le touchpad n'est pas encore installé, il ne réveille pas la machine ...
Il faut que je trouve un moyen de décharger le module qui fait marcher le touchpad lors de la mise en veille, et de le recharger au réveil !
Eteint le touchpad :
$ synclient TouchpadOff=1
Active le touchpad :
$ synclient TouchpadOff=0
Attention j'ai une sorte de conflit avec syndaemon : il réactive le touchpad ; il faut donc tuer ce processus/ne plus l'utiliser si tu veux que ça marche.
D'ailleurs, c'est peut être la source du problème que j'ai quand je perds le "taptoclick"...
Modification non testée pour : /usr/lib/systemd/system-sleep/cros-sound-suspend.sh
EDIT: Correction d'une typo.
#!/bin/bash
case $1/$2 in
pre/*)
# Kill flash plugin as it prevent suspend
pgrep -f flashplayer | xargs kill >/dev/null 2>&1
# kill syndeamon as it may wakeup the machine unexpectedly
pgrep -f syndaemon | xargs kill >/dev/null 2>&1
# disable touchpad while asleep
synclient TouchpadOff=1
# Unbind ehci for preventing error
echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
# Unbind snd_hda_intel for sound
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind
;;
post/*)
# Bind ehci for preventing error
echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
# bind snd_hda_intel for sound
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind
# activate touchpad while wakingup
synclient TouchpadOff=0
# restart syndeamon
syndaemon -t -k -i 1 -d
;;
esac
Dernière modification par Yannick@ekiga (20/02/2014 01:27:21)
Hors ligne
Ajout de la configuration pour regarder la TV à partir d'une freebox avec totem dans le post #2
Hors ligne
Ajout d'un début de gestion automatique de la luminosité de l'écran. Pour cela il faudra relancer le script qui ajoute des modules au noyau Linux : il inclus désormais le module pour l'ALS.
Dernière modification par Yannick@ekiga (09/02/2014 03:26:54)
Hors ligne
@carmy42 : En effet c'est passé comme sur des roulettes
@Yannic@ekiga : Très bon tuto mais pour la tv freebox sur totem comment faire ... oh non c'est expliqué ... Merci pour ce travail détaillé et accessible.
Niveau fluidité et autonomie je confirme c'est très bien pour le prix. Côté clavier à part la toche power un peu trop proche du backspace, c'est très pratique.
@Tous :
Il me reste un petit problème ( bug ou mauvaise utilisation de ma part je ne sais) qui me semble-t-il n'a pas été évoqué :
Lorsque j'ai plusieurs fenetres ouvertes je n'arrive pas avec le doigt à prendre la main sur d'autres fenêtres que la première à avoir été ouverte : d'ailleur en cliquant (enfin touchant) une fenêtre, c'est toujours la première qui s'active. Au pad cela fonctionne. Des idées ?
Et encore merci.
Ah oui : Il faudra trouver un jolie autocollant pour cacher un villain logo circulaire jaune rouge vert : je vais de ce pas à la boutique.
Dernière modification par fedboreve (10/02/2014 11:00:15)
ACER C720P sur Fedora 29.
"Là où le maître échoue, que peut faire l'élève ? ... s'il a toujours obéi! ..."
Wagner
Hors ligne
@Yannic@ekiga : Très bon tuto mais pour la tv freebox sur totem comment faire ... oh non c'est expliqué ... Merci pour ce travail détaillé et accessible.
Niveau fluidité et autonomie je confirme c'est très bien pour le prix. Côté clavier à part la toche power un peu trop proche du backspace, c'est très pratique.
@Tous :
Il me reste un petit problème ( bug ou mauvaise utilisation de ma part je ne sais) qui me semble-t-il n'a pas été évoqué :
Lorsque j'ai plusieurs fenetres ouvertes je n'arrive pas avec le doigt à prendre la main sur d'autres fenêtres que la première à avoir été ouverte : d'ailleur en cliquant (enfin touchant) une fenêtre, c'est toujours la première qui s'active. Au pad cela fonctionne. Des idées ?Et encore merci.
Ah oui : Il faudra trouver un jolie autocollant pour cacher un villain logo circulaire jaune rouge vert : je vais de ce pas à la boutique.
Merci. N'hésite pas à contribuer des astuces.
Pour le clavier tu peux modifier le comportement de la touche power avec gnome-tweak-tool -> power. Je te conseille "nothing" ça évite les erreurs de manipulation.
Pour ce qui concerne la manipulation des fenêtres avec l'écran tactile c'est un défaut d'implémentation de gnome. J'ai vu 2 problèmes : toutes les fenêtres qui implémentent la nouvelle top bar de gnome qui contient des boutons ne peuvent être manipulées. Par contre celles qui ont une top bar normale (ancien modèle) sont manipulables (comme le terminal). Ensuite il y a un soucis de focus : je l'observe souvent avec le terminal. Il pique le focus à d'autre fenêtres quand on passe par le touchscreen.
Ce sont à mon avis des problèmes de Gnome qui n'ont pas encore été réglés par les devs.
On en a parlé ici : http://forums.fedora-fr.org/viewtopic.php?id=61449
Dernière modification par Yannick@ekiga (11/02/2014 01:04:07)
Hors ligne
Ajout du décodage vidéo assisté par le GPU. Merci à tous ceux que j'ai croisé aux rencontres Fedora hier à Paris. J'ai pu trouvé cela grâce à eux. Et bien d'autres choses...
Hors ligne
Ajout d'une configuration qui évite le tearing (image coupée dans les vidéos).
Hors ligne
Aujourd'hui il y a une mise à jour du kernel (noyau Linux) vers la version 3.13.3. Le script qui installe les modules pour le pavé et l'écran tactile ne marche plus avec cette mise à jour. Je cherche une correction au problème...
En attendant, le plus simple est de faire la mise à jour, car il y a d'autres paquets que le kernel, mais au moment du boot de choisir le kernel précédant.
Dernière modification par Yannick@ekiga (18/02/2014 11:23:19)
Hors ligne
J'ai tenté d'adapter le script pour le kernel 3.13 mais je bute sur un problème de compilation pour le module de l'écran tactile. C'est au-delà de mon niveau de compétence. Toute aide est la bienvenue
Bug report :
https://bugzilla.redhat.com/show_bug.cgi?id=1045821
J'ai mis à jour le premier post : il y a maintenant 2 scripts pour les modules du noyau. Le premier pour la série 3.13 du noyau sans l'écran tactile et un autre avec pour les séries 3.11 et 3.12.
EDIT : il semble aussi que la mise en veille soit cassée par le noyau 3.13...
Dernière modification par Yannick@ekiga (18/02/2014 14:49:57)
Hors ligne
Mise à jour du script pour les kernel >= 3.13 : l'écran tactile marche à nouveau (j'ai trouvé un fix).
EDIT : il semble que ça règle du même coup la mise en veille.
Dernière modification par Yannick@ekiga (18/02/2014 19:49:45)
Hors ligne
Bonjour,
un petit tips pour les utilisateurs de freebox qui veulent monter leur disque à l'allumage :
Créer un dossier pour monter la freebox :
su -c 'mkdir /mnt/freebox'
ajouter le code suivante à la fin du fichier /etc/rc.d/rc.local :
# On monte le disque si on est à la maison
sleep 60
iwconfig wlp1s0 > /tmp/testscript.txt
grep -i ESSID /tmp/testscript.txt
if [ "$?" = "0" ]; then #On agit que si l'on est à la maison
mount -t cifs //mafreebox.freebox.fr/Disque\ dur /mnt/freebox/ -o user=freebox,password=password,uid=1000,gid=1000,rw > /tmp/logdesavaut.txt
fi
où vous remplacez ESSID par l'essid de votre réseau WIFI.
Pour le connaitre vous pouvez lancer la commande
iwconfig
Je peux ainsi avec un petit cron sur la commande rsync enregistrer les modifications d'une journée de travail au bureau sans avoir rien d'autre à faire que d'allumer l'ordinateur à la maison.
ACER C720P sur Fedora 29.
"Là où le maître échoue, que peut faire l'élève ? ... s'il a toujours obéi! ..."
Wagner
Hors ligne
Bonjour,
un petit tips pour les utilisateurs de freebox qui veulent monter leur disque à l'allumage :
../..
Joli ! Je vais mettre ça dans le post #2. Merci ! Il faut que je regarde ce qu'on peut tirer de cette box. Jusqu'à quelques mois en arrière j'avais la V4, alors je n'ai pas fait trop gaffe à ce que la révolution apporte...
Hors ligne
une petite info qui pourra peut être intéresser quelqu'un ici : je vends mon c720, au choix avec Chrome OS ou Fedora 20.
je le laisse partir pour 180€ frais de port inclus.
Hors ligne
une petite info qui pourra peut être intéresser quelqu'un ici : je vends mon c720, au choix avec Chrome OS ou Fedora 20.
je le laisse partir pour 180€ frais de port inclus.
C'est hors sujet... Et tu pourrais préciser pourquoi tu le vends. À mon avis, il a un soucis matériel et est hors garanti. Je précise car je n'ai pas envie qu'un acheteur se ramène sur ce post pour râler...
Hors ligne
je le vends parce que j'ai besoin de faire rentrer de l'argent rapidement. Je vends aussi ma Vespa 125 si ça intéresse quelqu'un :p
Pour le souci matériel je ne pense pas ! Tout fonctionne correctement ! Sinon je l'aurai signalé bien sûr ! (si l'acheteur est dans le coin il peut bien sûr l'essayer pour dissiper tout malentendu)
Hors ligne
Bonjour,
Merci pour le tuto tres detaillé et efficace.
Concernant la mise en veille, j'ai eu le meme probleme que carmy42, à savoir redémarrages intempestifs une fois en veille, écran replié.
Le souci provient effectivement du trackpad, mais la solution proposée sur le forum (synclient) en fonctionne pas. En effet, le trackpad sur mon C720 (tous ?) n'est pas un synaptics, mais un Cypress (pilote cyapa).
J'ai essayé de le desactiver avec xinput pendant la mise en veille, sans succes. La technique unbind ne fonctionne pas non plus, soit parce que je n'ai pas trouvé le bon identifiant, soit parce que le trackpad semble connecté au bus i2c et pas pci.
La solution que j'utilise actuellement consiste simplement à decharger/recharger le module cyapa :
#/usr/lib/systemd/system-sleep/cros-sound-suspend.sh
#!/bin/bash
case $1/$2 in
pre/*)
# Kill flash plugin as it prevent suspend
pgrep -f flashplayer | xargs kill >/dev/null 2>&1
# Touchpad
#xinput --set-prop 12 "Device Enabled" 0
rmmod cyapa
# Unbind ehci for preventing error
echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
# Unbind snd_hda_intel for sound
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/unbind
;;
post/*)
# Touchpad on
#xinput --set-prop 12 "Device Enabled" 1
modprobe cyapa
# Bind ehci for preventing error
echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
# bind snd_hda_intel for sound
echo -n "0000:00:1b.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind
echo -n "0000:00:03.0" | tee /sys/bus/pci/drivers/snd_hda_intel/bind
;;
esac
[root@c720 cyapa]#
Hors ligne
C'est bien le C720 que vous avez et non le C720P avec écran tactile ? Si c'est le cas je me demande si le soucis ne vient pas de mon script qui inclus le pilote pour le touchscreen. Il se trouve que lorsque le noyau 3.13 est sorti, je n'ai pas pu compiler le pilote pour l'écran et le portable sortait tout de suite de veille.
Tu as essayé de voir si ce n'est pas lié à ce module :
$ lsmod | grep atmel_mxt_ts
Et pour le virer :
# rmmod atmel_mxt_ts
Hors ligne
Bonsoir,
C'est effectivement un C720P avec la dalle tactile.
J'ai testé en déchargeant le module atmel_mxt_ts, le résultat est assez surprenant.
Une fois le module déchargé :
- si veille avec le bouton power -> reprise OK.
- si veille en rabattant l'écran : pas de mise en veille, système complètement figé, aucune autre console dispo, hard reset nécessaire (garder le doigt 30s sur le bouton power).
J'arrive à reproduire relativement fréquemment le problème de réactivation en appuyant, écran fermé, sur la zone au dessus du trackpad, alors que cela ne se produit pas en appuyant à gauche ou à droite du trackpad, là ou la hauteur du boitier est similaire et est aussi en contact avec l'écran tactile.
Hors ligne
Il y avait une typo dans le post #56. J'ai du mal à croire qu'on ait 2 pavés différents...
Essaye ceci :
$ pgrep -f syndaemon | xargs kill >/dev/null 2>&1
$ synclient TouchpadOff=1
Ça devrait désactiver le pavé tactile. Si ça ne marche pas vérifie que tu n'as pas un processus "syndaemon" qui tourne toujours (je l'avais en double...)
$ synclient TouchpadOff=0
Et ceci pour le réactiver.
Dernière modification par Yannick@ekiga (20/02/2014 01:31:28)
Hors ligne
Salut,
J'ai testé avec les modifications indiquées.
Bilan :
- effectivement, ça désactive bien le trackpad, je ne peux plus déplacer le pointeur, et cet état perdure lors de la sortie de mise en veille (en testant manuellement, avec le script il se reactive bien).
- mais hélas, ça ne régle pas le probleme : je desactive manuellement le trackpad avec cette méthode, je ferme l'écran, j'appuie un peu au dessus, le portable se réactive, j'ouvre l'écran, le trackpad est toujours coupé (ça ne se produit pas avec le déchargement du noyau, j'ai longuement testé...). Peut-etre qu'avec TouchpadOff, ça ne coupe pas toutes les fonctionnalités.
Egalement, j'ai re-vérifié, je n'ai aucune trace d'un hardware synaptics, ni dans dmesg/journalctl, ni dans lspci/lsusb/xinput.
[root@c720 jideel]# dmesg |grep -i track
[ 4.558304] input: Cypress APA Trackpad (cyapa) as /devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input13
Hors ligne