systemx

Aller au contenu | Aller au menu | Aller à la recherche

samedi, janvier 11 2014

Korora (fedora) upgrade report


Ca y est la version 20 est sortie sur Korora, la fille de Fedora, Je fais la procédure d'upgrade telle que décrite
root@korora ~ # fedup-cli --network 20 --debuglog /root/fedupdebug.log
..
virtualbox/20/x86_64/primary                                                           | 3.4 kB  00:00:00     
No upgrade available for the following repos: fedora-chromium-stable
getting boot images...
.treeinfo.signed  
... 
Downloading failed: could not verify GPG signature: No public key


Pour les problemes GPG j'essaye de trouver les clés sur le web.
Heuresement avec Fedora y a de l'info, et je recupérer la clé GPG :
rpmkeys --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-primary
Pour limiter les problemes de repo externes, j'enleve le enable de la plupart des repos non natif fedora.
Je passe enabled=0 dans /etc/yum.repos.d/fedora-chromium-stable.repo, pareil pour garminplugin.repo et virtualbox.repo (virtualbox n'est pas inclus dans fefora).

Je réessaye ca déboule :
root@korora ~ # fedup-cli --network 20 --debuglog /root/fedupdebug.log 
setting up repos...
getting boot images...
.treeinfo.signed                                                                       | 2.0 kB  00:00:00     
....
(2260/2260): xulrunner-26.0-2.fc20.x86_64.rpm                                          |  23 MB  00:00:43     
Importing GPG key 0xAE688223:
 Userid     : "RPM Fusion free repository for Fedora (20) "
 Fingerprint: 0017 ddfe fd13 2929 9d55 b1d3 963a 8848 ae68 8223
 Package    : rpmfusion-free-release-19-1.noarch (installed)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-20

Downloading failed: The GPG keys listed for the "Korora 20 - x86_64" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: virtualbox-release-1.0-2.fc20.noarch
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-korora-19-primary
Je retombe sur les problèmes GPG pour la plupart des packages, au final pour arrêter la prise de tête j’enlève le package (comme suggéré dans les forums) :
root@korora ~ #  fedup-cli --network 20 --nogpgcheck
setting up repos...
...
[=======================================================================================]
WARNING: potential problems with upgrade
  iguanaIR-firmware-1.0.3-2.fc19.noarch (no replacement) requires iguanaIR-1.0.3-2.fc19.x86_64 (replaced by iguanaIR-1.0.5-2.fc20.x86_64)
verify local files 100% [====================================================================================]
...
rpm install 100% [===========================================================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.
Packages without updates:
  GarminPlugin-0.3.22-1.1.x86_64
  a52dec-0.7.4-18.fc19.x86_64
  akmods-0.5.1-3.fc19.noarch
  bouncycastle-tsp-1.46-6.fc19.noarch
  btparser-0.26-1.fc19.x86_64
  ...
  vo-amrwbenc-0.1.2-1.fc19.x86_64
  webrtc-0.1-0.11.20130531svn3704.fc19.x86_64
  xorg-x11-drv-modesetting-0.8.0-3.fc19.x86_64
  1:firstboot-19.2-1.fc19.x86_64
  1:jockey-akmods-0.9.7-7.fc19.2.noarch
  1:jockey-selinux-0.9.7-7.fc19.2.noarch
  1:v8-3.17.6.14-2.fc19.x86_64
  1:vagrant-1.2.3-1.x86_64

WARNING: problems were encountered during transaction test:
  broken dependencies
    iguanaIR-firmware-1.0.3-2.fc19.noarch requires iguanaIR-1.0.3-2.fc19.x86_64
Continue with the upgrade at your own risk.

Comme on peut le voir dans le log plus haut, il faut rebooter pour uprader (je passe les commentaires ...)
Ce que je fais, au boot, il faut choisir fedup (donc si en multiboot on a pas pensé à faire un grub2-install rien ne se passe).
Mais au reboot ca semble se lancer mais rien du tout, je suis toujours en F19.
Je cherche et je trouve quelques joyeusetés dont celle qui semble correspondre à mon problème, avec un /var séparé de root ca marche pas. Ce qui est très pénible car je n'ai pas trop de place dans / et il download tout pour installer (il a besoin de 7 ou 8 Gb alors que mon / fait 8Gb utile /15Gb total).
Un peu galère de gérer tout ca mais au final j'arrive à faire l'espace nécessaire en déplacant de bouts de /usr.
Au reboot suivant, fedup puis c'est très long très très long (2 heures) en mode console (ordi inutilisable).
Mais cette fois ca fonctionne ! Ouf !

Mais les jouyeusetés continuent !
  1. Xorg crashe
  2. Au reboot plantage lamentable de l'inteface graphique, je regarde /var/log/Xorg.0.log ou je vois un probleme de driver nouveau.
    Je précise que c'est une upgrade et ca fonctionnait avant ....
  3. KDM devient skyzo
  4. Il a en double à la mise à jour : ---> Package kde-settings-kdm.noarch 0:19-23.fc19 will be updated ---> Package kde-settings-kdm.noarch 0:20-12.fc20.1 will be an update Evidement ca aide pas, je retire tout et reinstall le fc20.
    Je reboot (pas possible de faire un systemctl restart kdm.service ... ah systemctl !) et kdm se lance bien.
  5. Chromium est pas dispo
  6. J'avais enlevé la bête du à des erreurs de yum mais la reinstalle est impossible car le repo fedora/chromium n'est pas encore mis à jour (1 mois après la sortie du produit), il suffit de reprendre la version fc19.
    yum --releasever=19 install chromium

Quelle aventure et que de temps perdu, décidement les rolling release deviennent vraiment indispensable.
Quelles galère ces upgrades fedora ...
J'aurai pu réinstaller de 0 puis utiliser les scripts puppet ou salt mais bon c'est pas très élégant.
Une fois de plus fedora prouve qu'elle n'a rien d'une distro user friendly et korora a encore du chemin à parcourir pour pallier à cela.
C'est à mon avis ce qui pourrait vraiment faire la plus value de cette distro qui pour le moment n'est qu'une fedora avec des repos en plus ...

mardi, avril 16 2013

Fedora grrr Redhat

RedHat étant un acteur important de l'écosystem linux voir le géniteur de l'opensource dans les datacenter, je suis régulièrement ce qui se passe sous fedora qui est leur bouillon de culture et qui permet de découvrir pas mal de nouvelles choses.
Cependant cette distro est vraiment pas confortable au quotidien car les softs non redhat sont très mal supportés et on doit invariablement passer par l'ajout de repos ou bien la chasse aux rpms sur internet.
Dans mon aventure sur Kokora j'avais une fois de plus noté l'inflation des repos (entre autre pour les produits google) et les problèmes de cohérence de l'ensemble du système.
Travaillant avec vagrant pour faire des usines de test Redhat, j'ai fait un tour sur fedora ou bien évidement le package n'existait pas (alors qu'il est dispo sur ubuntu/gentoo par exemple).
Ensuite l'intégration a vraiment confirmé cette impression de pas fini et du peu de considération de redhat pour les pauvres péquins comme moi.
En gros pour creer un modele de box vagrant il faut packager une virtualbox avec la command vagrant package qui sous fedora créé un fichier temporaire dans /tmp.
Or depuis F18 /tmp est un filesystem tempfs qui fait par defaut la taille de la moitié de la mémoire.
[@fedora .vagrant.d]$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           968M   28K  968M   1% /tmp
La creation de la box plante lamentablement et plombe /tmp, il faut en général quelques GB pour creer les package.
De plus virtualbox est pas packagé, il faut ajouter les repos, tout reconstruire à la mimine.
Il y a bien de moyens de changer ce comportement mais au final travailler sous fedora avec virtualbox/vagrant c'est un cauchemar.
Je retourne sous gentoo, sabayon ou même ubuntu où tout est très bien packagé et fonctionne sans problème.
Il reste à mon avis une belle place pour une distro basée sur fedora qui intégrerait bien tous ces composants (et d'autres) suite à la mort fuduntu (encore du aux abus de pouvoir de RH entre gnome/sytemd). car quoi qu'on en dise RH reste le plus gros acteur Linux en entreprise.
Toutes ces reflections me font d'ailleurs penser à la belle place que peuvent trouver Ubuntu ou Opensuse qui font des distributions à la fois orientées enteprises et end user qui sont plus souples et intégrées que le trio boiteux RHEL/CentOS/Fedora.

mercredi, octobre 17 2012

Fedora Yum ne fonctionne plus : cannot load dispatch table from pyexpat

Depuis la mise à jour en FC 17 impossible de faire fonctionner yum.

[root@fedorax64 ~]# yum update
Plugin "langpacks" can't be imported
Loaded plugins: presto
Traceback (most recent call last):
  File "/bin/yum", line 29, in 
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 321, in user_main
    errcode = main(args)
.....
  File "/usr/lib/python2.7/site-packages/yum/misc.py", line 1188, in cElementTree_iterparse
    return __cached_cElementTree.iterparse(filename)
  File "", line 78, in __init__
RuntimeError: cannot load dispatch table from pyexpat



C'est signe d'un probleme entre les librairies utilisées.

root@fedorax64 ~]# env | grep LD LD_LIBRARY_PATH=/data/oracle/ORA11GR2/lib: [root@fedorax64 ~]# unset LD_LIBRARY_PATH [root@fedorax64 ~]# yum update Loaded plugins: langpacks, presto Resolving Dependencies --> Running transaction check ---> Package apache-commons-io.noarch 1:2.0.1-3.fc16 will be updated ---> Package apache-commons-io.noarch 1:2.1-2.fc17 will be an update
Si ca ne fonctionne pas :
  1. Regarder/etc/ld.so.conf.d/
  2. Vérifier la version de python et python-libs
  3. Prendre les dernieres versions de rpmbone et upgrader (--force --nodeps)


jeudi, décembre 15 2011

Fedora et packagekit

L'integration de packagekit/gnome/fedora devenant très tenu il n'est plus possible d'enlever le package.
C'est très ennuyeux car il tourne sous chaque compte utilisateur et est très peu approprié pour une gestion centralisée des configurations des machines.
Il semble que la direction prise par fedora est de dire que il faut que la distro soit faite de tous les composants comme le temoigne la querelle de ce bug.
Heureusement j'ai trouvé comment empecher packagekit de tourner (grace à ce post) :
vi /etc/yum/pluginconf.d/refresh-packagekit.conf
=> enabled=0