avril 2009 Archives
29-04-2009 19:08:21
Posté par Philippe Latu | permalien | dans : Enseignement, Debian, M6300 | | | Read it in english with Google
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.
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.
-
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».
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
Kbytesest 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 !
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.
-
On commence par ajouter l'application systemsettings dans la liste des autorisations pour mon compte utilisateur via visudo.
phil ALL=NOPASSWD: /usr/bin/systemsettings
-
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
-
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.
À 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 $




