Bonjour,

Ca sert à quoi des mises à jour qui plante un système opérationnel ?

Entre le Kernel et les Kmod qui ne se suivent pas ou bien tout simplement une application qui devient défectueuse alors qu'elle ne l'était pas......

Bref quand est-ce qu'on aura une sécurité sur les dépots pour éviter de tomber dans le piège à Chaque Fois ?

[Bash.fr]

#Pffff 1: ouai les MAJ c'est cool, ca t'évite d'avoir des bugs et ou des failles
#Pffff 2: oui d'accord mais quand je met mon system à jour il bug tout seul....
#Pffff 1: Ah bon, non c'est pas possible , t'as du laisser activer des dépots non-officiel ?
#Pffff 2: mais non, je connais les risques. De toute facon j'attendrais 1 mois pour être sûr des futurs MAJ.
#Pffff 1: 1 mois avec des failles et des bugs, non merci , je préfère booter sur un ancien kernel si j'ai des soucis.
#Pffff 2: c'est le chien qui se mord la queue ton histoire.
#Pffff 1: oui mais c'est en attendant des nouvelles MAJ.........🙂:-D:lol::hammer::pint:

[/Bash.fr]

@+
@LOOPING
with fedora update IS NOT testing but with F9 update IS WORSE THAN testing

65 mises à jour ce matin, mais aucune pour corriger les principaux bugs.
LOOPING wrote:Entre le Kernel et les Kmod qui ne se suivent pas ou bien tout simplement une application qui devient défectueuse alors qu'elle ne l'était pas......

Bref quand est-ce qu'on aura une sécurité sur les dépots pour éviter de tomber dans le piège à Chaque Fois ?

Je vous parle biensûre des dépots officiels.
Erreur : il n'y a aucun kmod dans les dépôts officiels.

++
@remi
En effet il n'y a aucun kmod dans les dépôts officiels. Mais qu'ils soient dans les officiels ou livna, le résultat pour l'utilisateur final est le même.

Déjà en temps ordinaire, on constate un décalage entre kernel et kmod, ce qui peut être considéré comme une erreur réccurente (et gênante), mais là on atteint des sommets.
Si le kmod pour le nouveau kernel n'est pas disponible, pourquoi lancez-vous la mise à jour du kernel ?

Fedora est une distribution à la pointe, il peut donc arriver de temps en temps ce genre de désagrément. Mais globalement, avec un minimum de prudence en faisant les mises à jour, on peut conserver son système stable à tout moment.

Je suis, moi même, resté avec la version 2.6.25.14-108 du kernel, je n'ai donc pas le soucis du kmod. Je ne passerai au noyau supérieur que lorsque le kmod sera disponible, ce qui ne devrait pas tarder.
akmod... On ne voit que ce mot sur le forum ces derniers temps... Il faudrait être aveugle pour l'avoir raté.
@Marcet
Comment fait-on pour éviter une mise à jour kernel si le kmod n'est pas disponible ? Lire le forum et attendre les messages de ceux qui se sont fait avoir.

@Pikachu_2014
Bien sûr, heureusement akmod existe, je l'utilise depuis le 2.6.26, mais rendre disponible le kmod en même temps que le kernel éviterait aux utilisateurs lambda de faire les pieds au mur (j'ai plus d'une dizaine de sites parents ou amis). Les utilisateurs lambda n'ont pas besoin de kernel-devel, mais akmods oui.

