[Gnome] Problème depuis màj 3.6 (temporairement résolu)

[patou355]

Bon ok ça me fera les pieds, je vais follower sur twitter et G+

[piR25]

Bon c'est bon suffisait d'un chown, j'ai du faire un startx en root pendant mes déboires... Donc tout est revenu dans l'ordre
Sauf l'histoire de ce que j'avais dans mon rc.local. Cela me permettait de couper ma arte ATI avec vga_switcheroo. J'avais deux lignes:

Code : Tout sélectionner

modprobe radeon

que j'ai placé dans modprobe.d donc pas de problème.

Code : Tout sélectionner

echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

et pour cette ligne je viens de remarquer que vga_switcheroo a disparu du répertoire. Est-ce que le kernel gère automatiquement le passage maintenant où la solution a tout simplement disparu ?

EDIT: J'ai vraiment une gestion de l'alimentation désastreuse là

[piR25]

Up! Personne ne sait ?

[FoolEcho]

Aucune idée. Faudrait voir dans le wiki ou le forum anglophone s'il y a des infos/mises à jour là-dessus.

[piR25]

Le problème c'est que vga_switcheroo sur le wiki anglais parle du dossier vga_switcheroo que je ne trouve plus (il y était il y a quelques temps), je vais essayer de trouver des informations mais il y en a assez peu concernant le switch entre cartes graphiques.

[sushi]

... ou en français (... ce qui, accessoirement, peut nous permettre de savoir si ce guide est compréhensible): http://wiki.archlinux.fr/Systemd#Migrat ... nitscripts ( mais bon, on sait que ce qui est bon pour le .org ne l'est pas pour le .fr -- private joke ).

Je viens de tester la migration avec le wiki francais.

Premier point, l'article commence par une section configuration. Quid de l'installation ? Perturbant de devoir "commencer" par la fin de l'article.

Donc je suis les instructions à partir de " Migration depuis initscripts ", dans l'ordre, en choisissant " Supprimer sysvinit ".
Arrivé à " Veillez également à lancer les services que vous utilisiez. Le fonctionnement des services est le suivant [...]", ca bloque.
Résultat de la commande systemctl enable leNomDuService (j'ai bien remplacé avec des services valides)

Code : Tout sélectionner

Operation failed: Invalid argument

Je fais ca:

Code : Tout sélectionner

systemctl 
Failed to get D-Bus connection: No connection to service manager.

Après visite sur le wiki anglais (qui lui a le bon sens de commencer par l'installation), je lis ça :

Pure systemd installation

Finally, it is possible to remove initscripts and sysvinit entirely and use only systemd.

Follow the instructions for a mixed systemd/initscripts installation.

Qui implique

Follow the instructions for a mixed systemd/sysvinit/initscripts installation.

Add init=/usr/lib/systemd/systemd to the kernel parameters in your bootloader.
Reboot.

Là où le wiki fr m'a fait croire que je pouvais passer direct à la configuration sans rc.conf & co, le wiki anglais me dit de bien passer par toute les étapes. Ce qui est bon pour le .org ne le serait donc pas pour le .fr ?
Dans l'état, je ne trouve pas l'article fr satisfaisant.
Comme je lis l'anglais, je ne me suis pas trop torturé le cerveau non plus. J'aurai probablement commencé directement avec l'article anglais si je n'avais pas lu le message cité plus haut.

Mes 2cts...

[Ichigo-Roku]

Regarde dans la section "Garder sysvinit" au tout début.

[FoolEcho]

J'en prends note...
Selon moi, il manque «simplement» le fait de redémarrer (ce qui sera corrigé vite fait)... plus explicitement que le titre «démarrer systemd» apparemment.

Je m'explique:

Premier point, l'article commence par une section configuration. Quid de l'installation ? Perturbant de devoir "commencer" par la fin de l'article.

À moins de ne pas avoir mis à jour Arch depuis un très long moment (juin 2012 d'après mon log), systemd est installé puisqu'il a remplacé udev... ou devrait l'être en tous cas, compte tenu de l'annonce officielle: http://archlinux.fr/news/systemd-tools-remplace-udev (on peut dire que non et éventuellement le préciser, mais bon... ceux qui restent sur des versions non à jour volontairement le savent... ou sont censés le savoir, on ne peut pas garder tous les éléments ad vitam eternam lorsqu'ils ne sont plus officiellement supportés -- tu pourras dire que je suis de mauvaise foi ).

Et la partie que je t'ai pointé est spécifique à la migration d'une Arch «ancienne» vers systemd puisque toute nouvelle installation l'a de base désormais (et c'est clairement indiqué au début du wiki). Le laisser au début peut gêner ceux qui justement n'ont jamais eu à faire la transition (c'est assez subjectif, mais c'est pareil, cette partie finira aux oubliettes à terme... ou peut-être ailleurs pour les archi-retardataires -- on commencera à être fixé au cours de janvier ).

[sushi]

Effectivement, il s'agit juste d'un problème d'explicitation. Pour l'utilisateur lambda un peu mauvais, ca fait vite une grosse différence. Entre une transition facile et une situation de stress, il y a souvent peu de chose. C'est pour ca que je le signale. Tu avais demandé un retour, le voila

Concernant ma remarque sur l'ordre des sections : ce n'est évidement pas un vrai problème. Mais c'est juste un peu perturbant. Je me suis déjà fait ce genre de réflexion sur d'autres articles. Je me doute que le choix de la structure d'un article n'est pas toujours évident... Dans ce cas précis, je trouve le wiki anglais plus efficace. L'inverse est souvent vrai aussi. Dans tout les cas c'est subjectif.

Sur les parties "anciennes", je pense qu'il faut les conserver un peu. Je viens de constater que des articles du wiki anglais ne font plus du tout mention des informations pré-systemd. C'est peut-être un poil prématuré considérant qu'il s'agit d'une période de transition.

Je fais parti des personnes qui n'avaient pas mis a jour depuis juin 2012. Dans mon cas, justement parce que je savais qu'un changement majeur allait intervenir : config système me convenant, pas le temps / motivation pour me pencher dessus, j'ai repoussé au plus tard.
Je sais d'expérience que j'ai moins de chance de perdre du temps en attendant le plus possible, tout simplement parce que la qualité des infos disponibles ne sera que meilleure, et que les cas de figure où l'on se retrouve avec un système planté seront pour la plupart résolus.

A part ce mini blocage qui m'a fait perdre 5min, la transition c'est passé en douceur : utilisateur content

[piR25]

J'ai une dernière question. Comment je fais pour exécuter une ligne de shell au démarrage (par exemple celles qui étaient dans rc.local), je crée un service mais comment ?!

EDIT: c'est à ne rien comprendre, après une mise en veille, le système gère l'alim beaucoup mieux (je ne sais pas comment, je pense qu'il baisse la freq de la carte) et j'ai 5h de'autonomie au lieu de 2h... (je suis toujours loin de mes 7h habituelles)

[piR25]

Bon problème partiellement réglé. Pour ceux que ça intéresse:

J'ai utilisé acpi_call, dispo sur AUR:
https://aur.archlinux.org/packages.php?ID=39470

Attention, acpi_call nécessite linux-headers et git.

Suffit ensuite d'extraire la tarball, de faire un makepkg puis de rajouter dans rc.local les lignes suivantes:

Code : Tout sélectionner

insmod <chemin>/src/acpi_call-build/acpi_call.ko
chmod u+x test_off.sh
./test_off.sh

Donc problème partiellement reglé puisqu'obligé d'utiliser le service qui lit rc.local.