avril 2009 Archives

29-04-2009 19:08:21

make-kpkg à la recherche de l'initrd perdu !

Les dernières évolutions du paquet kernel-package sont assez déconcertantes. En effet, la construction d'un nouveau paquet de noyau et l'installation de ce même paquet ne respectent plus l'option historique --initrd.

Voilà des années que j'avais pris l'habitude de lancer la construction d'un paquet de noyau via la commande suivante :

$ make-kpkg --rootcmd fakeroot --initrd kernel_image

Une fois l'opération terminée, l'installation du paquet en question se fait à l'aide du gestionnaire local de paquets dpkg.

# cd /usr/src
# dpkg -i dpkg -i linux-image-2.6.29.2_2.6.29.2-10.00.Custom_amd64.deb

Les soucis sont arrivés avec la sentence suivante :

Clarify that kernel-package no longer will create initrds Instead, now all that --initrd does is to arrange to convey to the hook scripts that this image requires an initrd, and that the initrd generation hook scripts should not short circuit early. Without this option, the example initramfs hook scripts bundled in with kernel- package will take no action on installation. Bug fix: "fails to build initrd and make a non-compliant .deb from vanilla 2.6.27 source", thanks to Arthur Marsh (Closes: #524499).

Bien sûr, n'ayant pas bien lu le changelog du paquet et surtout oublié d'installer le paquet apt-listchanges, j'ai relancé mon transportable M6300 avec un noyau sans fichier image initrd. Facteur aggravant, j'ai migré le système de fichiers de la partition racine en ext4 ! Il était donc impossible d'utiliser les CDs Debian en mode rescue.

Je m'en suis tiré en copiant manuellement les fichiers vmlinuz et initrd d'une autre machine puis en montant la partition /boot formatée en ext3 à partir du module ext4 chargé en mémoire. Je suis donc maintenant en mesure de confirmer que le mode de compatibilité permettant d'utiliser un système de fichiers ext3 en ext4 est fonctionnel.

Bref, passons à la partie remise en route du fonctionnement habituel. Il faut commencer par faire le ménage dans les scripts de l'arborescence /etc/kernel puis recopier les exemples fournis avec la documentation du paquet kernel-package.

  • Suppression des scripts existants
    # find /etc/kernel -type f -name "init*"
    /etc/kernel/postrm.d/initramfs-tools
    /etc/kernel/postinst.d/initramfs-tools
    
    # find /etc/kernel -type f -name "init*" -exec rm {} \;
    
  • Recopie des exemples fournis avec le paquet
    # cp /usr/share/doc/kernel-package/examples/etc/kernel/postinst.d/initramfs /etc/kernel/postinst.d/
    # cp /usr/share/doc/kernel-package/examples/etc/kernel/postrm.d/initramfs /etc/kernel/postrm.d/
    

Lors de l'installation du paquet, on remarque que le script de création du fichier image initrd est bien utilisé.

# dpkg -i linux-image-2.6.29.2_2.6.29.2-10.00.Custom_amd64.deb
Sélection du paquet linux-image-2.6.29.2 précédemment désélectionné.
(Lecture de la base de données... 59452 fichiers et répertoires déjà installés.)
Dépaquetage de linux-image-2.6.29.2 (à partir de linux-image-2.6.29.2_2.6.29.2-10.00.Custom_amd64.deb) ...
Done.
Paramétrage de linux-image-2.6.29.2 (2.6.29.2-10.00.Custom) ...
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs
Running postinst hook script update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /vmlinuz-2.6.29.2
Found kernel: /vmlinuz-2.6.29
Found kernel: /vmlinuz-2.6.26-2-amd64
Updating /boot/grub/menu.lst ... done

Les fichiers en question sont bien présents dans le répertoire /boot.

# ls -Aw1 /boot/
config-2.6.26-2-amd64
config-2.6.29
config-2.6.29.2
grub
initrd.img-2.6.26-2-amd64
initrd.img-2.6.29
initrd.img-2.6.29.2
lost+found
System.map-2.6.26-2-amd64
System.map-2.6.29
System.map-2.6.29.2
vmlinuz-2.6.26-2-amd64
vmlinuz-2.6.29
vmlinuz-2.6.29.2

Et voilà ! Une péripétie de plus dans le monde merveilleux du logiciel libre ;)).

