Je viens de tenter de mettre à jour mon système en utilisant la méthode de mise à jour recommandée, preupgrade, à partir de Fedora 16. J'ai eu énormément de mal à ce que anaconda accepte de se lancer. Il ne trouvait pas les paquets préalablement téléchargés par preupgrade. J'ai dû lui donner l'URL d'un repo en ligne pour qu'il re-télécharge tout (3 Go quand même).
Au final, il a tourné 5 heures, sans afficher le moindre message d'erreur et a redémarré correctement, pour arriver sur la même Fedora 16 qu'avant mais avec un yum inutilisable.
Heureusement, je fais toujours une sauvegarde complète du système avec rsync avant de lancer une mise à jour (de Fedora 9 à Fedora 17 j'en ai vu des mises à jour bancales). Et là, roulement de tambour, ma partition de sauvegarde a été mise à jour en Fedora 17. Si si ! Les deux partitions ne sont pas sur le même disque et n'ont ni le même numéro de partition, ni le même uuid, ni le même label…
Il y a certainement un script d'auto-détection à la con qui a réussi à choisir la sauvegarde à la place de la bonne partition…
Je n'ai plus qu'à espérer que la mise à jour s'est bien passée sur la sauvegarde. Bref, avant de tenter une installation de Fedora, il faut tout sauvegarder et déconnecter les médias de sauvegarde !
Franchement, anaconda (le programme d'installation de Fedora) c'est de la merde. On se croirait en train de d'installer un Windows. Heureusement, qu'il y a accès aux consoles virtuelles parce que l'interface graphique cache tellement ce qui se passe que ça en devient ridicule. J'ai dû lancer à plusieurs reprises des atop et des lsof pour vérifier si ça n'avait pas planté. On se coltine des messages à la con, du genre "préparation de l'installation" pendant une demi-heure sans aucune indication d'avancement, un écran complètement blanc pendant plusieurs minutes, etc. Les logs disponibles sur les consoles virtuelles ne sont pas d'une grande aide non plus. Viser la simplicité maximum, c'est bien, mais encore faudrait-il se donner les moyens pour que ça fonctionne. En plus, il faudrait voir à être réaliste, Fedora, c'est une distribution de bêta-testeurs pas de débutants… Je veux bien aider à tester RHEL mais il y a des limites.
Autre bug, ma disposition clavier n'est pas disponible dans anaconda parce qu'il n'utilise pas le même outil que la distribution (contrairement à Debian et Ubuntu par exemple). Évidemment, s'il utilisait dans ce cas une autre disposition (azerty ou même qwerty) ça irait, mais non, il plante ! Il faut éditer le fichier /boot/upgrade/ks.cfg avant de redémarrer pour changer la disposition du clavier qu'il a détecté.
Du coup, il vaut peut-être mieux utiliser yum pour faire la mise à jour. Ce n'est pas la méthode officielle mais au moins il y a de la doc et des gens qui testent.
Personnellement, j'utilise Fedora pour tester les derniers logiciels et remonter les bugs mais j'attends quand même que les logiciels de base fonctionnent correctement (yum, anaconda, rpm, preupgrade, outils de partitionnement, systèmes de fichiers, etc). Sinon autant utiliser Rawhide.
Lisant depuis longtemps plusieurs listes de diffusion du projet Fedora, j'ai pu constater que je ne suis pas le seul à penser que les utilisateurs avancés sont dédaignés et que des fonctionnalités critiques (je ne parle pas d'un truc désactivable comme pulseaudio) absolument pas prêtes sont parfois poussées coûte que coûte dans la distribution sans aucun égard pour les utilisateurs. Certes, on peut participer et on participe, mais la distribution est cassée plus vite qu'on ne peut la réparer. Ça fait des années que cela est discuté d'ailleurs, mais il me semblait que ça s'était un peu calmé. Qu'en pensez-vous ?
Un lien vers une discussion sur la mise à jour de F16 à F17 : http://forums.fedoraforum.org/showthread.php?t=280238
# ArchLinux
Posté par needs . Évalué à 10. Dernière modification le 30 mai 2012 à 03:51.
C'est exactement ce genre de petit détails qui m'ont fait passer à ArchLinux, un peu instable, jusqu’à la F15, yum était chez moi assez lent (la vitesse de pacman m'a vraiment impressionné). Les preupgrade n'ont jamais fonctionné une seule fois correctement (depuis F12), j'ai toujours du au final graver un DVD.
J'utilisais Openbox (depuis F14), c'est vraiment la galère sous Fedora, dès que tu diverge un peu de GNOME, c'est tout de suite moins rose tellement les logiciels sont liés entre eux, Nautilus qui ne monte pas tes périphériques, des permissions qui foirent un peu partout, les thèmes GTK qui ne marchent pas, bon bref.
Et pourquoi ArchLinux ? A trop vouloir cacher et simplifier les interfaces, tu bloques dès qu'une erreur survient, tu n'arrive pas à la résoudre de manière efficace car tu connais au final très peu se qui ce cache derrière les zolis boutons, tu perd d'une certaine manière le contrôle de ta machine, ou tout du moins, tu sens qu'il y a quelque chose qui t'échappe. Alors qu'avec ArchLinux (mais je suppose que c'est aussi valable avec Gentoo et d'autre distributions moins bling-bling), tu connais de manière beaucoup plus poussé comment fonctionne ton système, tu sais aussi qui fait quoi, c'est toi qui choisit et installe à peu près toutes les briques de ton système.
Et pourtant, Fedora à de bons arguments, mais elle est trop liée à GNOME ce qui la rend vraiment moins personnalisable, dommage.
[^] # Re: ArchLinux
Posté par fapro . Évalué à 8.
Oui, il y a aussi le problème d'être trop lié à Gnome. J'utilise KDE (enfin surtout Kwin et Konsole en fait). Il y a un groupe de héros qui s'occupent de l'intégration de KDE dans Fedora (KDE SIG) mais ils ne peuvent pas faire de miracles.
Pour l'instant, j'ai fait un rsync dans l'autre sens et je suis maintenant sur un système à moitié F16 et à moitié F17. En fait, la mise à jour n'avait pas complètement fonctionné sur la sauvegarde. J'ai le bug du kernel panic quand j'éteins le PC, comme tout le monde : il y a une solution, il suffit de forcer la mise à jour du noyau. Dans un sens, c'est rassurant.
Je suis en train de tenter de mettre à jour le reste mais yum a du mal à me trouver une solution.
Dès que c'est réglé, j'envoie quelques rapports de bugs.
Ensuite je pense que je vais tester ArchLinux effectivement. Je n'ai jamais testé ArchLinux et je ne change pas facilement de distribution pour mon PC personnel. Avant Fedora 9, j'utilisais Debian (principalement Sid) depuis Potato.
[^] # Re: ArchLinux
Posté par gnumdk (site web personnel) . Évalué à 8.
J'étais comme toi y'a 3 ans quand j'ai testé ArchLinux, sur un coup de sang suite à une mise à jour foireuse de Debian SID (ce qui est tolérable mais trop lentement corrigé!)…
J'y suis allé sans grande conviction, surtout à la vue de l'installation…
Grosse galère pour arriver à tout configurer correctement (genre créer le fichier /etc/X11/xorg.conf.d/11-keymap.conf) et là miracle:
- Ca boot très vite avec un init pourtant linéaire
- Tout est à jour, tout le temps!
- Aur est très pratique pour tester des versions de dev, des patchs (gtk-ubuntu par exemple), …
- Quand ca casse, c'est très vité réparer (souvent moins de deux jours et c'est là que j'ai décidé d'abandonner Debian SID)
Voilà, bref, pour le Desktop, ArchLinux, mangez en!
Pour les serveurs, je reste sous Debian Stable bien sur ;)
[^] # Re: ArchLinux
Posté par FabienC . Évalué à 2.
Comment se passe les grandes migrations sur Archlinux. Je pense à Systemd par exemple. Sur des distributions comme Ubuntu ou Fedora, ces systèmes sont 'imposés' lors d'un passage de version et j'aime bien l'idée de Fedora de pousser ces nouvelles technos. Mais sur les rolling release, on reste un peu avec l'ensemble logiciel que l'on avait choisi au départ sauf intervention manuelle, non ??
[^] # Re: ArchLinux
Posté par gnumdk (site web personnel) . Évalué à 6.
J'ai testé systemd sur mon portable hier, tu rajoutes justes une entrée dans ton "bootloader" et tu peux utiliser les deux systèmes de boot en //
Après, pour l'instant, systemd n'est pas l'init par défaut de ArchLinux et j'espère bien qu'il ne le deviendra pas (vu le bordel que c'est à gérer par rapport à rc.conf).
[^] # Re: ArchLinux
Posté par dguihal . Évalué à 7.
Il n'y a pas de réelles grande migration, c'est a chaque fois fait dans la douceur et la continuité.
Comme très peu de choses sont automatisées généralement tu retrouve les 2 lignes (genre system.d et boot arch) en parallèle pendant longtemps et a un moment tu vois passer un message comme quoi tel ou tel paquet et déprécié (genre hal par exemple). Mais comme les mises à jours sont en continu tu as le temps de t'y préparer et surtout tu n'as à gérer qu'une seule chose à la fois.
[^] # Re: ArchLinux
Posté par damien . Évalué à -6.
pfff… Qu'est-ce qu'on en vient encore a comparer archlinux à fedora.
C'est un peu n'importe quoi.
Honnêtement, je ne me suis jamais fier à Archlinux. Archlinux pour moi ça ne fonctionne pas. Elle me fou la trouille cette distribution.
Non Fedora n'est pas lié à GNOME… Faut arrêter un peu les préjugés. On a le même comportement sous archlinux. Tout ce que tu fais avec archlinux, tu sais le faire avec une Fedora, faut juste un peu de jujote et se dire que non Fedora ne fait pas tout, tout seul comme par magie.
Installe une Fedora minimal et tu es comme sous Archlinux. La Fedora, c'est toi qui la fait… Libre à toi de faire les mises-à-jour, d'installer ou d'utiliser les outils de configuration graphiques ou pas.
Pourquoi on en vient à comparer archlinux et fedora ? Ca na rien avoir ;)
[^] # Re: ArchLinux
Posté par gnumdk (site web personnel) . Évalué à 6. Dernière modification le 30 mai 2012 à 13:04.
Non, c'est la réalité, je viens de lancer une update sous F17, ca rame comme la mort…
Mais bon, pacman explose aussi APT/Dpkg …
Puis bon, Fedora ca sent la distrib avec les mises à jour testées:
Fedora, pour moi, c'est de la merde en boite… (t'as vu, sympa l'argumentation)
On voit bien que tu ne sais pas de quoi tu parles… Surtout quand tu finis en disant que ca n'a rien à voir…
[^] # Re: ArchLinux
Posté par claudex . Évalué à 2.
C'est marrant, pacman c'est le logiciel de gestion de paquet le plus lent que j'ai jamais essayé.
Mais bon, une distribution sans les informations de debug, c'est inutilisable pour moi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ArchLinux
Posté par gnumdk (site web personnel) . Évalué à 3.
Ah, ah, arrête, j'ai du mal à arrêter de rire…
C'est pas compliqué, une mise à jour de 50 paquets sous Arch (hors téléchargement), ca doit prendre 30 secondes… Sous Debian, entre les "triggers" et compagnie, t'as le temps de boire deux cafés… Et pourtant, I LOVE DEBIAN!
[^] # Re: ArchLinux
Posté par zerkman (site web personnel) . Évalué à 5.
Sur Debian, essaye ça :
Ca lance aptitude en supprimant tous les fsync qui garantissent la cohérence en cas de panne de courant pendant une mise à jour. Sur certains FS genre Btrfs où les sync sont très longs, ça va 3 ou 4 fois plus vite, et je suis gentil.
Par contre tu as intérêt à avoir une batterie chargée ou un onduleur.
De rien.
[^] # Re: ArchLinux
Posté par damien . Évalué à -3. Dernière modification le 30 mai 2012 à 13:20.
C'était pour le plasir de troller. Ca fini toujours en troll de chapelle les histoires de distributions ;) Honnêtement pour moi, les options de pacman sont imbuvables. Et une Fedora minimal avec tous les groups décochés à l'installation, c'est light :) Et après tu la fignoles comme tu veux.
Bha oui, c'est une distribution qui bouge beaucoup. Je dirais limite qu'il faut tweaker un peu.
# Konsole : can't open a pseudo teletype -> Solution
Posté par fapro . Évalué à 6.
Si Konsole ne fonctionne plus avec cette erreur "can't open a pseudo teletype", c'est un problème de permissions sur /dev/pts. Il faut penser à nettoyer le fichier fstab parce que systemd est censé s'occuper seul de monter les systèmes de fichiers spéciaux.
Il ne doit rester dans fstab que les systèmes de fichiers tels que /, /home, swap, etc.
C'est quelque chose qui aurait pu être noté dans les release notes. Ça date peut-être même de F16, mais ça ne posait pas de problème.
D'une manière générale, il y a un peu d'abus au niveau de la documentation chez Fedora. Je ne compte plus les features qui sont sorties avec zéro documentation. Quand les modifications occasionnent des régressions, il ne reste plus qu'à deviner le fonctionnement, lire le code, ou attendre que des gens d'ArchLinux ou Gentoo documentent ça sur leurs excellents wikis quand ce n'est pas spécifique à Fedora. Ce n'est pas la règle, heureusement, mais l'absence de documentation devrait être un critère pour refuser l'inclusion d'une feature.
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par Misc (site web personnel) . Évalué à 3.
L’équipe documentation accepte toujours de l'aide. Et je pense aussi que le but de Fedora est d'avoir les derniéres nouveautés, ça implique parfois des trucs pas aussi finis ( notamment au niveau de la doc ), ou avec encore des problèmes à régler. Comme pas assez de monde fait l'upgrade avant la stable, certains problèmes sont pas corrigés à temps car non signalé.
preupgrade a été testé plusieurs fois, il fait parti des critères de la QA. Mais il est testé dans des conditions qui sont par définition bornés et limités ( tu peux pas dire "tester dans tout les cas possibles" ), et il y a toujours quelqu'un ayant fait un truc hors des clous, et ça passe pas toujours. Un but de Fedora, c'est aussi d'avoir la communauté qui s'implique, donc pourquoi ne pas avoir testé plus tôt, surtout que tu as un système avec rsync et tout ?
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par barmic . Évalué à 4.
Il n'y a pas besoin de testeurs pour indiquer qu'il faut virer les FS spéciaux de fstab, soit les utilisateurs se mangent le problèmes et tentent de trouver une solution, soit les testeurs se mangent le problème et tentent de trouver une solution, soit le gars qui a intégré la fonctionnalité prend le temps d'ajouter 3 lignes pour expliquer ce qu'il fait (je ne connais pas l'organisation de fedora, mais je présume qu'il le fait de toute manière déjà pour informer ses pères ou le groupe de développeurs qui gère la version).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par Albert_ . Évalué à 4.
Je ne vois d'ailleurs pas pourquoi ce n'est pas fait automatiquement dans un script a l'installation de systemd. Si c'est un truc qui fout le merdier mais bon ca pose probleme pour Konsole qui est un logiciel KDE donc il ne faut pas trop s'etonner peut etre…
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Tous les intégristes vous le diront, la promiscuité des sociétés ne pratiquant pas une bigamie exclusive est nécessairement contre-productive en tout. Et c'est ainsi que l'information se perd pour un bête problème de parité/paternité :-).
Hou, mes pères, je m'y perd dans ces paires ; mais au cœur de ce péril de péricliter, il est bon de pouvoir compter sur ses pairs pour ne pas vous persécuter. Bon j'arrête de pérorer.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par barmic . Évalué à 3.
Je présume que tu voulais parler de monogamie, si non ça ne poserais pas de problèmes pour eux de créer un foyer avec 2 hommes et une femme.
Joli et merci pour la remarque instructive.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par Littleboy . Évalué à 4.
Le monde ne se reduit pas a la France.
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par fapro . Évalué à 3.
Je n'en doute pas, mais justement, je ne pense pas que ce soit à l'équipe documentation de se coltiner seule la doc sur les nouvelles features. C'est pour cela qu'il y a une section release notes sur les pages wiki des features. C'est le développeur qui doit remplir cette section. Sinon, personnellement, vu le nombre de projets libres où je suis déjà impliqué par rapport à mon temps libre, je peux difficilement en rajouter. Malheureusement, il faudrait plutôt que j'en abandonne.
Certes, mais j'estime qu'il y a quand même une limite. Sortir une nouvelle version avec un composant essentiel (yum, anaconda, etc) sans documentation et/ou pas fini donc pouvant potentiellement massacrer tout le système, je ne trouve pas cela acceptable. Un truc désactivable, comme pulseaudio à l'époque, je suis d'accord ça ne pose pas trop de problèmes.
Anaconda est un nid de bugs et manque de développeurs. Ce n'est pas qu'un problème de tests.
J'ai déjà utilisé Rawhide assez tôt dans le cycle et testé preupgrade en avance pour les versions précédentes. Je n'avais pas suffisamment de temps cette fois et surtout de nombreux bugs très problématiques étaient déjà rapportés. Je comptais donc tester quand les plus gros bugs auraient été résolus. Sauf qu'il a été décidé de ne pas retarder davantage la sortie, une fois les bugs critiques connus corrigés, sans laisser suffisamment de temps pour tester. Soit on accepte de faire moins de bouleversements pendant un cycle, soit on recule la date de sortie. Sortir le tout à la Rache® ne sert qu'à dégoutter les utilisateurs et les testeurs. Les utilisateurs ne sont pas payés pour tester donc il semble raisonnable de supposer qu'ils n'ont pas que cela à faire et qu'ils ont besoin d'un peu de temps. Il est aussi possible qu'il y ait un gros manque de testeurs mais dans ce cas il faudrait réfléchir à y remédier plutôt que de passer outre. Par ailleurs, je suis très loin d'être le seul à avoir des problèmes avec cette mise à jour donc des bugs critiques faciles à trouver, il y en avait.
Le fait est que les gens n'étant pas fous, beaucoup attendent un peu avant de mettre à jour. Certains vont jusqu'à mettre à jour avec quasiment un cycle de retard. Cependant tout le monde n'est pas censé savoir qu'il vaut souvent mieux attendre et surtout cela donne une mauvaise image à la distribution et décourage les testeurs. À quoi bon tester en avance si on ne vise plus à sortir une distribution réellement solide le jour de la sortie.
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par Albert_ . Évalué à 5.
En ce qui concerne le manque de testeurs je pense aussi que cela vient du fait du manque d'utilisateurs qui migrent peu a peu vers autre chose en raison de problemes tel que ceux enumere ici.
Personnellement j'ai apres des aventures malheureuse avec ubuntu (version KDE) regarde pour passer vers Fedora mais ce fut impossible. Tous les outils de configs etaient fait uniquement pour Gnome, YUM etait une horreur de lenteur et de pas pratique (venant du monde debian ca fait drole compare avec apt) j'ai trouve la communaute beaucoup moins sympa et qui se "la petait" avec systementiquement une reponse du style "cherche dans la doc" (doc qui est tres loin de celle de Gentoo ou meme de ubuntu).
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par Misc (site web personnel) . Évalué à 2.
Je pense que tu ne dois pas suivre les choses d'assez prêt.
Par exemple, systemd a été retardé de 6 mois pour manque de documentation, et il a été mis par défaut lors de la F16, parce que la documentation a été jugé suffisante ( mais pas suffisante pour tous, si j'en crois certains ici, et pourtant, lennart a mouillé la chemise je trouve ).
Ensuite, il y a eu 3 semaine de reports de la release de Fedora 17, justement pour corriger les bugs critiques.
( cf https://fedoraproject.org/wiki/Releases/17/Schedule ).
Enfin, il y a les élections en ce moment, donc tu peux toujours signaler que selon toi, le processus de features devrait rendre obligatoire l'écriture de documentation. Le vrai souci est dans ce cas que faire si quelqu'un ne joue pas le jeu. Dire "on reverte la feature" me parait assez violent, et retarder tout le monde pour une doc me parait pas terrible non plus.
Et comme tu dis, tout les bugs notés comme bloquant ont été corrigé, y a un meeting de validation chaque semaine, annoncé sur les listes. Donc soit un bug qui t'affecte n'a pas été noté comme bloquant, soit il n'a pas été reporté à temps. Si il n'a pas été reporté, ben soit c'est pas de chance, il touche tout le monde mais personne n'a fait de rapport, soit il touche moins de gens que tu crois, et il n'a pas eu droit à un rapport.
Ou le bug a été rapporté et il n'a pas été retenu comme bloquant, auquel cas il faut en effet dans ce cas revoir les critères de choix, et pour être franc, c'est déjà ce qui est fait régulièrement. Si tu penses qu'il y a eu un souci à ce niveau, les logs des meetings sont publiques, tu peux aller dire "voila, moi, je trouve que ce bug aurait du être noté comme bloquant, donc je propose de rajouter ça à la liste des critéres pour que ça se passe pas une 2eme fois". C'est pas un engagement sur le long terme, donc tu va pouvoir consacrer autant de temps à tout les projets libres auquel tu contribues, et au pire, on te dit non, auquel cas t va pouvoir revenir poster un journal.
[^] # Re: Konsole : can't open a pseudo teletype -> Solution
Posté par gnumdk (site web personnel) . Évalué à 0.
Cela n'empeche pas de documenter un peu ce que l'on fait avec une page comme celle ci:
http://www.archlinux.org/news/
Les devs d'Arch font vraiment un très bon travail de documentation des mises à jours, je ne vois pas pourquoi une équipe comme Fedora qui a plus de moyens n'y arrivent pas…
# Les nouveautés \o/
Posté par fapro . Évalué à 5.
J'ai quand même fini par m'en sortir mais ce fut laborieux : même vim ne fonctionnait plus à cause d'une bibliothèque introuvable.
Au final, maintenant ça fonctionne bien, je n'ai pas trouvé de régressions.
Je viens de tester virt-sandbox, c'est génial ce truc. Je vais pouvoir faire tourner les deux malheureux logiciels non-libres que j'utilise (boulot) là-dedans.
Spice fonctionne maintenant chez moi : depuis Fedora 15, ça plantait.
La saisie prédictive fonctionne bien sous KDE. Par contre, ça ne gère que l'anglais pour le moment.
J'ai hâte de tester les profils de couleurs ICC.
# /home séparé et ré-installation
Posté par TNorth . Évalué à 1.
Avec un /home séparé, on démarre sur une clé USB, et on installe directement F17 sur la partition principale.
Ça prend environ 15 min, on peut naviguer en même temps, et au redémarrage tout fonctionne avec les paramètres présents dans le .user/
(Par contre j'admets que c'est peut-être pas la solution la plus élégante de migrer)
Seul problème, il faut réinstaller les programmes utiles (c'est pas la mort, juste long la première semaine, et les plus prévoyants garderons leur rpm -qa dans un fichier), et ne pas oublier de garder les éventuelles config de /etc/.
Testé et approuvé depuis F14 :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.