#1 Le 15/09/2006, à 21:27
- mesmento
une idée de solution aux récents problèmes de maj
Bon voici un scripts pour pallier aux récents problèmes du serveur X sous Ubuntu
Ou plutôt une idée de script à valider.
#!bin/sh -
# cherche si le serveur X s'est arrêté suite à une erreur
# Si oui, lance un serveur X sans optimisation et lance gdm/kdm
# Sinon ne fais rien
if dmesg | grep -F la_ligne_qui_indique_une_erreur_et_arrêt_de_xorg
then
sudo Xorg -config /path/to/Xorg_2 && sudo $variable_pointant_vers_gdm/kdm/...
fiEnsuite intégrer le script au démarrage (EST-CE JUSTE ?).
update-rc.d script.sh start 20 5À NE PAS UTILISER, c'est juste une idée de script.
P.S. : le titre est mensongé, sous Windows si le serveur graphique plante on est dans le bousin. Dans la plupart des cas ce n'est pas le cas sous Linux. Quelques connaissancesdu systèmes permettent de s'en sortir assez rapidement. Ce script n'a pour seul but qu'aider les gens qui se sentirait pedu devant une invite de commande.
J'ai changé le titre pour faire réagir un peu plus 
Dernière modification par mesmento (Le 16/09/2006, à 00:43)
Hors ligne
#2 Le 16/09/2006, à 00:13
- mesmento
Re : une idée de solution aux récents problèmes de maj
up.
ça n'intéresse vraiment personne ?
Hors ligne
#3 Le 16/09/2006, à 01:21
- coffee
Re : une idée de solution aux récents problèmes de maj
C'est pas que ça interesse personne mais:
1) c'est un bouche trou qui n'évite pas le pb
2) Si c'est xorg qui merde, ça ne fait rien (ou du moins si c'est indépendant de fichiers de conf)
L'idée de base est interessante mais je pense qu'un case bien trouvé serait mieux.
Prenons un exemple, on a un bug dans la maj de HAL, il ne détecte plus très bien les cartes graphiques ce qui fait que xorg ne voit pas d'écran donc il bug, on a changé de fichier de configuration mais rien ne va se passer.
Personnellement je pense que la solution ne doit pas être trouvé en aval mais plus ou moins en amont. Par exemple, on pourrait télécharger les paquets et s'ils ont une valeur dans le .deb qui dit "paquet non testé" afficher en gros que c'est un paquet de test ou alors un dépot de paquet à tester (un unstable-like pour le dépôt main) qui dure un jour et s'il n'y a aucun retour, on le met sur les dépôts courants.
Toutefois, celà peut interesser des gens mais je pense que cette idée n'est qu'un bouche trou et non une solution.
Nom d'un tupperware habillé en streetware mangeant de la confiture de pouère et qui se dite où est-ce que je suis ouère !
Tiens mon blog
Les blagues sous forme de fausses aides sont susceptible de ban (ex: rm)
Hors ligne
#4 Le 16/09/2006, à 01:36
- mesmento
Re : une idée de solution aux récents problèmes de maj
Là je suis entièrement d'accord avec toi, c'est un bouche trou complet.
Effectivement. Le problème de cette idée de script c'est qu'elle ne concerne qu'une infime partie des problèmes possibles.
Une solution plus générale serait plus intéressante.
Ton idée est très bonne. Si j'ai bien compris, tu émets l'idée qu'un paquet est marqué "testé" si le retour d'une somme importante d'utilisateurs est bon ?
À moins que tu te situes au niveau du mainteneur lui-même mais dans ce cas, quelque chose me chiffone, cela signifie-t-il que les paquets de mises-à-jour sont proposés sans avoir forcément été testés auparavant ?
Finalement mettre en place un système de test au niveau mainteneur+utilisateur serait pas mal.
Test au niveau mainteneur, maj des dépôts. paquet signé "test mainteneur réussi" ou autre. Puis batterie de test des utilisateurs sur une durée limitée. Retour d'expérience au mainteneur. Correction des bugs si nécessaire. Et enfin paquet signé "testé".
Peut-être un peu lourd. Je ne me rend pas compte.
C'était cela ton idée ?
Dernière modification par mesmento (Le 16/09/2006, à 01:37)
Hors ligne
#5 Le 16/09/2006, à 01:45
- bartholomeus
Re : une idée de solution aux récents problèmes de maj
Quelqu'un (je ne parle pas de Quelqu'un) avait proposé un jour la création d'un groupe restreint de Kamikazes qui aurait l'honneur de recevoir 24 ou 48 heures avant le commun des mortels les mises à jour. Ce groupe doit bien sur être constitué de personnes maitrisant linux et capables de renvoyer des rapports de bugs clairs et intélligibles.
C'est ce que vous proposez je crois. L'idée est très interreassante car statistiquement il y aurait un retour de toutes les configs possibles et immaginables (enfin presque) et ça assurerait une sécurité 99 % pour les utilisateurs basiques ( comme moi).
La solution serait peut-être là non ?
Dernière modification par bartholomeus (Le 16/09/2006, à 02:01)
Hors ligne
#6 Le 17/09/2006, à 08:59
- malev
Re : une idée de solution aux récents problèmes de maj
Bonjour,
je ne suis pas développeur, jsute utilisateur, je regarde dans ce forum par curiosité, etje vois cette histoire qui m'intéresser, voici donc ce que j'avais imaginé.
Au lieu d'un groupe kamiakaze, ne serait-il pas possible de proposer un délai dans les mises à jour ? Je veux dire ceci : à l'install on clique ou non sur une option : les mises à jour seront signalées après un délai d'attente de disons 3 jours, option recommandée pour les postes "en production".
Imaginons maintenant le bug xorg. J=1 : ça plante des milliers, dizaines de milliers de machines de particuliers, habitués à mettre les mains dans le camboui... les paquets sont retirés. Pour ceux qui ont choisi le délai, en production : rien ne se passe, le problème a été résolu en deux jours, c'est ça ? les paquets sont remplacés j 3: mise à jour pour la prod : pas de bug. s'il faut plus de 3 jours pour corrier : pas de maj pour les postes en prod.
autrement, c"est sûr qu'il faudrait une gestion des plantages. après une maj qui plante, proposer un retour à la version précédente.