19-04-2009 17:32:49

Migration KDE 4.2 sur Debian unstable/sid

Pour commencer, il me faut avouer que j'avais craqué depuis longtemps pour les paquets de la branche expérimentale et l'APT pining dans le but hautement inavouable de fanfaronner devant les étudiants. Voilà donc quelques mois que j'utilise l'environnement graphique KDE 4.x sur le transportable M6300.

Depuis, la donne a changé et la publication de la version 4.2 de KDE a poussé l'équipe en charge de la gestion des paquets Debian correspondants à publier cette version dans la branche 'unstable' (aussi baptisée 'sid' pour Still In Development). Compte tenu de l'évolution rapide des bibliothèques et des dépendances dans cette branche de la distribution, il a bien fallu sauter le pas sur toutes les machines installées en unstable que j'administre et me confronter aux réactions des utilisateurs pas forcément enthousiastes à l'idée d'un bouleversement des habitudes d'utilisation d'un poste de travail.

Croyez-moi (ou pas), il est possible de survivre à cette évolution majeure de l'environnement graphique sans trop de casse. Il suffit juste de faire ressembler le plus possible KDE 4.2 à KDE 3.5.10 !

Voici un retour d'expérience sur une petite semaine d'utilisation de la nouvelle version de KDE 4.2. On y trouve quelques aspects futiles dans le style copies d'écran et quelques éléments plus sérieux comme une tentative d'optimisation de l'occupation mémoire de MYSQL ou une méthode détournée pour accéder à la personnalisation du gestionnaire de connexion.

Le contexte

Les machines sur lesquelles ces tests sont effectués sont au nombre de trois.

Poste fixe

Il s'agit d'une composition maison avec une installation Debian/unstable x86_64 et un noyau 2.6.29.1. La machine est basée sur les éléments matériels suivants :

  • Une carte mère ASUSTeK P5K-E/WiFi-AP (Intel P35 Express).

  • Un processeur Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz.

  • Une capacité mémoire de 4 Go de RAM.

  • Une carte graphique nVidia Corporation D9M-20 [GeForce 9400 GT] avec 512Mo de RAM et le pilote propriétaire en version 180.44.

Portable Dell M70

Il s'agit d'un portable acheté en 2005 avec une installation Debian/unstable i686 et un noyau 2.6.29.1. La machine est basée sur les éléments matériels suivants :

  • Une carte mère Dell/Intel avec un jeu de composants de la famille ICH6.

  • Un processeur Intel(R) Pentium(R) M processor 1.73GHz.

  • Une capacité mémoire de 1 Go de RAM.

  • Une carte graphique nVidia Corporation NV41 [Quadro FX Go1400] avec 256Mo de RAM et le pilote propriétaire en version 180.44.

Transportable Dell M6300

Il s'agit d'un portable acheté en 2005 avec une installation Debian/unstable i686 et un noyau 2.6.29.1. La machine est basée sur les éléments matériels suivants :

  • Une carte mère Dell/Intel avec un jeu de composants de la famille ICH8.

  • Un processeur Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz.

  • Une capacité mémoire de 4 Go de RAM

  • Une carte graphique nVidia Corporation Quadro FX 1600M avec 512Mo de RAM et le pilote propriétaire en version 185.19.

Les copies d'écran

Voici une petite série de copies d'écran illustrant le résultat de la migration vers KDE 4.2.

Cette première image illustre le Défilement circulaire obtenu en configurant les Effets du bureau.

La seconde image illustre l'utilisation des fonctions de Bords du bureau actifs. En plaçant le pointeur de la souris contre le coin supérieur gauche du bureau pendant quelques instants, on provoque un affichage de l'ensemble des applications actives dans ce bureau. Il ne reste plus ensuite qu'à cliquer sur l'application choisie pour qu'elle passe au premier plan.

