Bonjour,

Je viens d'installer la fedora core 3 à partir d'un dvd dont j'ai téléchargé l'image. Je n'arrive pas à mettre à jour mon système, up2date part en carafe et bloque sur la résolution des dépendances, trouvant que les anciens packages et les nouveaux sont les mêmes... et si je lance yum update, ensuite je n'arrive plus à démarrer la fedora, elle plante au lancement juste après la phase de détection du matériel. Ce n'est pas la première fois que j'ai ce problème, je l'ai eu sur d'autres machines et des collègues ont planté leur tête de réseau du boulot car ils avaient activé la mise à jour auto... Bref, je suis surpris qu'un problème aussi flagrant et aussi récurrent soit en place depuis des mois.

Cordialement,

Guillaume
crystalizer a écrit:
Je viens d'installer la fedora core 3 à partir d'un dvd dont j'ai téléchargé l'image. Je n'arrive pas à mettre à jour mon système, up2date part en carafe et bloque sur la résolution des dépendances, trouvant que les anciens packages et les nouveaux sont les mêmes...
On suppose donc que le système a pu être lancé correctement. Le pb interviendrait après l'implantation.
et si je lance yum update, ensuite je n'arrive plus à démarrer la fedora, elle plante au lancement juste après la phase de détection du matériel.
Quels sont les dépôts déclarés?

Attention aux mélanges des genres (cette question a de nombreuses fois été abordée; en cas d'utilisation du yum.conf des tutoriaux, bien lire les réserves et s'en tenir à core, updates et livna dans un premier temps).

Le plantage après la phase de détection du matériel est un grand classique: il intervient généralement lors du chargement des modules.

Il faut dès lors sérier les pbs ...

On démarrera en level 3 (sans activation du serveur graphique donc). Si le démarrage est réalisé sans difficulté, on en déduira que le pb naît du serveur graphique.

Deux cas généraux sont possibles:

1- pb de support de la carte graphique (Nvidia par exemple; voir les tutoriaux). Il faut alors installer les pilotes ad hoc.

2- pb de support de rhgb (Red Hat Graphic Boot). Pour réduire ce pb, on enlèvera d'abord l'invocation de rhgb au sein de la ligne de lancement du kernel (le boot ne sera donc pas graphique).

Dans une console avec les droits root:

vi /boot/grub/grub.conf
se positionner sur la ligne commençant par kernel ...
passer en mode insert (touche i)
supprimer rhgb
sauvegarder et quitter (:wq)
relancer

On mentionnera quelques autres cas de support de périphiques USB. Pour régler ces cas, il faut enlever les périphériques concernés lors du boot puis les brancher après initialisation du système...
Ce n'est pas la première fois que j'ai ce problème, je l'ai eu sur d'autres machines et des collègues ont planté leur tête de réseau du boulot car ils avaient activé la mise à jour auto... Bref, je suis surpris qu'un problème aussi flagrant et aussi récurrent soit en place depuis des mois.
Il faudrait en savoir plus sur les configurations impliquées. Effectivement, le support de certaines cartes graphiques ou certains matériels soulève des difficultés dont les forums se sont fait l'écho. Il s'agit malheureusement de pbs récurrents qui affectent très largement les distributions Linux...
Ma config est une carte mère a7n8x-x, carte vidéo ATI 9200 SE, carte son emu 0404 (exotique donc), disque maxtor 200Go, modem freebox sur entrée réseau de la carte mère.
Je vais tâcher effectivement de limiter les sources de mise à jour, en espérant que ça ne plante pas encore mon système.
Le yum.conf est celui d'origine :

