25-Mise à jour "critique" Baselayout 2

Lors de ma mise à jour du 02 juin 2011 (ma dernière datée du 19 mars) avec ma classique séquence :

# emerge –sync; emerge -ud world; emerge –depclean; revdep-rebuild

j'ai dès le début 2 news à lire, ce qui se fait avec un

# eselect news read

(p.m une fois lues, pour retrouver ces news, il vous faut lancer "eselect news list" puis un eselect news read <item>" avec pour <item> le numéro correspondant à la new que vous voulez lire.)

La première m'annonce :

2011-04-27-glib-228
 Title Upgrade to GLIB 2.28

 Author The Gentoo Freedesktop Maintainers
  <freedesktop-bugs@gentoo.org>
  Posted 2011-04-27
 Revision                  1

The method for
setting default applications for specific URI types (https://,
mailto://, etc.) changed in dev-libs/glib-2.28 and newer.

If you
previously set them in GConf using the Configuration Editor, they
will now be ignored.

If you use GNOME, you must upgrade
gnome-session and gnome-control-center and set your default
browser/mail-client again.

If you don't use GNOME, you should
ensure that the file ~/.local/share/applications/mimeapps.list has
the following content:

[Added Associations]
x-scheme-handler/http=$browser_name.desktop;
x-scheme-handler/https=$browser_name.desktop;
x-scheme-handler/mailto=$mailclient_name.desktop;

Replace
$browser_name.desktop and $mailclient_name.desktop with the
appropriate file from /usr/share/applications that can handle
http/https/mailto URIs.

The system-wide version of the file is
often at /usr/share/applications/defaults.list instead.

Please
make sure that your browsers and mail clients have been upgraded to
the latest stable versions before doing all this.
More information about using defaults.list and mimeapps.list is at:
http://www.freedesktop.org/wiki/Specifications/mime-actions-spec

En clair, cela concerne l'upgrade vers glib 2.28. En gros les appels par défaut d'application de type URI (https://, mailto://, etc.) changent. Si nous avions utilisé Configuration Editor pour les définir dans GConf, et bien ces configurations seront ignorées.

La seconde nouvelle est plus inquiétante :

2011-05-01-baselayout-update
  Title    Baselayout update
  Author   Christian Faulhammer <fauli@gentoo.org>
  Author   William Hubbs <williamh@gentoo.org>
  Posted   2011-05-01
  Revision 1

The baselayout package provides files which all systems must have in
order to function properly. You are currently using version 1.x,
which has several issues. The most significant of these is that the
included init scripts are written entirely in bash, which makes them
slow and not very flexible.

On 2011/05/08, you will see an update for sys-apps/baselayout to 2.x 
and a new package,sys-apps/openrc. It is recommended that you perform
this update as soon as possible.

Please note, after these packages are
emerged, it is __Absolutely_Critical__ that you immediately update
your configuration files with dispatch-conf, etc-update or a similar
tool then follow the
steps in the migration guide located at the
following URL.

http://www.gentoo.org/doc/en/openrc-migration.xml

FAILURE
TO FOLLOW ALL OF THESE STEPS WILL RESULT IN AN UNBOOTABLE SYSTEM! IF
THIS SHOULD HAPPEN, YOU WILL NEED TO BOOT FROM A LIVE CD OR DVD,
MOUNT YOUR ROOT FILE SYSTEM, CHROOT INTO THAT ENVIRONMENT AND FOLLOW
THE ABOVE STEPS!

Quand on voit "Absolutely Critical" et "RESULT IN AN UNBOOTABLE SYSTEM", on craint le pire.

Pourtant mon gros problème ne viendra pas de là.

1 – La commande "Emerge" ne fonctionne plus – Python n'est plus installé

En effet mes quelques 146 mises à jour se passent correctement, vient le temps du emerge –depclean puis du revdep-rebuild et là message d'erreur !

Lorsqu'on regarde les logs d'emerge ("/var/log/emerge.log"), on remarque :

- Dans la séquence –update :

1307026442:  ::: completed emerge (103 of 146) dev-lang/python-2.7.1-r1 to /

- Dans la séquence –depclean :

1307088818: === Unmerging...(dev-lang/python-2.6.6-r2)
1307088829:  >>> unmerge success: dev-lang/python-2.6.6-r2

 - Et enfin sur la séquence revdep-rebuild

 1307132694:  === (10 of 16)
Compiling/Merging
(net-analyzer/net-snmp-5.4.2.1-r4::/usr/portage/net-analyzer/net-snmp/net-snmp-5.4.2.1-r4.ebuild)
1307133675:  *** Finished. Cleaning up...
1307133676:  *** exiting unsuccessfully with status '1'.
1307133679:  *** terminating.

Et dans l'affichage on trouve un :

requires libpython2.6.so.1.0

Par ailleurs, les commandes "emerge" ne fonctionnent plus, au sens où elles me renvoient que dalle, rien, nada, ...

Le changement de version de Python doit y être pour quelque chose, je tente alors un :

# python-updater

qui me répond

python 2 and 3 not installed

Sur le net d'autres ont exactement la même problématique et la réponse la plus avisée fut celle-ci.

Elle consiste à passer les commandes suivantes :

# eselect python list
[1] python2.7
[2] python3.1 

# eselect python set 1

Un python-updater est également nécessaire (mais il me semble de mémoire qu'à ce stade il ne va pas jusqu'au bout à cause de java-config, que je résouds au chapitre suivant)

Et de recommencer la procédure de mise à jour, car emerge fonctionne de nouveau.

2 – "revdep-rebuild" demande une mise à jour de setuptools et n'arrive pas à trouver java-config

Pour net-analyser/net-snmp-5.4.2.1-14, j'ai (/var/log/emerge.log)

1307132692:  >>> emerge (10 of
16) net-analyzer/net-snmp-5.4.2.1-r4 to /
1307132693:  === (10 of 16) Cleaning
(net-analyzer/net-snmp-5.4.2.1-r4::/usr/portage/net-analyzer/net-snmp/net-snmp-5.4.2.1-r4.ebuild)
1307132694:  === (10 of 16)
Compiling/Merging
(net-analyzer/net-snmp-5.4.2.1-r4::/usr/portage/net-analyzer/net-snmp/net-snmp-5.4.2.1-r4.ebuild)
1307133675:  *** Finished. Cleaning
up...
1307133676:  *** exiting unsuccessfully
with status '1'.

Et dans l'affichage (ou dans /var/tmp/portage/net-analyser/net-snmp-5.4.2.1-r4/temp/build.log que je n'ai pas gardé), on me parle de setuptools. Donc :

# emerge -va setuptools

puis

# emerge net-snmp

et c'est OK. Si tel n'est pas le cas essayez de supprimer et de ré installer, comme ceci :

# emerge -C setuptools
# emerge setuptools

idem avec net-snmp.

Je relance la mise à jour et cette fois, pour subversion-1.6.16, j'ai le message suivant :

Can't run java-config --help
Have you upgraded python recently but
haven't run python-updater yet?
ERROR: dev-vcs/subversion-1.6.16 failed
(setup phase):
    Can't run java-config –help

Problème similaire évoqué et résolu ici, et qui en résumé se résoud par un re emerge de java-config.

# emerge -va java-config

Nota : ne pas oublier de supprimer les fichiers temporaires :

# rm /var/cache/revedep-rebuild/*-rr

avant de relancer un revdep-rebuild.

3 – Garantir la migration vers openrc

Là j'ai suivi strictement cette page (que je vous conseille fortement de lire), et voici les changements que j'ai apporté (mais vous pouvez en avoir d'autres selon votre configuration, c'est pourquoi la lecture de la page de migration à Openrc est nécessaire) :

     3-1 La mise à jour des fichiers de configuration

J'ai 21 fichiers de configuration, tous n'ont pas la même importance, voici ceux que j'ai trouvé intéressants :

• /etc/host

c'est là que l'on met le nom de la machine, avec /etc/conf.d/hostname

• /etc/networks

A noter que l'on y trouve l'adresse par défaut lorsqu'il n'y a pas de réseau (169.254.0.0)

• /etc/bash

• /etc/protocols

• /etc/screenrc

• /etc/services

• /etc/sysctl.conf

• /etc/conf.d/consolefont

• /etc/conf.d/hostname

• /etc/conf.d/hwclock

• /etc/conf.d/keymaps

Si on veut un clavier français sous console (c.a.d lorsqu'on n'est pas sous X, à la mise en route notamment), il faut y mettre keymap="fr-latin9" au lieu de "us"

• /etc/tor/torrc

Ces fichiers se mettent à jour avec la commande "etc-update" ou "dispatch-conf" qui permet d'aller un peu plus vite, tout en gardant la visibilité des changements pour chaque fichier.

    3.2 /etc/conf.d/rc

/etc/conf.d/rc est devenu obsolète et les paramètres que vous y avez placés devront être migrés à l'endroit approprié dans le fichier /etc/rc.conf. Moi je n'y avais rien mis, mais par précaution plutôt que de supprimer /etc/conf.d/rc je l'ai renommé en /etc/conf/d/rc.old.

    3-3 Mettre net.eth0

Sous /etc/init.d, le lien net.eth0 n'existait pas, mais mes liens (connection Wi-Fi) sur net.wlan0 et net.wlan1 eux été présents. Cela se crée facilement par :

# cd /etc/init.d
# ln -s net.lo net.eth0

Par ailleurs, il y a quelque modif à apporter à /etc/conf.d/net, où il faut simplement enlever les parenthèses existantes, par exemple :

Voici un exemple de code ancienne configuration de /etc/conf.d/net

config_eth0=( "192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.100" )

et voici le code précédent version nouvelle configuration de /etc/conf.d/net

config_eth0="192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255"
routes_eth0="default via 192.168.1.100"

Comme ils n'étaient pas dans la séquence de boot :

# ls -al /etc/runlevels/boot/

j'ai du ajouter net.eth0 et mes net.wlanx au démarrage par :

# rc-update add net.eth0 boot

    3-4 Horloge

Les paramètres de l'horloge ont changé également, pour moi cela s'est fait automatiquement.

Mais la variable TIMEZONE est à présent placé dans le fichier /etc/timezone. S'il n'existe pas, vous devrez le créer avec votre fuseau horaire.

# vi /etc/timezone
Europe/Paris

    3.5 Journal de démarrage

Je trouve intéressant d'avoir un log du démarrage (même si avant je n'en avais pas). Mais avec OpenRC, c'est simple, il suffit d'écrire dans /etc/rc.conf

rc_logger="YES"

et les messages seront écrits dans /var/log/rc.log.

4 – Le "reboot" : clavier anglais et plus de Wi-Fi

Lors de la mise à jour des fichiers de configuration, vous avez du louper la modification de "/etc/conf.d/keymaps" dans lequel il faut écrire :

keymap="fr-latin9"

et non keymap='"us". Vous pouvez choisir le clavier qui vous convient le mieux sous "/usr/share/keymap/"

Pour le Wi-Fi, il y a quelque modif à apporter à /etc/conf.d/net  en effet le fichier /etc/conf.d/net n'utilise plus les tableaux de style bash pour la configuration. Vous devriez votre bonheur dans le fichier /usr/share/doc/openrc-<version>/net.example pour les instructions de configuration. La conversion devrait être assez simple, par exemple l'affectation d'une adresse IP statique devra se faire ainsi :

• Exemple de code avec l'ancienne configuration de /etc/conf.d/net

config_eth0=( "192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.100" )

• et le même code avec la nouvelle configuration de /etc/conf.d/net

config_eth0="192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255"
routes_eth0="default via 192.168.1.100"

Bref les parenthèses disparaissent !

Ensuite un :

# ls -al /etc/runlevels/boot/

montre que si net.lo est bien dans le process de boot, ce n'est pas le cas de /etc/init.d/net.wlan0, on corrige ce manque par :

# rc-update add net.wlan0 boot

Et voilà, tout est maintenant nickel !