Un des avantages cités pour ne pas installer le driver Nvidia propriétaire, est d'éviter une compilation à chaque changement de noyau. Or c'est bien ce que fait akmod.
pmarion wrote:@Marcet
Comment fait-on pour éviter une mise à jour kernel si le kmod n'est pas disponible ? Lire le forum et attendre les messages de ceux qui se sont fait avoir.
C'est très simple : quand une mise à jour est proposée, il faut regarder de quoi il s'agit.
Si on voit que le kernel doit être mis à jour, il faut alors vérifier dans la liste que le ou les kmod(s) nécessaires sont aussi disponible.
@Pikachu_2014
Bien sûr, heureusement akmod existe, je l'utilise depuis le 2.6.26, mais rendre disponible le kmod en même temps que le kernel éviterait aux utilisateurs lambda de faire les pieds au mur (j'ai plus d'une dizaine de sites parents ou amis). Les utilisateurs lambda n'ont pas besoin de kernel-devel, mais akmods oui.
Les akmod sont là pour rendre service le temps que ça s'arrange 😉
Sinon, depuis que Fedora existe, le délai de mise à disposition des drivers nVidia par Livna n'a cessé de se réduire. Et vous, vous sautez sur le premier dysfonctionnement venu pour râler 🙁

Juste pour info, je rappelle que Livna n'est pas un dépôt officiel de Fedora.
Et que RedHat et Fedora ont connu des attaques récentes sur leurs serveurs, ce qui a conduit à resigner les paquetages. Il est possible que Livna ait connu des retards consécutifs à ces attaques. D'ailleurs si quelqu'un qui fréquente la mailing list de Livna pouvait nous renseigner, ce serait sympa 😉

Pour finir, je suis sur que tout va rentrer dans l'ordre très vite. Mais de grâce ne généralisez et ne dramatisez pas.
Marcet wrote:Si on voit que le kernel doit être mis à jour, il faut alors vérifier dans la liste que le ou les kmod(s) nécessaires sont aussi disponible.
@Marcet
Bravo tu viens d'inventer le yum/pakageKit assisté par l'utilisateur au lieu et place d'un yum/PackageKit transparent pour l'utilisateur.

Je me vois mal expliquer cela à un utilisateur lambda.

D'habitude, nous constations un décalage de 24/48H (24/48H de trop) mais là nous dépassons ce genre de délai.

Les dépendances ne sont pas faites pour les chiens. Ce matin 67 mises à jour comment vérifier qu'il n'y a pas dans ces 65 mises à jour une mise à jour qui va planter d'autres compostant.

Il y aurait certainement un moyen de créer un paquet supplémentaire kernel_kmod dont la dépendance serait kernel ET kmod au même niveau.

Et dans ce cas un utilisateur pourrait lancer les mises à jour sans avoir la peur au ventre ou sans devoir faire un travail qui ne lui incombe pas.
Je suis d'accord avec marcet, il suffisait de regarder le message d'erreur et voir ce qu'on mettait à jour.
Maintenant avec les akmod, ca devrait s'arranger.

Sinon elle sort d'ou la quote? j'ai cherché sur bashfr et je ne l'ai pas trouvée.

PS : pika, il est zoli ce nouvel avatar 😉
epo
marcet wrote:Juste pour info, je rappelle que Livna n'est pas un dépôt officiel de Fedora.
Heureusement que Livna existe, car sans lui fedora serait un peu nu ( nul ? )
C'est un peu trop redondant comme situation mais je ne dramatise pas pour autant.
Contrairement à Fedora, Windows peut récupérrer ses MAJ en automatique sans trop de souci par la suite.
Mais bon, t'es OpenSource ou tu l'es pas.....

J'ai mis Bash.fr parceque c'est le style de discussion, qui dois trainer sur IRC sauf que c'est pas sensé faire rire tout le monde.....
LOOPING wrote:mais non, je connais les risques. De toute facon j'attendrais 1 mois pour être sûr des futurs MAJ.
Mais c'est justement la différence qu'il devrait y avoir entre update et testing
Marcet wrote:Fedora est une distribution à la pointe, il peut donc arriver de temps en temps ce genre de désagrément. Mais globalement, avec un minimum de prudence en faisant les mises à jour, on peut conserver son système stable à tout moment.
Dans une mise à jour, qu'est-ce qui peux te prouver que la nouvelle version va pas faire bugguer ton systeme ? C'est pas possible ! :p

En même temps c'est un risque à prendre. Dans l'espoir t'avoir le problème corrigé au plus vite.

