Reprise du message précédent :
/etc/conf.d/cpufreq
 
Puis rajoute cpufreq dans les DAEMONS du rc.conf

Pour le rc.sysinit si vous cherchez un peu plus de sûreté que ce que j'ai mis au-dessus un petit "wait" à la fin du script s'assurera que toutes les tâches soient finies avant de passer au level 3 ou 5.
 
Un autre point important que j'ai oublié c'est qu'il y a une grosse différence entre mettre {x,k,g}dm dans DAEMONS et le mettre dans /etc/inittab. En effet lorsqu'il est dans inittab il commence à se lancer en même temps que rc.multi donc ça fait gagner du temps. Le désavantage c'est que si rc.multi est trop long à s'exécuter on peut se retrouver avec un timeout de xorg, donc faut faire attention à ce que l'on met dans rc.local … Si quelqu'un sait comment modifier/enlever ce timeout ça m'intéresse beaucoup.

Changaco, merci pour ces astuces, j'y jetterai un oeil.
 
Sinon, toujours avec mes problèmes de stabilité de ma distrib. Avant hier, après avoir viré mon profil pour repartir d'un vide, j'avais eu un crash de aspell, qu'il avait fallu que je réinstalle. Aujourd'hui, deuxième fois que je lance l'ordi et que je dois réinstaller openoffice-base pour cause de corruption de fichier. Faut vraiment que je trouve comment résoudre ces problèmes, en identifiant et mettant en évidence de manière irréfutable la pièce qui pose problème puisque tout est sous garantie sur mon laptop, parce que là ça commence à doucement me faire chier.

J'ai testé rapidement quick-init et ça fonctionne pas chez moi. La vérification des partitions échoue ce qui est logique étant donné que les partitions ne sont pas encore détectés quand il est lancé. C'est le risque quand on met le "udevadm" plus tard.

Nouveau boot tout à l'heure : problème sur le fsck automatique sur sda1, il a fallu que je fasse un fsck manuellement pour rattraper un inode qui avait pété. Ce serait mon contrôleur SATA qui serait naze ? Comment le tester ?

Tu peux peut être créer un topik pour ton soucis, tu aurais je pense plus de réponse
 
Je suis dans l'incapacité de t'aider en tout cas. Le seul "soucis" que j'ai c'est KDE qui se ramolit avec le temps.

ueahs 5 jours que j ai pas fait d update
187mo à faire  

Kortex@HFR : serait-ce dû au formatage du SSD ? (alignement, toussa... j'ai pas suivi vos évolutions ces 10 derniers jours, je me trompe peut-être, mais bon, c'est ce qui me vient en tête là, immédiatement).

Sinon, moi aussi, de temps en temps (1 à 2 fois par mois ? plus souvent ?), j'ai le crash de KDE à froid qui me renvoie sur KDM.
Je m'en suis accomodé, ça arrive pas souvent.
Mais si tu as la solution, je prends !

Je ne pense pas que le SSD soit concerné, j'avais le problème avec mon HDD précédent.

(la flemme de tout relire : ) as-tu redémarré avec un profil de firefox neuf ?

Kortex,  démarre avec UBCD sur ton pc, et fais la série des stresstest
CPU / RAM / HDD

Oui, ça j'ai fait, ça n'a rien donné.

Je vais essayer, mais les tests HDD avec le SSD, ça me fait un peu chier, j'ai peur de le salir, et tant que je ne sais pas avec certitude si le TRIM est réellement fonctionnel sous Linux, je préfère éviter. Mais je peux essayer les tests CPU/RAM et si possible CG aussi. Sait-on aussi, peut être que le chip graphique merdoie aussi.

bah refous le hdd en attendant

Une mini-review de Chakra, la distribution user-friendly bâtie sur Arch et KDE4 :
http://ubunblox.servhome.org/petit [...] hakra.html

Chakra est à Arch ce que Ubuntu est à Debian. J'espère seulement que ça ne prendra pas la forme qu'à pris Ubuntu, mais je n'ai que peu de crainte, Arch étant une base solide et Chakra ne rencontrant pas le problème lié au release comme Ubuntu peut y être confronté.

Certes... J'avais la flemme de tout démonter (oui, je sais, je suis très flemmard). Mais bon, j'ai quand même remis l'autre HDD dedans, et c'est parti pour les tests.

Là, c'est StressCPU qui tourne, on verra bien ce que ça dit. D'ailleurs à partir de quand je peux considérer que je peux passer au test suivant et que le précédent à réussi ?

Je dois exécuter quel test pour tester les I/O et le HDD ? J'ai jamais trop fait, je ne connais pas ces outils... Merci

EDIT : j'ai remis mon ancien HDD dans le portable, booté sur la distrib et exécuté 1h15 de stress avec la commande suivante :
stress -v --cpu 8 --io 4 --vm-bytes 128M --timeout 10000s

Aucun erreur à déplorer, mais le HDD n'a pas tourné, donc je ne suis pas sur que ce test soit réellement efficace pour mettre en évidence un problème lié au contrôleur de disque. Par contre, cela semble exclure tout le reste non ?

Par contre, c'est bien ce test, ça permet de se rendre compte à quel point un SSD accélère la machine J'ai vraiment eu du mal avec le HDD, qu'est-ce que c'est lent pour tout...

Peut-on rester on-topic sur arch svp?
 