La troisième image illustre l'utilisation du Tableau de bord et de son Gestionnaire des tâches placé en bas de l'écran. Le tableau de bord peut être placé librement sur le bureau. On voit aussi les informations sur la configuration graphique du poste via l'outil nvidia-settings.

La quatrième image montre un bureau «nu».

L'utilisation de MySQL

Avec l'apparition du gestionnaire de stockage des informations personnelles baptisé akonadi, on trouve une dépendance un peu surprenante dans le monde du poste de travail : le serveur MySQL. Je ne suis absolument pas compétent pour discuter du bien fondé du choix de MySQL ou de SQLite, mais il semble bien que l'artillerie lourde ait été déployée dans ce cas. Akonadi utilise principalement le service mysqld comme cache et non comme source de stockage. Il n'est donc pas nécessaire de disposer d'une configuration complète de type LAMP (Linux Apache MySQL PHP).

Facteur aggravant, les paquets Debian du service mysqld sont justement préparés pour une configuration serveur et ils occupent une place mémoire non négligeable sur le système.

Nous allons donc nous lancer dans la «réduction» de l'occupation mémoire du service mysqld après son installation et sa configuration telle que livrée via le jeu de paquets Debian. On commence par identifier les paquets installés.

$ dpkg -l mysql* | grep ^ii
ii  mysql-client-5.0       5.0.77-1         MySQL database client binaries
ii  mysql-common           5.0.77-1         MySQL database common files
ii  mysql-server           5.0.77-1         MySQL database server (metapackage ...)
ii  mysql-server-5.0       5.0.77-1         MySQL database server binaries

On identifie ensuite les processus lancés ... qui sont au nombre de 9. Rien que ça !

# pstree -p |grep mysql
|-mysqld_safe(4359)-+-logger(4399)
|                   `-mysqld(4398)-+-{mysqld}(4402)
|                                  |-{mysqld}(4403)
|                                  |-{mysqld}(4404)
|                                  |-{mysqld}(4405)
|                                  |-{mysqld}(4407)
|                                  |-{mysqld}(4408)
|                                  |-{mysqld}(4419)
|                                  |-{mysqld}(4420)
|                                  `-{mysqld}(4423)

Connaissant les numéros de processus, on peut essayer d'évaluer l'occupation mémoire du processus principal du service.

# pmap -d 4398                                
4398:   /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql \
--pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 \
--socket=/var/run/mysqld/mysqld.sock                                                                                                                          
Address           Kbytes Mode  Offset           Device    Mapping                                                                                          
0000000000400000    7500 r-x-- 0000000000000000 0fe:00003 mysqld                                                                                           
0000000000d52000     492 rw--- 0000000000752000 0fe:00003 mysqld                                                                                           
0000000000dcd000      88 rw--- 0000000000dcd000 000:00000   [ anon ]                                                                                       
000000000227e000   22752 rw--- 000000000227e000 000:00000   [ anon ]                                                                                       
00007feb55d04000       4 ----- 00007feb55d04000 000:00000   [ anon ]                                                                                       
00007feb55d05000    8192 rw--- 00007feb55d05000 000:00000   [ anon ]                                                                                       
00007feb56505000       4 ----- 00007feb56505000 000:00000   [ anon ]                                                                                       
00007feb56506000    8192 rw--- 00007feb56506000 000:00000   [ anon ]                                                                                       
00007feb56d06000       4 ----- 00007feb56d06000 000:00000   [ anon ]                                                                                       
00007feb56d07000    8192 rw--- 00007feb56d07000 000:00000   [ anon ]                                                                                       
00007feb57507000       4 ----- 00007feb57507000 000:00000   [ anon ]                                                                                       
00007feb57508000   10264 rw--- 00007feb57508000 000:00000   [ anon ]                                                                                       
00007feb5821e000       4 ----- 00007feb5821e000 000:00000   [ anon ]                                                                                       
00007feb5821f000    8192 rw--- 00007feb5821f000 000:00000   [ anon ]                                                                                       
00007feb58a1f000       4 ----- 00007feb58a1f000 000:00000   [ anon ]                                                                                       
00007feb58a20000    8192 rw--- 00007feb58a20000 000:00000   [ anon ]                                                                                       
00007feb59220000       4 ----- 00007feb59220000 000:00000   [ anon ]                                                                                       
00007feb59221000   36592 rw--- 00007feb59221000 000:00000   [ anon ]                                                                                       
00007feb5b5dd000      44 r-x-- 0000000000000000 0fe:00002 libnss_files-2.9.so                                                                              
<snipped/>
00007feb5ccdb000    2044 ----- 00000000000f1000 0fe:00003 libstdc++.so.6.0.10                                                                              
00007feb5ceda000      28 r---- 00000000000f0000 0fe:00003 libstdc++.so.6.0.10                                                                              
00007feb5cee1000       8 rw--- 00000000000f7000 0fe:00003 libstdc++.so.6.0.10                                                                              
<snipped/>
mapped: 160788K    writeable/private: 121044K    shared: 0K