Actuellement ce qui me dérange le plus, c'est le problème de boot sur les portables, ou il faut mettre acpi à off, ou débrancher l'alimentation au boot. Quoique parfois ca marche pas si on débranche, il faut le laisser brancher ... enfin bref :p Le problème ne vient pas du bios (comme certains le croient) car plusieurs portables ont été touchés de marque différents. Et ce après une mise à jour.

Perso je préfère avoir quelques problèmes (rares) avec mes mises à jours et pouvoir surfer tranquillement sur le web 🙂
Ca, ce sont les joies de la distribution de pointe - laboratoire.

On ne peut jamais être sur que le système est opérationnel. Pour ma part c'est pour cette raison que je préfère m'amuser avec F9 sans rien avoir de crucial dessus mais travailler sous des versions abouties.
@nouv09
Tu es en train de nous dire que :
update IS testing
alors que pour moi
update IS NOT testing
@nouvo09: Donc tu bosses sous CentOS ou Fedora8.....

Perso je parlais juste des Mises à Jour, mais si tu commences a dériver sur les versions de la distribution , tu riques d'affronter les foudres de la colère divine des users-friendly-fedora-geek-underground.... ^^

Pour ne pas choquer les âmes sensibles, on dira qu'elle manque de maturité mais sa ne l'empêchera pas de garder une stabilité.
pmarion wrote:Je me vois mal expliquer cela à un utilisateur lambda.
Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda 😉

Si tu as des utilisateurs lambda à gérer, le mieux est encore de faire un dépôt local sur ton réseau, ce qui te permet de tester les mises à jour avant les utilisateurs.
D'habitude, nous constations un décalage de 24/48H (24/48H de trop) mais là nous dépassons ce genre de délai.
Comme je l'ai dit, c'est exceptionnel.
Les dépendances ne sont pas faites pour les chiens. Ce matin 67 mises à jour comment vérifier qu'il n'y a pas dans ces 65 mises à jour une mise à jour qui va planter d'autres compostant.

Il y aurait certainement un moyen de créer un paquet supplémentaire kernel_kmod dont la dépendance serait kernel ET kmod au même niveau.
Fedora ne fera jamais un tel paquetage. Je te rappelle que Fedora est 100% libre et que le dépôt Livna produit des paquetages non-libres.
Et dans ce cas un utilisateur pourrait lancer les mises à jour sans avoir la peur au ventre ou sans devoir faire un travail qui ne lui incombe pas.
Je savais pas qu'on pouvait avoir la peur au ventre dans ce genre de situation 😉
marcet wrote:Fedora ne fera jamais un tel paquetage. Je te rappelle que Fedora est 100% libre et que le dépôt Livna produit des paquetages non-libres
Je n'ai jamais dit que c'était à fedora de le faire.
marcet wrote:Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda
Je ne savais pas fedora aussi élitiste.

