systemx

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

mardi, décembre 22 2015

Archeries


Il y a pas à dire Arch est une très bonne distro, surtout avec une communauté active, une doc de qualité et une efficacité rare.
Cependant les mises à jour sont parfois très mystérieuses.
Celle de ce jour commence par les classiques tu veux remplacer toto/tutu par toto/tutu-toto ?
Le genre de truc incompréhensible et surtout on s'est fout un peu.
Exemple du jour :
:: Remplacer kdeadmin-ksystemlog par extra/ksystemlog ? [O/n] o
:: Remplacer kdegraphics-ksnapshot par extra/spectacle ? [O/n] o
:: Remplacer kdemultimedia-ffmpegthumbs par extra/ffmpegthumbs ? [O/n] o
On met oui parceque sinon on avance pas, de plus étant passé à plasma 5, je m'attends à ce genre de choses.
Mais ... surprise ca continue pour se terminer sur un magnifique :
:: libkolab et libkolab4 sont en conflit. Supprimer libkolab4 ? [o/N] o
erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
:: kdepim-wizards : requiert kdepim-kresources
Au final après différentes recherches, je passe à la methode forte :
[root@archx64 ~]# pacman -R kdepim-akonadiconsole kdepim-akregator kdepim-blogilo kdepim-console kdepim-kaddressbook kdepim-kalarm kdepim-kjots kdepim-kleopatra kdepim-kmail kdepim-knode kdepim-knotes kdepim-kontact kdepim-korganizer kdepim-kresources kdepim-ktimetracker kdepim-wizards
Ca passe mais quid de ces applications ... que je n'utilise guère et heuresement car l'installation de kmail entre en conflit entre libkdepim and kdepim-libkdepim, bien sûr, bien sûr.
Le passage manuel de KDE4 à plasma 5 est plutot une bonne chose (même si plasma4 est maintenant EOL) mais il faut maintenir derrière et la c'est très moyen.

samedi, janvier 3 2015

Upgrade Arch qui ne fonctionne pas.