Le calcul exact de l'occupation mémoire d'un ou plusieurs processus est assez complexe sur un système GNU/Linux. Comme le montre la copie d'écran ci-dessus un processus en cours d'exécution n'occupe pas une quantité mémoire fixe tout seul. Il fait appel à des bibliothèques partagées avec d'autres processus. Toujours dans la même copie d'écran, la liste de ces bibliothèques a été tronquée et j'ai choisi de faire apparaître les plus faciles à identifier : les bibliothèques standard C/C++.

L'arrêt d'un processus du service mysqld n'entraîne pas nécessairement le déchargement de ces bibliothèques de la mémoire puisqu'elles sont utilisées par ailleurs. Les éléments identifiables sont les suivants :

  • Les lignes repérées par r-x-- correspondent au segment de code du processus.

  • Les lignes repérées par rw--- correspondent au segment de données du processus.

  • La colonne Kbytes est la plus importante dans notre cas.

  • Généralement, ce sont les segments de données qui occupent le plus de place en mémoire.

  • La dernière ligne montre que le processus étudié occupe environ 118Mo à lui tout seul en faisant abstraction des bibliothèques partagées.

Pour un simple poste de travail, c'est énorme ! Il convient donc de procéder à une optimisation vers le bas de la configuration du service mysqld. Pour nous aider, nous disposons des exemples de fichiers de configuration fournis avec le paquet mysql-server-5.0. Le fichier qui nous intéresse est le suivant : /usr/share/doc/mysql-server-5.0/examples/my-small.cnf. À partir de cet exemple, on édite le fichier de configuration /etc/mysql/my.cnf en appliquant les valeurs proposées. Voici une copie réduite du fichier de configuration.