Faut-il avoir un CAF (Certificat d'aptitude à fedora) pour utiliser fedora ?

Sur ce forum nous avons en permanence des débutants que nous essayons d'aider. Ne les rebutons pas.
Solution simple : Utilisez des drivers Libres.
pmarion wrote:Je n'ai jamais dit que c'était à fedora de le faire.
Dans ce cas ça ne sert à rien.
Faut-il avoir un CAF (Certificat d'aptitude à fedora) pour utiliser fedora ?
Non, mais il ne faut pas perdre de vue que c'est une distribution qui se veut à la pointe de la nouveauté.
Sur ce forum nous avons en permanence des débutants que nous essayons d'aider. Ne les rebutons pas.
Loin de moi cette pensée, et tu sais bien que je suis parmi les premier à les aider quand je le peux. Seulement il est bon de rappeler que ce genre de choses peut se produire.
Mais peu importe, puisque le forum est là pour savoir comment réagir quand ça arrive 😉
@Marcet
Si cela n'arrivait pas, nous aurions plus de temps à passer sur d'autres problèmes !
Il suffit de voir combien de posts sur les kmod, sur rhgb et l'arrêt graphique (pour ne citer qu'eux).
louizatakk wrote:Solution simple : Utilisez des drivers Libres.
Comme dirai la mère Denis (paix à son âme) : "Ca c'est vrai çà !".
pmarion wrote:@nouv09
Tu es en train de nous dire que :
update IS testing
alors que pour moi
update IS NOT testing
Je vais même plus loin : je dis que Fedora entière est testing. En fait c'est bien de ça que tu te plains si j'ai bien suivi?

Je conserve une F6 qui tourne comme une horloge, mais sachant que je devrai l'abandonner un jour pour une question d'incompatibilité et j'ai une (non deux) centos 5.2. Ca ce n'est pas testing .
Sans aller jusqu'à tourner avec Fedora 6, on peut très bien différer les mises à jour, ça suffit en général pour garder sa distrib stable.
@Marcet
Je repose alors ma question comment faire :
yum --je_ne_veux_pas_les_fichiers_de_moins_de_30_jours update

Si on laisse les paquets sensibles dans testing suffisamment longtemps pour qu'il soient testés avant de les balancer dans update on a bien

update IS NOT testing
pmarion wrote:@Marcet
Je repose alors ma question comment faire :
yum --je_ne_veux_pas_les_fichiers_de_moins_de_30_jours update

Si on laisse les paquets sensibles dans testing suffisamment longtemps pour qu'il soient testés avant de les balancer dans update on a bien
Rire,

Sérieusement je n'en sais rien. J'imagine que si on crée chez soi un mirroir de Fedora on doit pouvoir trier selon les dates et heures des fichiers.

Mais si on trouve la solution à ça et qu'on télécharge un fichier âgé de 35 jours mais comportant un bug qui est corrigé dans un fichier qui lui n'a que 10 jours, quel est le résultat ?
LOOPING wrote:bonjour,
je suis débutant sous fédora et jamais utiliser linux auparavant...
Juste pour savoir si on peut utiliser les fonctions de hachage sha-224 à sha-512 sous fedora ? si oui comment ???
Help please 🙁
[Bash.fr]



[/Bash.fr]

@+
bonjour,
je suis débutant sous fédora et jamais utiliser linux auparavant...
Juste pour savoir si on peut utiliser les fonctions de hachage sha-224 à sha-512 sous fedora ? si oui comment ???
Help please sad
Juste pour calmer un peu le jeu, il faut savoir que si les kmod-nividia pour kernel 2.6.26 mettent autant de temps pour être disponible c'est simplement du au fait que 2 systèmes utilisés chez livna sont tombés en même (le serveur SVN pour les sources et le buildsys qui est le serveur effectuant les builds et plaçant ces build dans les dépôts).

Actuellement, le serveur SVN a été redémarré mais il reste encore le buildsys. Grâce au premier redémarrage, un membre de livna a buildé manuellement et hébergé hors dépôt les kmod pour Fedora9 et un utilisateur possédant Fedora 8 et Fedora 9 a effectué le build manuel pour Fedora 8. Ces derniers paquets sont eux aussi hébergés hors dépôts. Les pakcgaes pour Fedora 8 et 9 sont donc téléchargeables.
Donc pour ceux que ça intéresse, l'installation des kmod pour kernel 2.6.26 peut être effecutée via rpm. Sinon ben alors faites preuve de patience et dés que le serveur buildsys sera redémarré, les dépôts et les miroirs seront mise à jour.

Par conséquent, je ne blâmerai ni Fedora ni livna, car les 1er ne pouvaient pas savoir qu'il y aurait un plantage chez livna et les seconds ne sont pas responsables d'un plantage informatique car cela peut arriver et ne s'annonce pas 😉.
De plus le groupe Fedora devait-il bloquer la mise à jour d'une kernel pour 1 seul type de matériel (uniquement les cartes graphiqes nvidia) ? Personnellement je ne le pense pas et je peux vous dire que j'utilise une carte nvidia et que j'ai été piégé mais je prend mon mal en patience en utilisant akmod.

lionelh
lionelh wrote:Juste pour calmer un peu le jeu, il faut savoir que si les kmod-nividia pour kernel 2.6.26 mettent autant de temps pour être disponible c'est simplement du au fait que 2 systèmes utilisés chez livna sont tombés en même (le serveur SVN pour les sources et le buildsys qui est le serveur effectuant les builds et plaçant ces build dans les dépôts).
Par contre ils ne disent pas suite à quoi. Quelqu'un sait ?
Peut-être qu'ils utilisaient CYGWIN sous WINDOW$ ?
Que dire des procédures de backup et haute disponibilité ?
5 jours plus tard
@lionelh: le problème évoqué ici est récurrant depuis le début des Fedora Core.
Marcet wrote:on peut très bien différer les mises à jour, ça suffit en général pour garder sa distrib stable
Fedora n'est peut-être pas la distribution la plus adaptée pour les utilisateurs lambda
@Marcet: Donc tu es d'accord avec mon 1er post.
@pmarion & cx42net & nouvo09: on est d'accord.

Et puis pourquoi stopper la distrib, c'est riddicule, vu le nombre d'utilisateurs + les goodies ^^ , pourquoi devrait-on se tourner vers une autre distrib?
Ca sert à quoi de créer une communauté et le lendemain tout casser sous prétexte que le support sera arrêté?
On efface tout et on recommence ?

Alors pourquoi une Fedora 10, qu'elle est l'utilité ? pour allez pleurrer sur un Forum parcequ'on est bloqué après une MAJ ou sur une configuration....
#Pfff1: mais non c'est pour être à la pointe de la technologie..
#Pfff2: Pfff!

L'informatique repose essentiellement sur les mathématiques, autrement dit on peut avoir une Fedora sans avoir besoin de 1000 versions pour évoluer.
Si le code est cohérent comme un théorème alors on peut avoir 0 bugs = stabilité. Seules les failles peuvent existées encore.
L'idée c'est comment faire évoluer un noyau en gardant une rétro-compatibilité sur les anciens programmes qui devront subir une MaJ par la suite?
C'est là qu'est tout le challenge pour des distrib grand public.

Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
LOOPING wrote:Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
T'as dû te tromper de distro alors.

Essaye une debian 4.0 (stable)
@louizatakk
Mais non, à partir du moment où l'on n'utilise que 'update' (et non pas 'testing' ou 'rawhide') on peut espérer une version opérationnelle sinon stable.

update IS NOT testing
louizatakk wrote:
LOOPING wrote:Perso j'en rien à secoué d'avoir les dernières versions qui bugs.
T'as dû te tromper de distro alors.

Essaye une debian 4.0 (stable)
Eh bien oui ! Quand on a une philosophie particulière quant à son usage de l'informatique, on essaie de trouver la distribution qui a la même philosophie, et on ne va pas demander à une distribution qui n'a pas la même philosophie, d'en changer.

Pour toi, sans aucun doute, c'est sûrement plus debian que fedora qui saura répondre à ta façon de faire.
Miracle, Miracle, ........
Ce matin 30 mises à jour and the winner is LIVNA 
# egrep 'kernel|nvidia' yum.log | grep 'Oct 02'
Oct 02 08:03:04 Installed: kernel-2.6.26.5-45.fc9.i686
Oct 02 08:03:21 Installed: kernel-devel-2.6.26.5-45.fc9.i686
Oct 02 08:03:27 Updated: kernel-headers-2.6.26.5-45.fc9.i386
Oct 02 08:03:33 Updated: kmod-nvidia-173.14.12-5.lvn9.i686
Oct 02 08:03:34 Installed: kmod-nvidia-2.6.26.5-45.fc9.i686-173.14.12-5.lvn9.i686
Oct 02 08:03:43 Installed: kernel-2.6.26.5-45.fc9.i686
Encore un petit effort et livna sortira le kmod avant le kernel ! ! !
Bonjour,

Livna est toujours extrêmement rapide. Sauf quand ses serveurs sont en panne, évidemment.
Ça m'avait surpris aussi de voir à quel point ils étaient rapides oO