[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
retries=20
obsoletes=1
gpgcheck=1

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
Le yum.conf ne contient aucun dépôt; ces derniers sont normalement décrits sous forme de fichiers dans /etc/yum.repos.d (selon la nouvelle version de yum).

Les tutoriaux expliquent comment procéder.


Les drivers ATI ont motivé (et motivent encore!) un fil assez long (plein de rebondissements!):

http://www.fedora-france.org/modules/newbb/viewtopic.php?topic_id=3155&start=0

As-tu réalisé les diverses manip. suggérées? (dont rhgb ...)
Je n'ose pas trop tenter l'update car quand c'est planté le système est bon à être relancé. Et je n'ai pas trop le temps car j'ai du boulot à faire sous linux et je ne peux pas prendre le temps de voir quel package me fait planter le système.
Bonjour,

Tu peux effectivement prendre le risque de travailler sur une machine qui semble instable.
Pour limiter les risques d'instabilité par les mises à jour, j'applique depuis un certain temps la méthode suivante :
- up2date dans sa config d'origine
- synaptic sur des dépôts dont je suis sûr (voir ce qu'a dit herrib fort justement)

Conseil pour tes collègues un peu trop enthousiastes : ne jamais mettre une machine en production sans avoir testé et validé longtemps (ce sont plus de 20 ans d'expérience dans ce domaine qui parlent).
Vi, dans ce cas c'était pour remplacer une distrib qui était archi hackée et qui plantait elle aussi sur les mises à jour, une mandrake d'ailleurs. Je vais retenter l'update après avoir enlevé le démarrage graphique (très joli d'ailleurs).
crystalizer a écrit:
...
des collègues ont planté leur tête de réseau du boulot car ils avaient activé la mise à jour auto
...
Pas trés prudent tes collègues.

Cf le post de tapioca.

J'ajouterai que personnellement j'utilise les maj officielles (avec up2date mais scotché sur un mirroir qui marche bien), avec prudence quand même :
- installation sur une machine de test
- lecture de la mailling list pour voir les réactions des autres utilisateurs

Car on peut avoir des soucis, ex : vixie-cron ou util-linux récemment. Heureusement ils sont trés réactifs dans ce cas.

Fedora n'est après tout que le labo de Redhat.

Avec les noyaux, depuis l'abandon de branche "devel" c'est d'ailleur une vrai horreur.
Ceci dit, FC3 est une distrib très mûre, très sûre et pourtant à la pointe : je vais enfin la mettre en production sur des config éprouvées, j'aurai ainsi un peu de temps à consacrer à la version suivante.
J'en profite d'ailleurs pour saluer respectueusement le super travail réalisé par tous ceux qui participent activement à son développement.
Ok, j'ai réussi à mettre à jour ma fedora3. J'ai plutôt bétonné : root sans serveur x et yum update après avoir enlevé rhgb. Au premier redémarrage, système planté juste après l'activation du swap.. J'ai tenu compte de vos remarques, j'ai débranché ma logitech pro 4000, rebooté comme un troll et me voici de nouveau à poster sous linux. Merci pour vos indications.
La vie est belle et la logitech bidule sucks (comme le disent nos amis britanniques ...).

Elle marche après?
Je n'ai pas eu le temps de coder une chtite appli pour vérifier si elle fonctionne mais ça redémarre alors que je l'ai rebranchée :-D
Elle fonctionne sous GnomeMeeting, plus facile d'installer une webcam sous linux que sous windows ! Par contre l'USB sous linux n'a pas l'air totalement stable.
Content de voir que ça se stabilise.
En ce qui concerne l'USB 1.1, je n'ai aucun problème mais je n'utilise que des mémoires de masse (APN Olympus ou mémoires sur sticks).
J'ai vécu des moments plus difficiles en USB 2.0 sous FC3, mais pas beaucoup plus décourageants que sous W2K.
Sous FC3, HOTPLUG est désormais couplé à HAL et UDEV : ça rajoute forcément de la complexité de mise au point.
J'ai aussi (parfois) le blocage après le "swap" (à cause de mon modem sagem USB).

Visiblement le problème est résolu avec le noyau 2.6.11 (je teste actuellement la version 2.6.11-1.14_FC3) qui ne devrait plus tarder. Par contre impossible d'utiliser les drivers ATI 🙁

Effectivement hotplug + udev + hal + usb c'est dur dur à mettre au point.

Mait ça avance...