Suite à la mise à jour du noyau de ce soir, j'ai eu une erreur lors du script pour réinstaller les modules pour le pavé/écran/zram :

Cannot retrieve metalink for repository: fedora-source/20/x86_64. Please verify its path and try again

Ceci a permis de résoudre ce soucis :

$ su -c 'yum clean all'

Salut carmy42,

Tu devrais pouvoir tester ta théorie avec le fichier :
/etc/X11/xorg.conf.d/50-cros-touchpad.conf

Essaye de voir comment le configurer pour désactiver le touchpad et ainsi vérifier si le problème vient de là. Je ne peux pas trop t'aider pour le moment, j'ai malheureusement sorti un tourne-vis et depuis seabios n'est plus accessible. Résultat : je n'ai plus accès à Fedora...

Moralité, gare au tourne-vis !

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 !

carmy42 wrote: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

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.

fedboreve wrote:@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