28 - Une mise à jour (09/05/2012) avortée par saturation du DD (Disque Dur)

Faut-il encore répéter les séquences de mise à jour ? Oui ! alors voir la page : Mettre à Jour une Gentoo

La mise à jour de portage se passe sans problème.

2 news relatives à :

• 'udev-181 unmasking', et ce depuis le 10/03/2012, mais ne concerne que les systèmes avec /usr sur une partition séparée,
• et 'The default JPEG implementation' qui nous recommande de migrer de jpeg vers libjpeg-turbo :

   

  # emerge --deselect media-libs/jpeg
  # emerge --oneshot media-libs/libjpeg-turbo

Non, là où cela coince c'est comme d'habitude à la mise à jour proprement dite :

1 - Disque dur saturé = Mise à jour plantée

Au fur à mesure de l'avancée de la compilation (qui s'est déroulée sur 2 jours ...), je voyais grâce à conky mon espace disque diminuer. Je pensais que cela allait tenir, hé non, ce que je craignais arriva : la compil s'est arrêtée, la fenêtre s'est fermée, mon conky a disparu mais mon interface graphique est encore présente et fonctionnelle. (Plus tard, un emerge m'apprendra qu'il me reste 15 màj, donc 179 se sont déroulées sans problème)

Je vérifie que mon pronostic de plantage suite à manque d'espace disque est juste (cf. Mettre à Jour une Gentoo, paragraphe 6) :

# df -h | grep -E '(sd|hd)+'    
/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%.

Allons jeter un œil aux log pour voir ce que l'emerge a donné :

# vi /var/log/portage/elog/summary.log

Bon, il y a pas mal de WARN: postinst qu'il va falloir traiter (comme les, maintenant, traditionnels python-updater ${options}, ou autre java-config -L, puis -S, mais pas seulement).

Mais avant, il s'agit de libérer de l'espace mémoire afin de poursuivre la mise à jour : le mieux serait de supprimer des fichiers que l'on connaît, si cela ne suffit pas vous pouvez recourir à ce que je raconte en 16-Libérer de l'espace mémoire.

Je supprime quelques fichiers perso qui me libèrent ... 15M. Trop peu, mais suffisant pour lancer conky (mais je ne suis pas sûr qu'il me fallait libérer de l'espace mémoire pour le lancer) :

$ conky &

Pour être plus précis sur ce qui me prend de l'espace mémoire, je lance un :

#du -h --max-depth=1 --exclude=home /
5,2G    /var
8,9G    /usr
....

En appliquant la même commande aux 2 répertoires, on obtient :

pour /var

5,2G    /var
|===> 4,8G  /var/tmp
      |===> 4,8G  /var/tmp/portage
            |===> 3,1G  /var/tmp/portage/www-client
            |===> 1,8G  /var/tmp/portage/mail-client

Clairement les installations de firefox et de thunderbird se sont mal passées. Allons voir pourquoi :

# vi /var/tmp/portage/mail-client/thunderbird-8.0-r1/temp/build.log
# vi /var/tmp/portage/www-client/firefox-10.0.4/temp/build.log

J'y trouve en dernière ligne :

collect2: Id terminated with signal 9 [Killed]

Pas très explicite mais au moins on sait que ce n'est pas un problème "connu" de type java ou autre.

Donc ces 2 répertoires temporaires sont à supprimer, cela nous fera gagner près de 5Go !

pour /usr

8,9G    /usr
|===> 1,7G  /usr/lib
|===> 1,8G  /usr/src
      |===> 809M  /usr/src/linux-2.6.32-gentoo-r7    // celui que j'utilise actuellement !
      |===> 511M  /usr/src/linux-3.2.12-gentoo    // le dernier stable
      |===> 501M  /usr/src/linux-3.0.6-gentoo    // A supprimer 
|===> 4,2G  /usr/portage
      |===> comprend des répertoires de 2M en moyenne dont le plus gros fait 26M (dev-perl)

