Mettre à Jour une Gentoo
Afin d'éviter de répéter à chaque fois ce que je fais, voici de manière concise les commandes que je lance pour mettre à jour ma Gentoo... et quelques commandes de débogage bien utiles.
1 - Les commandes de base
Quand tout se passe bien, vous devriez pouvoir enchaîner ces 5 commandes :
# emerge --sync /// Mise à jour de portage # emerge --update --deep world /// Sans le deep, on ne traite pas les dépendances
A noter que la dernière commande peut se noter en abrégé : emerge -uD world. Certains utilisent également :
# emerge -uDNav world /// -N = --newuse, -a = --ask et -v = --verbose
# emerge --depclean /// Suppression des liens dynamiques # revdep-rebuild /// Recompile les liens cassés, cela peut être très long # dispatch-conf /// Remplace etc-update pour la MàJ des fichiers de configuration (en .cfg)
Mais l'enchaînement sans complication reste rare.
Ainsi après la 1ière commande (mise à jour de portage) vous pouvez avoir les messages suivant:
* An update to portage is available. It is _highly_ recommended * that you update portage now, before any other packages are updated. * To update portage, run 'emerge portage' now. * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items.
En clair il vous est fortement conseillé d’exécuter un 'emerge portage' avant toute mise à jour.
Mais lire la new (ou les news) avec 'eselect news read' reste tout aussi important, car souvent il est fait mention de spécificités, particularités ou autres changements qu'il est bon de connaître avant de lancer une mise à jour.' Si vous voulez relire une news il vous faut d'abord les lister avec 'eselect news list', puis lire celle qui vous intéresse avec 'eselect news read <xx>' avec <xx> le numéro de la news donné par 'eselect news list'.
Important :
- ne lancez pas un 'emerge --depclean' sans avoir terminé votre mise à jour ('emerge -uD world');
- de même avant de lancer un 'emerge --depclean' il est préférable de lire le summary.log (cf. Paragraphe '3 - Lire les log' supra) et de traiter les WARN:Postinst
- par contre un 'revdep-rebuild' peut être utile et ce avant le 'emerge --depclean'
Il est bon aussi de connaître :
2 - Quelques commandes utiles
# emerge -pqv <atom>
Cette commande permet de connaître le statut du paquet car -p = --pretend (n'exécute pas vraiment, il fait comme si), -q = --quiet (il le fait en silence), -v = --verbose (mais cause beaucoup à la fin)
# emerge -C <atom>
-C = --unmerge = Suppression d'un paquet
# emerge -n <atom>
-n = --noreplace = (re) met le paquet dans le set world, ainsi il n'est pas supprimé par un 'emerge --depclean' par exemple.
# emerge -uDNav world --exclude <atom1> <atom2> ....
Cet 'emerge --exclude' permet d'éviter de mettre à jour un paquet donné (il n'installe ni ebuild, ni binaire correspondant). Cela peut arriver lorsque vous avez une mise à jour qui plante avec un paquet donné (ex firefox) : vous l'excluez provisoirement, vous finissez votre mise à jour, et éventuellement vous y revenez plus tard. A noter : votre paquet n'est pas enlevé du set world.
# emerge --deselect=y <atom>
Ici par contre on enlève le paquet du set world (qui se trouve sous /var/lib/portage/world), c'est la commande inverse de 'emerge --noreplace', mais attention lors du lancement d'un 'emerge --depclean' sans autre précaution supprimera tout paquet sorti du set world.
# equery uses <pkg>
La commande equery permet également plein de choses (cf. man equery), ici elle permet de connaître les USES d'un paquet donné, aussi bien de la version installée que celle de la mise à jour.
A propos d'USE, il peut en manquer ou certains doivent être changés. Dans ce cas il vous est proposé d'utiliser --autounmask-write pour écrire ces changements dans le fichier de configuration. Cette option est récente (mi 2011 je pense), et son utilisation est expliquée ici.
Mais lors d'une mise à jour, nous pouvons l'utiliser simplement comme ceci :
# emerge -uD world --autounmask-write
Nota : pour que l'écriture soit effective il vous faudra lancer la commande dispatch-conf (qui est le successeur de la commande 'etc-update') puis 'e' pour 'edit-new' ainsi vous verrez votre nouveau fichier et vous pourrez même le modifier, ensuite 'u' pour 'use-new' ce qui vous remplacera l'ancien fichier par le nouveau.
3 - Lire les log
Très vite lorsqu'une mise à jour plante, il est très instructif (mais rébarbatif je le concède) de se plonger dans les log. Le premier à regarder est celui qui archive toutes les commandes emerge : le summary.log
# vi /var/log/portage/elog/summary.log
ou "tail -f /var/log/portage/elog/summary.log" pour suivre / ne voir que la fin et ce en direct
Ensuite pour un build qui a planté, il est quasi incontournable de regarder son log qui se trouve :
# vi /var/tmp/portage/<nom/ebuild>/temp/build.log
Son environnement est sous (mais pour ma part je n'ai pas eu à l'utiliser):
# vi /var/tmp/portage/<nom/ebuild>/temp/environnement
Ensuite pour rapporter un problème (sous gentoo.bugzilla par exemple), il est souvent utile pour ceux qui vont vous aider de connaître le contexte que l'on trouve avec :
# emerge --info =<nom/ebuild> # emerge -pqv =<nom/ebuild>
Pour récupérer la sortie dans un fichier, tout en gardant la lecture à l'écran (Cf. aussi Le Shell ou les commandes Linux):
# <ma_commande> 2>&1 | tee out_ma_commande
4 - Un grand classique les problèmes liés à Xorg : pas d'interface graphique, pas de clavier, pas de souris
Cf. 17-Encore des problèmes de clavier et de souris – MàJ de juin 2010 au paragraphe "8 - Retour à la case : plus de clavier ni de touchpad"
Cf. 27 - libpng-1.5.6, newuse et fin de 'gnome-cups-manager' (MàJ du 31/12/2011)
Autant dire que dans ces cas là on galère un peu, car on se retrouve en mode texte plein écran sans 'ascenseur' (n'oubliez pas qu'un alt F2, F3, ... F6 vous donne accès à autant d'écrans différents).
Comme d'habitude lire le log de Xorg :
# vi /var/log/Xorg.0.log
Normalement vous y trouverez ce qui ne va pas, mais souvent c'est un problème de mise à jour des drivers que l'on résout par cette commande :
# emerge portage-utils; qlist -I -C x11-drivers/
ou celle-ci :
# emerge -1a $(qlist -I -C x11-drivers/)
5 - Le passage de la version 2 à la version 3 de Python
Comme tous les scripts de mise à jour sont écrits en Python, le passage à sa nouvelle version 3.x génère depuis un certain temps déjà (écrit en janvier 2012) quelques soucis.
Pour pallier ces difficultés la commande :
# python updater
est d'une grande utilité.
6 - La capacité disque est saturée
Sur des petites configurations comme la mienne (20Go de disque dur), il peut arriver que votre compilation s'arrête sans autre explication. Les formes peuvent être diverses : arrêt du micro, retour en mode texte, ou encore vous restez en mode graphique plus ou moins opérationnel. La raison est simple, la compilation consommant de l'espace mémoire, votre disque dur s'est saturé. Vous pouvez le vérifier simplement par la commande :
# df -h //df = Disk Free, -h = Human readable
où si vous êtes connecté à un serveur de fichiers et que vous ne souhaitez pas voir ces montages, mais ne voir que les /dev/hd* et (ou) les /dev/sd* voila la ligne :-)
# df -h | grep -E '(sd|hd)+'
Chez moi la réponse est :
/dev/hda3 18G 18G 0 100% / /dev/hda1 36M 27M 7,4M 79% /boot
On voit que ma partition principale sur /dev/hda3 est occupée à 100%.
Pour connaître plus précisément les répertoires ou dossiers qui occupent le plus d'espace mémoire, il suffit de lancer :
du -hs / //du = Disk Usage, -s = --summarize affiche le total pour chaque argument
ou, si on veut éviter un répertoire donné (en cas de montage sur un serveur de fichiers par exemple)
du -h --max-depth=0 --exclude=/home / //--max-depth=0 est équivalent à -s //--exclude ignore les répertoires indiqués, ici home
Pour faire le ménage cf. 16-Libérer de l'espace mémoire, mais attention tout de même si cela vous arrive en pleine mise à jour, vérifier dans les log que tout ce qui a été compilé s'est bien passé !