Notamment Kortex... J'ai l'impression de lire ton blog
Tu en es a 5 ou 6 posts sur cette page et aucun qui soit en rapport avec arch: Kortex a des problemes avec Mozilla, Kortex a des problemes avec son disque dur, Kortex a un SSD et il est trop trop content, Kortex aime pas ubuntu...
Merci.

fl0ups : je te comprends, mais bon, tu peux aussi le lui dire plus gentiment...  
 
(et tout le monde sait qu'en cas de gros pb avec Arch, il faut aller sur notre forum )  

fl0ups est gentil je pense, je vois pas d'agressivité dans son post

Ah, c'est donc sur toi qu'il faut taper quand les mirroirs marchent pas

Effectivement, je viens de le relire, et je nuance un peu mon intervention... je voulais juste éviter un conflit (idiot) entre archers...

ah non, je dis "notre", car j'y participe, c'est tout !  

Pas vraiment dans le sujet désolé mais j'ai récemment mis mon profil Firefox en ramfs et maintenant j'ai des crashs de Firefox de plus en plus fréquents, toujours sur des événements (notamment rafraîchissement de page, que ce soit par souris ou par clavier). Je vais donc supprimer le ramfs pour en avoir le cœur net.

memtest ? je dirais ça cache quelquechose

aucun soucis pour ma part avec Firefox en tmpfs...

Je tourne sous Arch, j'ai des problèmes sous cette distrib (et je ne dis pas que ça vient de la distrib pour autant), je pensais pas mal faire en postant ici, je ne le ferai plus à part pour parler d'Arch directement. Quand au ton de ton post, je ne dirai rien...

Et tu as raison    
 
Sinon, j'ai trouvé la solution miracle pour mon touchpad non géré par synaptics, complètement au hasard :
http://forums.fedora-fr.org/viewtopic.php?pid=271490

Après bidouillage, je boot en ... 17 secondes avec mon disque dur 5200rpm  
http://img245.imageshack.us/img245/9651/bootchartg.png
Est-ce qu'on peut faire quelque chose pour hwclock, ça a l'air de tout bloquer  

moi j'avais ça sans aucune bidouille

C'est surement optimisable mais je m'en fous un peu, sachant qu'il reboot une fois par semaine

j ai une question con
dans le rc.conf
Lorsque qu on démarre les démons, par ex : sshd hal alsa
le fait de mettre du @alsa passe le démon en background
ok
 
Mais ca sert à quoi de le passer en background ? lesquels doit on privilégier?

Ca sert à laisser continuer la séquence de démarrage des démons sans attendre que le précédent ait fini de démarrer. C'est utile par exemple si un démon est autonome et n'est pas un prérequis d'un autre, ou si un démon doit attendre un événement particulier avant de finir son démarrage, pour gagner du temps.
Je dirai que sorti de HAL, pour une utilisation standard, presque tout le reste peut être démarré en background, puisque les démons ne sont pas dépendants les uns des autres. Après, en fonction de ton utilisation de ta machine (présence de démons particulier), il faut faire attention à ne pas pas faire quelque chose qui va au mieux ralentir le démarrage, au pire le bloquer.

oki je comprend mieux
comme le démon network qui me bloque je démarrage 10s si pas de cable ...
   

Par exemple oui, il est bien pénible celui-ci. Après, en démon de gestion du réseau, je te conseille d'utiliser wicd en lieu et place de network, c'est nettement plus complet.

Ou networkmanager.

wicd + ip fixe !!! rapide et efficace !

Il est à moitié bizarre ton boot. Normalement il y a deux hwclock, le premier il faut le laisser et le deuxième on peut le mettre en parallèle.

je l utilise déja depuis un bon moment maintenant
d ailleurs mon arch n a connu que ca  

Bon ca fait longtemps que j'ai un bug qui me fait royalement chier :  
 
J'ai un XPS1330, avec lecteur d'empreinte, et donc un module d'autentification en plus dans pam(thinkfinger) . Seulement ca fait qques mois que des que je veux passer en root ( avec la commande su ), que une fois sur deux il me sort tout simplement un segmentation fault ... Voir un stack trace horrible. De plus il prend toujours au moins 20 secondes pour réaliser l'authentification. Je sais pas trop si c'est lié à Thinkfinger, ou bien si c'est lié à su. Faudrait que je fasse des test, mais si avant, qqun peut me dire simplement à quoi c'est du, ca me sauverait le temps perdu en chipotage...

Comment fait-on passer pacman par un proxy HTTP avec authentification ? Je trouve bien comment exporter des variables d'environnement pour un proxy normal, mais authentifié, rien...

Edit : c'est bon, j'ai trouvé, c'est dans la syntaxe de l'export.

J ai un M1530
Pour le pam sous ubuntu ca marchait plutot pas mal
mais devant le peu d interet de la chose j ai préféré ne pas le mettre sous arch
c est un peu hasardeux comme config, on trouve plusieurs config possible sur le net, c est chiant faut bidouiller dans tous les sens
donc sans c est bien  

 
Bah maintenant je l'utilise presque plus vu que il foire, mais avant j'étais devenu totalement accro du lecteur d'empreinte   , c'était parfait, authentification en deux seconde en passant son doigt dessus, et vu le nombre de fois que je passe en root, c'était toujours ca de gagné.
 
Mais c'est clair que je me souviens que tout ca c'était du beau chipotage...
Enfin bon je vais essayer de regarder quel module foire exactement, et corriger tout cela.
 
Tiens sinon, il y a des développeurs ArchLinux ici ? Ou bien des gars qui participe à AUR .?

Mué, trèèès vite fait sur aur