Après suppression des fichiers ci-dessus (# rm -rf <répertoire>), je lance la mise à jour du seul thunderbird :

2 - Gérer les plantages de compilation de Thunderbird et de Firefox

# emerge --update --deep -va thunderbird

et cela se termine comme précédemment (plantage, fenêtre de ma commande emerge fermée, conky arrêté) à la seule différence perceptible : mon gnome-terminal une fois relancé est revenu sur sa configuration par défaut !

Cette fois ce n'est pas lié à la saturation du disque :

# df -h | grep -E '(sd|hd)+'    
/dev/hda3        18G    14G    3,5G     80%    /
/dev/hda1        36M    27M    7,4M     79%    /boot

On jette un œil au log :

# vi /var/tmp/portage/mail-client/thunderbird-10.0.4/temp/build.log

A part le fait que la version a changé, le log ne m'apprend rien, la dernière ligne (très longue) appelle /usr/bin/python2.7, par ailleurs le summary.log ne fait pas état de cet emerge. Donc l'arrêt a été brutal, mais pourquoi ? Je ne sais pas, problème de taille mémoire mais RAM cette fois ?

Là je me souviens que j'ai également eu des soucis lors de la dernière mise à jour (cf. 27 - libpng-1.5.6, newuse et fin de 'gnome-cups-manager' (MàJ du 31/12/2011)) : suite à des soucis d'installation, j'avais installé la version binaire de thunderbird, en supprimant la version installée du set world, mais sans supprimer la version à compiler de portage !!!

Conclusion, je n'avais pas résolu mes problèmes de compilation de thunderbird la dernière fois en optant pour la solution de facilité : installer le binaire. C'est un peu normal de les retrouver ici.

Pour firefox, c'est presque pareil à la seule différence que j'ai gardé mon ancienne version (3.6.20) tout en gardant firefox dans portage et dans le set world.

Pour éviter (skipper) ces 2 points, j'ai lancé les commandes suivantes :

# emerge --update --deep thunderbird-bin
# emerge --update --deep -va world --exclude firefox

La dernière commande ne me compile pas, comme demandé, firefox, mais m'installe firefox-bin (version 10.0.4)

Pour sortir firefox du set world et garder ainsi ma version 3.6.20 (en faisant attention lors d'un --depclean) :

# emerge -va --deselect=y firefox

Cette fois la compilation va jusqu'à son terme, j'ai 72 fichiers de configuration à mettre à jour dont 27 triviaux, la commande 'etc-update' m'en laisse donc 45. Les plus marquants sont :

1. /etc/man.conf : compte tenu des problèmes rencontrés la dernière fois, à regarder de près et agir en conséquence. Mais pour moi, sans y apporter les modifications de la dernière fois, tout est correct.
   
2. /etc/conf.d/alsasound : ici il y a des points (modification du noyau) que je veux vérifier avant. Donc je garde l'update comme exemple, et je calerai cela plus tard.

Les autres, après y avoir jeter un œil ne posent pas question.

3 - Traiter les WARN: postinst

Avant de passer à la suite de la mise à jour, allons voir le /var/log/portage/elog/summary.log (cf.  paragraphe "3 - Lire les log") et traitons les WARN: postinst :

• sys-libs/glibc-2;14.1-r3 : il me faut ré éditer mes locales (/etc/locales) : fr_FR ISO-8859-1; fr_FR@euro ISO-8859-15; fr_FR.UTF-8 UTF-8.
• media-libs/libpng-1.5.10 me signale d'anciennes librairies ==> # revdep-rebuild --library '/usr/lib/libpng14.so.14' puis # rm '/usr/lib/libpng14.so.14'
• media-libs/freetype-2.4.9-r1 : le code TrueType n'est plus soumis à license, et n'est donc plus soumis au contrôle de l'USE 'bindist'. Si vous souhaitez garder ce comportement, il vous faut activer l'USE 'auto-hinter'. A voir.
• media-libs/alsa-lib-1.0.25-r1 : il est conseillé de remplacer l'ebuild alsa-driver par le driver ALSA inclus dans le kernel. A voir.
• media-sounds/alsa-utils-1.0.25-r1 : pour tirer tout le parti de ce script (sauvegarde et restauration automatiques des niveaux de la carte son), il faut lancer : 'rc-update add alsasound boot'. (déjà fait chez moi)
  
• dev-libs/libcdio-0.83 : il nous faut lancer 'revdep-rebuild', ce que nous ferons tout à l'heure.
• sys-devel/gcc-4.5.3-r2 : A voir si ce changement de version pose problème de type 'unable to locate libstdc++.la'. Si tel est le cas voir GCC upgrade guide sur le site de Gentoo.
• dev-libs/glib-2.30.3 : A voir si souci, re emerge dev-libs/dbus-glib
• sys-fs/udev-171-r5 : Un point de vigilance, car udev revient (cf. la new avec la commande eselect). Commentaire du summary.log à revoir si problème.
• sys-apps/openrc-0.9.8.4 : /etc/conf.d/net.example et wireless.example sont maintenant obsolètes et doivent être supprimés. Le fichier exemple est à trouver sous /usr/share/doc/openrc-0.9.8.4/net.example. La configuration reste dans le /etc/conf.d/net mais si vous utilisez l'ancien style il vous faudra le revoir en s'appuyant sur le 'net.example'. A voir si problème.
• app-arh/libarchive-3.0.3 :  me signale d'anciennes librairies ==> # revdep-rebuild --library '/lib/libarchive.so.2' puis # rm '/lib/libarchive.so.2' '/usr/lib/libarchive.so.2'
• www-servers/apache-2.2.22-r1 : mon serveur apache de test. Il faut s'assurer que dans le kernel CONFIG_SYSVIPC=y. Par ailleurs les modules cgi et cgid sont maintenant gérés via le flag APACHE2_MODULES dans /etc/make.conf ==> il faut s'assurer de leur activation pour qu'ils soient compilés. En principe, vous utilisez cgid avec des Multi Processing Modules (MPM) threadés (ce qui est mon cas : module worker), sinon utilisez cgi.
• net-misc/openssh-5.9_p1-r4 : Il est conseillé de mettre à jour la liste des clés sauvegardées plutôt que ce soit fait par les serveurs, cf. man ssh-keyscan. Ne pas oublier de lancer '/etc/init.d/sshd reload'  si vous touchez au fichier de configuration sous '/etc/ssh/'.
• dev-db/mysql-init-scripts-2.0_pre1-r2 me signale que les anciens scripts /etc/init.d/mysql et /etc/conf.d/mysql sont toujours présents, et qu'il faudrait les mettre à jour. A voir.
• sys-apps/man-pages-3.38 : si makewhatis n'est pas dans un lot cron (pour le savoir # crontab -l), alors vous devez mettre à jour la base whatis par : '# makewhatis -u'.
• net-fs/samba-3.5.15 signale qu'une implémentation expérimentale du protocole SMB2 a été ajoutée. SMB2 est une nouvelle implantation utilisée par Windows sous ses OS Vista et supérieurs. A voir sur mon serveur de fichier (qui n'est pas sous Gentoo). Mais pour l'instant mon W7 se connecte correctement.
•  dev-db/mysql-5.1.61 ma base de données de test, mais comme je ne l'avais pas encore utilisée j'ai lancé comme pour une première installation '# emerge --config =dev-db/mysql-5.1.61' qui me demande de renseigner mon mot de passe d'administrateur. S'il s'était agi d'une mise à jour un '# mysql_upgrade' aurait suffi.
• dev-lang/python-3.2.2 : Ah de nouveau python 3 ! il est dit que je viens d'upgrader une ancienne version de Python et il me faut lancer '# python-updater ${options}' pour re compiler les modules Python. Non sans une certaine appréhension, je m'exécute. J'ai 2 versions actives de Python : la 2.7 et la 3.1, la principale étant la 2.7. Je suppose que la màj ne concerne que la version 3.1.
  
• dev-java/icedtea-bin-1.10.4. Ici aussi un paquet habituellement à soucis. En 'WARN: prerm' j'ai : "Il apparaît que vous êtes en train de supprimer votre system-vm ! SVP lancer 'java-config -L' pour lister les VMs disponibles, puis 'java-config -S' pour définir un nouveau system-vm !".
  
• dev-java/icedtea-bin-6.1.11.1. VM la suite. Après un petit laïus sur le changement d'appellation (icedtea6-bin devient icedtea-bin-6), apparaît un commentaire inquiétant : "Si vous aviez icedtea6-bin comme sytem-VM, les changements seront automatiques, cependant les paramètres dans '/etc/java-config-2/build/jdk.conf' ne sont pas modifiés, il en est de même pour tous les utilisateurs de VM. Désolé pour cet inconvénient". En fait ce n'est pas gênant, car 'java-config -L' m'indique que j'ai bien un (seul) vm-system avec IcedTea JDK 6.1.11.1 et donc ce sera celui-là qui sera utilisé. Le jdk.conf ne sert que dans des utilisations avancées. Par contre le fichier /usr/share/java-config-2/config/jdk-defaults.conf qui liste les VM supportées parle encore de icedtea6-bin et non de icedtea-bin-6 !? (cf. http://www.gentoo.org/doc/fr/java.xml paragraphe 4)
  
• app-admin/sudo-1.8.3_p2. J'apprends que sudo utilise le fichier /etc/ldap.conf.sudo pour configurer ldap. Par ailleurs pour utiliser l'option -A (askpass), on doit installer un programme de mot de passe compatible : net-misc/ssh-askpass-fullscreen ou x11-ssh-askpass. Attention ces programmes ne forcent pas l'option -A. Le programme utilisé est défini dans la variable d'environnement SUDO_ASKPASS que vous pouvez modifier.
• dev-lang/php-5.3.13 : Avant de compiler des extensions pour 5.3 ABI, s'assurer que la variable PHP_TARGETS dans '/etc/make.conf' comprend php5-3. Par ailleurs, l'ebuild installe une version de php.ini correspondant à la version php.ini-development. Cependant on peut modifier cette installation par défaut en initialisant la variable PHP_INI_VERSION dans /etc/make.conf soit à 'production' soit à 'development'. Vous trouverez les 2 versions de php.ini sous '/usr/share/doc/php-5.3.13' 
  

4 - Mise à jour suite et fin

Bon il est temps maintenant de reprendre le cours de la mise à jour avec :

# emerge --depclean

Hé oui, j'ai oublié d'ajouter --noreplace firefox, donc exit ma version 3.6.20. Ce qui n'est pas trop grave car j'avais des messages pour me prévenir que cette version n'était plus maintenue et qu'il fallait la mettre à jour !

Mais le --depclean me fait aussi beaucoup le ménage autour de Python 3.

Passons maintenant à :

# revdep-rebuild

Là aussi, il y a du boulot, 15 paquets seront ainsi 're emergés'.

Tout semble OK, ce que me confirme un redémarrage du PC. Il ne reste qu'à régler les détails :

• Puisque pour Firefox j'ai installé le binaire au lieu d'avoir compilé les sources, il me faut remplacer l'appel 'firefox' par 'firefox-bin' dans .fluxbox/menu et dans .fluxbox/keys pour les touches spéciales de mon Evo N600 (Cf. aussi 23 - Sous X mon clavier est en 'us' et non en 'fr' (ou le passage à xorg 1.9) paragraphe '3 - Et mes touches spéciales')
• Reconfigurer mon terminal Gterminal afin de lui redonner la transparence de l'arrière-plan (Edition > Profils > Onglet Arrière-plan > cocher "Arrière-plan transparent" ), on peut jouer aussi sur les couleurs : noir pour le fond et bleu clair pour le texte par exemple.
  
• Terminer le traitement s'il y a lieu des WARN:Postinst marqués "A voir".
• Et un petit nettoyage des fichiers présents sur le disque dur ne serait pas superflu, que ce soit les fichiers perso ou les fichiers 'système'. Pour ce dernier point cf. 16-Libérer de l'espace mémoire.