Pour la nouvelle année un plantage de l'upgrade Arch :
[root@archx64 ~]# pacman -Syu 
:: Synchronisation des bases de données de paquets...
 core                                     121,6 KiB   617K/s 00:00 [#####################################] 100%
 extra                                   1809,1 KiB  1295K/s 00:01 [#####################################] 100%
 community                                  2,4 MiB  1359K/s 00:02 [#####################################] 100%
:: Début de la mise à jour complète du système...
:: Remplacer mesa-dri par extra/mesa ? [O/n] o
avertissement : skrooge : ignore la mise à jour du paquet (1.9.0-1 => 1.10.0-2)
résolution des dépendances...
avertissement : cycle de dépendances détecté :
avertissement : harfbuzz sera installé avant sa dépendance freetype2
recherche des conflits entre paquets...
erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
:: package-query : requiert pacman<4.2
Je pensais à un simple conflit de dépendances mais le problème semble plus compliqué (voir la derniere ligne ... ).
Pacman ayant été upgradé récement on tombe dans un conflit avec des packages externes voir ce post.
La solution :
[root@archx64 etc]# pacman -R yaourt
[root@archx64 etc]# pacman -R package-query  
Puis l'upgrade standard fonctionne.

Pour conclure, pour qu'une distro linux fonctionne bien il faut vraiment éviter les repos externes.
Les AUR c'est pratique mais à long terme plutot casse gueule, tout ca ne me pousse pas à penser que Arch est LA distro.
En rolling release Sabayon est plus stable et l'offre de package quasi aussi riche (sans compter les AUR et l'accès à emerge dans Sabayon). Arch rapide, légère mais pas la plus efficace !

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 ...

jeudi, juillet 18 2013

Korora - X ecran noir - Le fix en chroot

J'avais du faire une mise à jour Korora recement avant d'arreter l'ordi et aujourd'hui au démarrage au lancement de X, ecran noir.
Rien du tout, même pas de Ctr+Alt+Fx
Je reboot sur Sabayon, cherche sur le web et trouve une piste.
Je monte la Korora en chroot (via blk).
[22:17] root@sabayon / # yum downgrade xorg-x11-server-Xorg
Modules complémentaires chargés : etckeeper, langpacks, refresh-packagekit, refresh-updatesd,
...
rpmfusion-nonfree-updates                                                 | 3.3 kB  00:00:00     
...
updates/19/x86_64/group_gz                                                | 384 kB  00:00:00     
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet xorg-x11-server-Xorg.x86_64 0:1.14.1-4.fc19 sera une rétrogradation
---> Le paquet xorg-x11-server-Xorg.x86_64 0:1.14.2-3.fc19 sera effacé
--> Résolution des dépendances terminée

Dépendances résolues

=================================================================================================
 Package                        Architecture     Version                  Dépôt            Taille
=================================================================================================
Retour à la version précédente :
 xorg-x11-server-Xorg           x86_64           1.14.1-4.fc19            fedora           1.3 M

Résumé de la transaction
=================================================================================================
Retour à la version précédente  1 Paquet

Taille totale des téléchargements : 1.3 M
Is this ok [y/d/N]: y
Downloading packages:
xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64.rpm                             | 1.3 MB  00:00:01     
...
  Installation : xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64                                   1/2 
  Nettoyage    : xorg-x11-server-Xorg-1.14.2-3.fc19.x86_64                                   2/2 
...
  Vérification : xorg-x11-server-Xorg-1.14.1-4.fc19.x86_64                                   1/2 
  Vérification : xorg-x11-server-Xorg-1.14.2-3.fc19.x86_64                                   2/2 
...
Supprimé :
  xorg-x11-server-Xorg.x86_64 0:1.14.2-3.fc19                                                    
Installé :
  xorg-x11-server-Xorg.x86_64 0:1.14.1-4.fc19                                                    
Reboot et tout va bien.
Ensuite pour éviter les catastrophes on peut locker des versions de package mais ... il faut ajouter un autre package.
Pour masquer/empecher une version de package il faut avoir le package yum-plugin-versionlock.noarch.
Ensuite :
[22:28] root@korora ~ # yum versionlock xorg-x11-server-Xorg 
Loaded plugins: etckeeper, langpacks, refresh-packagekit, refresh-updatesd, versionlock
Adding versionlock on: 0:xorg-x11-server-Xorg-1.14.1-4.fc19
versionlock added: 1
[22:29] root@korora ~ # more /etc/yum/pluginconf.d/versionlock.list
# Added locks on Thu Jul 18 22:29:35 2013
0:xorg-x11-server-Xorg-1.14.1-4.fc19.*
Il y a un embryon de man : man yum-versionlock
Il en reste que tout ca est assez (très ...) mal documenté et un peu brouillon.
De la fedora quoi !

PS : Le post qui m'a permis de resoudre ce probleme.

mercredi, juin 19 2013

Mise à jour Rosa/Mageia - Comment que c'est censé se passer ?


J'ai été un peu confus sur la methode de mise à jour Rosa mal documentée.
Apparement il faut :
urpmi.removemedia -a
urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST'
urpmi --auto-update
Ca me donne :
[root@Rosa64 ~]# urpmi.addmedia --distrib --mirrorlist '$MIRRORLIST' adding medium "main" adding medium "main updates" .... adding medium "restricted updates" adding medium "Restricted32" ... $MIRRORLIST: media/../../i586/media/restricted/release/media_info/synthesis.hdlist.cz $MIRRORLIST: media/../../i586/media/restricted/updates/media_info/synthesis.hdlist.cz
[root@Rosa64 ~]# urpmi --auto-update                                                                          
medium "main" is up-to-date
medium "main updates" is up-to-date
blah blah blah blah blah ....
medium "Resctricted32 Updates" is up-to-date
Et enfin une question que je me posais déjà depuis des années :
In order to satisfy the 'python-distribute|python-distribute|python3-distribute|python-distribute|python-distribute|python3-distribute' dependency, one of the following packages is needed:
 1- python3-distribute-0.6.35-3-rosa2012.1.noarch: Python Distutils Enhancements (to install)
 2- python-distribute-0.6.35-3-rosa2012.1.noarch: Python Distutils Enhancements (to install)
What is your choice? (1-2) 1
Puis celle ci aussi ...
In order to satisfy the 'libjawt.so()(64bit)' dependency, one of the following packages is needed:
 1- lib64gcj13-4.7.3_2012.10-3.1-rosa2012.1.x86_64: Java runtime library for gcc (to install)
 2- java-1.7.0-openjdk-1.7.0.1-2.0.3-mdv2012.0.x86_64: OpenJDK Runtime Environment (to install)
 3- java-1.6.0-openjdk-1.6.0.0-26.b24.1-rosa2012.1.x86_64: OpenJDK Runtime Environment (to install)
 4- classpath-0.97.2-7-rosa2012.1.x86_64: GNU Classpath, Essential Libraries for Java (to install)
What is your choice? (1-4) 2
Ensuite j'ai eu des centaines de megs de mise à jour et tout s'est bien fini.

J'ai de plus regardé du coté de Mageia où j'ai eu les même mise à jour, comme j'ai pas envie de me mettre au russe et que les 2 distros sont assez semblables, j'ai décidé que Rosa passera à la moulinette du format pour une nouvelle remplacante.
Par contre ne peuvent-ils pas éviter ce genre de question dont personne (ou presque) ne se soucis et de faire le choix des composants logiciels ...
Y a donc plus guère que sur ubuntu et fedora que les mise à jour sont galère ?

jeudi, juin 13 2013

Mise à jour Arch - Intervention manuelle


J'utilise différentes distros pour comparer et voir comment elles se comportent sur le long terme.
Je vais noter les différents problèmes de mise à jour que j'ai pu avoir ...
Je suis Sabayon/Arch/Ubuntu/Rosa et Megiea/Korora et cherche une debian compatible sympa mais toujours pas trouvé.

Sur Arch suite aux changements d'architecture de certains repertoires, il faut opérer une opération manuelle pour que la mise à jour puisse être faite.
C'est correctement documenté dans la page de news arch.
C'est un peu court en explication sur les commandes :
  • pacman -Qqo/Qm
  • Q = query
    q = silentieux
    o = Appartient (own)
    m = Package "etranger" (qui n est pas dans la base des packages), installé via les AUR par exemple
Pour moi ca c'est passé sans complication mais pour les amateurs de AUR et autres packages non classique ça peut être casse gueule.
Du arch quoi !
  • Difficulté = 3
  • Criticité = 6
  • Explication = 9