# egrep -v '^#|^$' /etc/mysql/my.cnf 
[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0
[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
language        = /usr/share/mysql/english
skip-external-locking
bind-address            = 127.0.0.1
key_buffer              = 16K
max_allowed_packet      = 1M
thread_stack            = 128K
thread_cache_size       = 8
myisam-recover          = BACKUP
query_cache_limit       = 1M
query_cache_size        = 16M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
skip-bdb
skip-innodb
skip-federated
[mysqldump]
quick
quote-names
max_allowed_packet      = 1M
[mysql]
[isamchk]
key_buffer              = 1M
!includedir /etc/mysql/conf.d/

Après avoir relancé le service, les nouvelles informations sur l'occupation mémoire sont obtenues avec les commandes déjà utilisées précédemment.

# pstree -p |grep mysql
|-mysqld_safe(27335)-+-logger(27375)
|                    `-mysqld(27374)-+-{mysqld}(27378)
|                                    `-{mysqld}(27381)

On ne trouve plus que 2 processus enfants au lieu de 9 précédemment.

# pmap -d 27374
27374:   /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql \
--pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 \
--socket=/var/run/mysqld/mysqld.sock                                                                                                                         
Address           Kbytes Mode  Offset           Device    Mapping                                                                                          
0000000000400000    7500 r-x-- 0000000000000000 0fe:00003 mysqld                                                                                           
0000000000d52000     492 rw--- 0000000000752000 0fe:00003 mysqld                                                                                           
0000000000dcd000      88 rw--- 0000000000dcd000 000:00000   [ anon ]                                                                                       
0000000002726000     532 rw--- 0000000002726000 000:00000   [ anon ]                                                                                       
00007f66b1fd3000   16368 rw--- 00007f66b1fd3000 000:00000   [ anon ]                                                                                       
00007f66b2fcf000      44 r-x-- 0000000000000000 0fe:00002 libnss_files-2.9.so                                                                              
00007f66b2fda000    2044 ----- 000000000000b000 0fe:00002 libnss_files-2.9.so                                                                              
<snipped/>
00007f66b46cd000    2044 ----- 00000000000f1000 0fe:00003 libstdc++.so.6.0.10                                                                              
00007f66b48cc000      28 r---- 00000000000f0000 0fe:00003 libstdc++.so.6.0.10                                                                              
<snipped/>
mapped: 66137K    writeable/private: 26420K    shared: 0K

Le résultat de la commande montre que les bibliothèques partagées sont toujours là avec les mêmes caractéristiques en termes d'occupation mémoire. Ce qui a changé, c'est la quantité de mémoire réservé au service mysqld qui est passée de presque 118Mo à 25.8Mo.

Bien sûr, il doit être possible de faire mieux ! Avec cette manipulation simple, on a gagné en capacité mémoire sans dégrader le service pour un usage monoposte. Si vous avez d'autres améliorations à proposer, je suis preneur !

La personnalisation du gestionnaire de connexion KDM

J'ai rencontré quelques difficultés pour personnaliser le gestionnaire de connexion KDM. En effet, dans la version précédente de ce gestionnaire, il était possible d'accéder au mode super-utilisateur via un bouton de l'interface graphique de l'application de configuration système.

Avec les nouveaux paquets, ce bouton semble avoir disparu ! J'ai donc fait appel à kdesudo pour accéder à la configuration en mode super-utilisateur.

  1. On commence par ajouter l'application systemsettings dans la liste des autorisations pour mon compte utilisateur via visudo.

    phil    ALL=NOPASSWD: /usr/bin/systemsettings
    
  2. On délègue l'utilisation de l'écran à toutes les connexions locales non réseau.

    $ xhost +local:                                                                                                                       
    non-network local connections being added to access control list
    
  3. On lance l'application de configuration du système pour accéder au gestionnaire de connexion.

    $ kdesudo /usr/bin/systemsettings
    

On accède enfin à la personnalisation du gestionnaire de connexion.

Pour le reste

À part ces petits désagréments, la migration est un succès. L'ensemble des applications «phares» de KDE fonctionnent à merveille.

  • Le client de courrier électronique kmail fonctionne parfaitement et tolère beaucoup mieux les (ruptures|reprises) de connexion avec les serveurs IMAP que la version précédente. Vu l'état de la ligne téléphonique domestique, c'est un très bon point.

  • Les programmes de télévision TNT sont bien gérés avec le player kaffeine même s'il s'agit d'une version (0.8.7-1) qui n'utilise pas encore le module multimedia phonon de KDE4.

  • La collection musicale est aussi bien gérée avec le player amarok. Comme dans le cas précédent, j'utilise encore une version (1.4.10-3+b1) de la génération KDE3. Il semble que l'interface graphique de la nouvelle version ne fasse pas l'unanimité. J'attends le paquet de la version 2.1 pour sauter le pas.

Bien sûr, cette liste est très incomplète et je n'ai cité que les applications KDE les plus importantes à mon sens. Ce qui est très subjectif. Voilà. Merci de m'avoir lu jusque là ;)).

Ce document est disponible en version imprimable au format PDF : kde4.2-sid.pdf.

$Id: kde4.2-sid.xml 1381 2009-04-19 15:32:10Z latu $