l’empoté va se debrouiller
merci
[quote=“farka”]l’empoté va se debrouiller
merci[/quote] 
Faut pas le prendre mal, empoté est plutot gentil comme qualificatif: je dis juste ce que je pense, mais ce n’est pas pour te laisser tomber ni pour t’insulter, c’est juste une remarque moqueuse.
resolu en rajoutant dans
command_line {
hdparm -B 254 /dev/hda
}
ça fonctionne dès le demarrage .
Et, c’en est où ce truc là?
Ben rien de plus, les gens se sont aperçus que leur disque dur ne leur pétait pas à la figure, que ça marchait bien, que ça n’est pas spécifique à Debian ou Ubuntu mais que c’est juste une question de réglage, que WIndows pouvait connaître ce pbm mais qu’il était bcp plus facile de paramétrer ça sous linux.
Voilà
Un peu léger ta réponse. Tu n’as pas du lire toute la littérature disponible sur le sujet. Il est vrai qu’elle vient plus des forums relatifs à Ubuntu.
Bon, j’ai viré sous OpenSuse à cause de cela et je n’ai pas ce problème.
J’avais lu qu’une nouvelle version de acpi-support de Debian réglait le bug. Je pensais donc en savoir plus sur un forum Debian!
Ubuntu -qui par définition est censé être prte à l’emploi et sans trop de réglages- a réglé le pbm avec hdparm. J’ai parcouru le forum à ce sujet, (lis ce fil)
Suse n’a pas eu ce problème parce que Suse, moins adapté aux portables, n’intègre pas par défaut le paquet laptop permettant l’économie de batterie. Si sur ta Suse tu veux économiser ta batterie et protéger ton disque des chocs, tu auras ce problème de réglage. Si tu veux l’éviter, il faut à mon avis avoir des systèmes de fichiers ext2 sans journaux et donc sans écriture régulière sur le disque au repos.
La nouvelle version acpi-support modifies probablement légèrement les réglages par défaut lors de l’installation du paquet.
Pour corroborer les dires de fran.b, il faut bien comprendre que le problèmes peut ne pas venir de l’os mais du firmware du disque dur par exemple. Dans ce cas-là, bien évidemment, tous les os sont touchés, mais le problème se règle “très” facilement sous linux.
Oui, merci.
Mais tout ce que vous dites là est connu. je sais très bien faire fontionner une debian sur mon portable en paramétrant le laptop-mode de manière à stopper ce problème. Voir plus haut un truc que j’avais donné il y a quelques temps déjà.
Ce qui m’intéressait de savoir sur le problème, c’est si les développeurs avaient fait le nécessaire de manière à ce que le quidam qui installe sa Debian (ou Ubuntu) n’aie rien à faire pour supprimer le bug après son installtion. C’est quand même mieux que de découvrir après un temps d’utilisation que ton disque a été arrêté, redémarré un nombre de fois dément sans que tu n’en sache rien.
Je ne vois pas ce que cela a d’extraordinaire que de vouloir avoir un système qui fonctionne sans problème quand on vient d’installer une version stable. On est pas sous Windows, merde!
Je vois trop pourquoi tu t’énerves. 
Si le bug n’est pas un bug et vient du firmware du disque dur, celui-ci ayant été codé volontairement pour que le disque dur fonctionne de cette manière, les développeurs des différents OS n’ont pas, à priori, à combler ce bug qui n’en est pas forcément un. 
ce n’est peut-être pas un bug, mais si tu vas sur les packages Debian à acpi-support, ils appellent cela un bug. Et même un important bug.
Cela vient de chez Debian:
bugs.debian.org/cgi-bin/pkgrepor … t=unstable
Et ça, c’est pour la version Sid qui semble corriger le BUG.
C’est pour ça que je suis étonné que cela ne fasse pas plus l’objet de discussion sur les forums Debian.
Je ne suis pas énervé et à la limite en ce moment je m’en fous un peu ayant un iMac sous Macintosh et un portbale Dell sous Opensuse. Mais j’aurais voulu me remettre sous Debian pour mon portable.
Junichirô: Il est sensé être résolu, c’est marqué dans le lien que tu donnes.
Ca m’étonnait aussi que ce genre de bug traine, et pour ce que tu disais à propos des bugs externes à debian, de ce que j’ai vu, debian ne rejette jamais l’excuse d’un bug à l’exterieur, il le corrige, sauf si le concepteur du soft (externe à debian le plus souvent) est de trop mauvaise volonté ou le code plus maintenu et que le bug est prouvé incorrigible. C’est pas pour rien que debian empaquète tout même le noyau, les modules propriétaire, et les softs commerciaux les plus incontournables comme google earth ou flash. Les versions empaquetées, en plus d’être choisies, sont le plus souvent corrigées par rapport à la version d’origine (parfois amputées aussi pour des raisons de licence tt de même).
Ben oui! C’est ce que j’essaie de dire depuis le début. Ce que je voulais savoir c’est si les utilisateurs du forum en avaient une expérience et des informations en tant qu’utilisateurs. Avant de me relancer sous Debian car je n’arrive pas à me faire à OpenSuse. J’ai l’impression de ne pas comprendre comment mon ordinateur fonctionne alors que sous debian j’ai l’impression de pouvoir régler n’importe quel problème.
Chez moi, rien n’a changé, mais je ne crois pas que cela vienne de debian, étant donné que le portable est sous sid et à jour, donc le problème - sur mon ordi - semble venir plutôt d’un firmware “buggé”… (disque seagate momentus 5400.2 series - modèle ST9100823A).
À noter que la manipulation avec l’option -B fonctionne, elle.
Je crois que les disques Seagate ont eu pas mal de Pbs car sur les iMac en disposant (C’est pas le cas du mien) Apple s’est fendu d’une mise à jour Firmware sans aucune explication; ce sont les bidouilleurs qui ont trouvés le pourquoi de cette mise à jour. Il faut dire que certains avaient eu des pbs avec ces disques.
Bon, pour revenir à mon portable (Dell Inspiron) que je compte repasser sous Debian because of voir ci-dessus, j’espère qu’après l’installation en Etch je ne vais pas avoir trop de problèmes pour récupérer la version débuguées de acpi-support qui n’existe à ma connaissance que sous Leny et Sid.
Les éléments de correction pour désactiver l’APM dans la description du bug permettent de toutes facons de le corriger, au pire.
J’utilise Gutsy sur mon Asus F9s et pour palier ce problème en attendant que le “bug” soit corrigé, j’ai desactiver la gestion de l’energie du disque dur par l’acpi en modifiant le fichier /etc/laptop-mode/laptop-mode.conf
Bonjour,
D’apres tout ce que j’ai lu a propos de LCC, c’est qu’il faut gérer la gestion de l’alimentation en fonction de ces besoins & de l’utilisation de son Pc.
[quote][size=85]c’est juste une gestion particulière de l’économie de ton disque dur sur un portable, …
Si tu utilises ton portable tous les jours dans le metro/train/déplacement je te conseille de garder la configuration par défaut.
Si tu urilises ton portable comme beaucoup sur un bureau branché sur le secteur, alors désactive cette fonctionnalité, elle ne te sers à rien ! (hdparm -B 255)
L’idéal serait un script qui passe le hdparm en 255 au moment ou on branche le secteur … Je ne sais pas faire ![/size][/quote]
Pour ma part, j’utilise mon portable de cette maniere,
- (Train et Métro) deux fois par semaines, durant 4 à 5 heures .
- Au boulot (lundi -> vendredi) sur un bureau 8 à 9 heures.
- Ou sur les genoux le soir allongé sur mon Lit, 4 à 5 heures.
Someone can Help me ?
Junichirô : je ne sais pas ce qu’est SID ou Lenny. Un paquet, un noyau, … je n’ai que 2 semaines de Linux plein temps dans les mains, donc encore long à la détente …
Pour debian :
Etch : version stable
Lenny : version testing
Sid : version unstable
A ma connaissance le Load Cycle est adapté en fonction du branchement sur secteur ou non :
Sur secteur : hdparm -B 254 : ne parque pas les tetes pour pas “abimer” le disque
Sur battery : hdparm -B 128 : parque les tetes régulierement pour prévenir les chocs
Ceci est fixé pour Lenny et Sid à ma connaissance. (pour etch je ne sais pas car je ne l’utilise pas sur Laptop).