le blog de cep

Iceweasel Sandbox

posté par cep le 4 mai 2010

Mike Hommey a versé une pré-version 3.6.4 de Iceweasel dans experimental.

La particularité de cette version Debian est le “Out of Process Plugins”. Les plugins sont enfermés dans un sandbox, un bac à sable. Le gros avantage de ce principe est que si le plugin plante il n’entraîne pas avec lui le crash de tout le programme. Comme le précise Mike Hommey, pour le moment seul Adobe flash est concerné, mais comme il est le responsable de la plupart des plantages Firefox/Iceweasel cela devrait grandement améliorer le fonctionnement du programme.

On pourra installer cette version de Iceweasel par la commande aptitude install -t experimental iceweasel après avoir bien sûr activé les dépôts expérimentaux dans le sources.list.

Ne pas oublier d’installer aussi les versions “experimental” de iceweasel-l10n-fr, xulrunner-1.9.2, sans oublier libmozjs3d experimental, sinon Iceweasel a un segmentation fault au démarrage.

À l’heure actuelle les versions disponibles sont :
:~$ apt-show-versions icewea sel libmozjs3d iceweasel-l10n-fr xulrunner-1.9.2
iceweasel/experimental uptodate 3.6.4~build2-1
iceweasel-l10n-fr/experimental uptodate 1:3.6.3+debian-1
libmozjs3d/experimental uptodate 1.9.2.4~build2-1
xulrunner-1.9.2/experimental uptodate 1.9.2.4~build2-1

Si l’on ne veut pas tester les paquets Debian mais avoir tout de même les dernières versions de Firefox il est possible de récupérer les tar.bz2 sur http://ftp.mozilla.org/pub/mozilla.org/firefox/

cep

p.s chromium-browser est maintenant disponible en paquet Debian dans la branche Experimental en version 5.0.375.29~r46008-3

Topics : Général, debian, linux | 5 Commentaires »

udev, attr et attrs

posté par cep le 2 mai 2010

Si lors du boot s’affiche un message d’avertissement du genre :

udevd : SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/ suivi du nom de la règle .rules il faudra éditer la règle signalée et remplacer les occurences SYSFS par ATTR ou ATTRS.

On peut aussi rechercher la présence de SYSFS dans les logs du démarrage par la commande :
:~# grep ‘SYSFS’ /var/log/syslog ou syslog.0 , syslog.1 et suivants.

Il est aussi possible de le vérifier directement dans le répertoire des règles udev :
:~# grep -r -l ‘SYSFS’ /etc/udev/rules.d/

qui affichera le nom du fichier contenant l’occurrence SYSFS.

Après avoir modifié la règle et remplacé SYSFS il sera préférable de reconfigurer udev par la commande :
:~# dpkg-reconfigure udev
qui génèrera un nouveau initrd.img et ensuite relancer udev par la commande :

:~# service udev restart

Lors de l’édition de la règle udev la question va se poser de savoir si l’on remplace SYSFS par ATTR ou ATTRS. Prenons un exemple. Si je devais modifier la règle 70-persistent-net.rules contenant :

SUBSYSTEM==”net”, DRIVERS==”?*”, SYSFS{address}==”00:30:bd:6b:0f:d3″, NAME=”eth0″ etc. etc.

il s’agirait dans ce cas d’un attribut ATTR. L’utilitaire udevadm scinde ses informations dans des classements “looking at device” suivi des attribus ATTR et d’autres classements “looking at parent device” concernés par ATTRS.

En effet la commande :
~# udevadm info -a -p /sys/class/net/eth0 |grep address
me retournerait l’informaion :
ATTR{address}==”00:30:bd:6b:0f:d3″

alors que si ma règle était basée par exemple sur {device}==”0×8139″ j’aurais du employer ATTRS comme l’indique udevadm :

:~# udevadm info -a -p /sys/class/net/eth0 |grep -m1 “{device}”
ATTRS{device}==”0×8139″

À noter aussi que certaines règles présentes dans /etc/udev/rules.d/ peuvent être supprimées, elles seront recréés automatiquement (souvent avec les bonnes configurations), c’est d’ailleurs le cas de la règle 70-persistent-net.rules. D’autres seront mises en conformité lors de la mise à jour du paquet concerné. Mais ce n’est pas le cas de toutes les règles, comme par exemple celles générées par les programmes blackberry, certaines versions hplip, etc. etc.

Pour comprendre la rédaction des règles udev, une bonne adresse :
http://slackfr.org/doku.php?id=articles:logiciels:ecrire_des_regles_pour_udev
ou bien en anglais :
http://www.reactivated.net/writing_udev_rules.html
http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html

Pensez simplement à remplacer la commande udevinfo par udevadm.

cep

p.s. Si l’on voulait connaitre les informations udev sur le disque sda, la commande à passer serait
udevadm info -a -n sda

Topics : Général, linux | Pas de commentaire »

modifier un script de grub-pc

posté par cep le 25 avril 2010

Sur une Debian sid avec le noyau 2.6.33-2-amd64 j’avais besoin de démarrer avec l’option nouveau.modeset=0 passée en paramètre sur la ligne du kernel de grub-pc. Les autres noyaux n’avaient pas besoin de cette option supplémentaire.

Bien sûr il est possible d’éditer grub.cfg pour modifier la ligne du noyau concerné, mais cela n’est pas pratique si pour certaines raisons on est appelé à faire plusieurs update-grub.

L’ami tellmewhy ayant étudié depuis un certain temps tous les scripts de grub2, je lui ai demandé quelle solution il appliquerait pour modifier le fichier de boot. Il m’a conseillé d’ajouter une condition dans le fichier /etc/grub.d/10_linux dans la partie linux_entry () en commentant la ligne args=”$4 et d’y ajouter mon if . . . else. Les autres lignes de la partie se terminant à :
EOF
}
restent inchangées.

Dans mon cas la partie modifiée ressemble à ceci :

linux_entry ()
{
os=”$1″
version=”$2″
recovery=”$3″
# args=”$4″
if [ $version = “2.6.33-2-amd64″ ] && [ $recovery = “false” ]; then
args=”$4 nouveau.modeset=0″
else
args=”$4″
fi

et lignes suivantes inchangées.

Si, avant de modifier le fichier 10_linux, on en fait une copie de sauvegarde, ne pas placer cette sauvegarde dans /etc/grub.d/ car le fichier de sauvegarde sera lui aussi exécuté, quel que soit le nom qu’on lui donne et on aura une partie linux en double dans grub.cfg.

Bien sûr, lors d’une mise à jour de grub, s’il y a une nouvelle version du fichier 10_linux il faudra refaire la modification. En outre, si le paramètre supplémentaire doit être ajouté sur toutes les lignes du noyau il suffira de modifier le ficher /etc/default/grub sur la ligne GRUB_CMDLINE_LINUX_DEFAULT ou bien la ligne GRUB_CMDLINE_LINUX suivant qu’il faille ajouter l’option aux lignes de boot normal ou aux lignes normales et aux lignes “recovery”
cep

Topics : Général, debian, linux | 1 Commentaire »

updates lentes

posté par cep le 29 mars 2010

Depuis quelques temps la récupération de la liste des paquets à mettre à jour est très lente si l’on a les dépôts Google activés. Ces dépôts ne respecteraient pas la RFC 2068

Une solution est de lancer la commande apt-get ou aptitude avec l’option Acquire::http::Pipeline-Depth=0 comme par exemple :

aptitude -o Acquire::http::Pipeline-Depth=0 update

Une autre possibilité est de créer un fichier dans /etc/apt/apt.conf.d/ contenant ces options comme par exemple :

:~$ cat /etc/apt/apt.conf.d/01pipeline
# désactiver http/1.1 pipeline
# voir man apt.conf
Acquire::http::Pipeline-Depth “0″;

La lecture du man apt.conf nous renseigne sur cette option :

“Une option de configuration est fournie pour contrôler la profondeur du tube pour le cas où un serveur distant n’est pas conforme à la RFC ou est bogué (comme Squid 2.0.2). Acquire::http::Pipeline-Depth a une valeur comprise entre 0 et 5 : elle indique le nombre de requêtes en attente qui peuvent être émises. Quand la machine distante ne conserve pas correctement les connexions TCP, la valeur doit être égale à 0. Dans le cas contraire, des données seront corrompues. Les machines qui ont besoin de cette option ne respectent pas la RFC 2068.”

Pour suivre l’évolution de ce bug, voir :

http://code.google.com/p/chromium/issues/detail?id=38608

cep

ÉDIT du 26/04/2010 : le problème a été résolu sur les serveurs Google et l’option pipeline n’est plus nécessaire. À noter que cupt émettait un message d’erreur au passage de l’option pipeline mais récupérait les données sans problème.

Topics : Général, debian, ubuntu | 7 Commentaires »

linux-base

posté par cep le 1 mars 2010

Linux-image-2.6.33-2 est disponible dans la branche “experimental” Debian. L’installation de ce nouveau kernel apporte aussi l’installation du paquet linux-base, chargé entre autre de faire passer l’utilisation de Ide à Pata. Ceux qui utilisaient encore la dénomination des disques sous la forme /dev/hd les verront transformés en /dev/sd.

Pour faciliter ce passage, toujours pour ceux qui ne l’auraient pas encore fait, il sera préférable de désigner les disques par leur label ou leur uuid dans les fichiers de configurations, en particulier dans /etc/fstab et /boot/grub/grub.cfg.

Si elle est toujours disponible dans les dépôts, ne pas installer la version 2.6.33-1~experimental.1 de linux-base mais préférer la version 2.6.33-1~experimental.2 car la première version souffre d’un bug bloquant la configuration du paquet.

Le paquet linux-image-2.6.33-2 apporte aussi les drivers Nouveau. Pour toutes informations sur les nouveautés du kernel 2.6.33 voir l’article de patrick_g, toujours aussi exhaustif sur le sujet, article disponible sur linux.fr : http://linuxfr.org/2010/02/25/26478.html

cep

EDIT du 23/05/2010 :

lors du passage de Ide à Pata le fichier /boot/grub/device.map ne sera pas modifié et risque de porter encore les références (hd0) /dev/hda

Pour modifier cela, utiliser la commande grub-mkdevicemap qui va recréer un nouveau device.map avec les bonnes coordonnées.

Topics : Général, debian | 1 Commentaire »

2.6.32 et rt61

posté par cep le 9 décembre 2009

Les versions Rc* du kernel 2.6.32 de même que la version 2.6.32-1 révèlent un problème avec les cartes wifi à base de ralink rt61 (et s’emble-t’il pour d’autres constructeurs aussi ).

Voir :
http://lkml.org/lkml/2009/12/8/213
http://patchwork.kernel.org/patch/65154/
http://bugzilla.kernel.org/show_bug.cgi?id=14731

Une solution temporaire si les dernières versions du kernel ne sont pas disponibles est de désactiver le “powersaving” par la commande :
iwconfig wlan0 power off
en adaptant l’adresse de votre interface.

cep

Topics : Général, linux | Pas de commentaire »

initrd sur 2.6.3*

posté par cep le 12 novembre 2009

Un ami devait recompiler son noyau pour y modifier une option concernant la gestion de la mémoire. Après avoir récupéré le linux-source xxx et fait toutes les procédures de compilation, y compris le :

fakeroot make-kpkg –initrd etc. etc.

à la fin, après installation du nouveau kernel il n’y avait pas d’ initrd.img-xxxx dans /boot/ et cela malgré la présence du fichier /etc/kernel/postinst.d/initramfs-tools créé lors de l’installation du paquet initramfs-tools.

La commande dpkg-reconfigure linux-image-2.6.3xxxx ne générait pas non plus l’initrd.

Bien sûr il a tout de suite résolu son problème en faisant un : update-initramfs -c -k 2.6.3xxxx
suivi d’un update-grub. Mais cela ne le satisfaisait pas.

Nous avons fait quelques recherches google, lu le man make-kpkg, man kernel-package, différents man de initramfs-tools pour enfin se rendre compte qu’il fallait compléter les scripts dans /etc/kernel/postinst.d.

Après avoir récupéré dans /usr/share/kernel-package/examples/etc/kernel/postinst.d l’exemple de script initramfs nous l’avons ajouté dans le répertoire /etc/kernel/postinst.d et l’avons rendu exécutable.

Après cela la commande dpkg-reconfigure linux-image-2.6.3xxxx générait bien l’initrd :

$ sudo dpkg-reconfigure linux-image-2.6.30-mem Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs 2.6.30-mem /boot/vmlinuz-2.6.30-mem run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.30-mem /boot/vmlinuz-2.6.30-mem Running postinst hook script update-grub. . . .

Donc si on utilise les dernières versions de kernel-package, initramfs-tools, et que l’on compile son kernel avec génération d’un initrd penser à compléter les scripts dans /etc/kernel/postinst.d/ en piochant dans /usr/share/kernel-package/examples/*.

Accessoirement, en ce qui me concerne pour faire une petite modification sur un kernel officiel debian que je ne vais pas conserver longtemps je procède de la manière suivante :

$ apt-get source linux-source-2.6.31
$ cd linux-2.6-2.6.31/

Là je change le paramètre désiré (à noter qu’il n’est pas conseillé de changer ce paramètre) :
$ perl -i -p -e ’s/CONFIG_STRICT_DEVMEM=y/CONFIG_STRICT_DEVMEM=n/g;’ debian/config/kernelarch-x86/config

Puis je reprends la procédure :

$ fakeroot debian/rules
$ cd ..
$ fakeroot make -f debian/rules.gen binary-arch_i386_none_686
$ ls ../*deb
../linux-headers-2.6.31-1-686_2.6.31-1_i386.deb ../linux-image-2.6.31-1-686_2.6.31-1_i386.deb
$ sudo dpkg -i ../*.deb

cep

Topics : Général, debian | Pas de commentaire »

aptitude Method rred

posté par cep le 4 novembre 2009

Ce matin il m’était impossible de faire les mises à jour. La commande aptitude update tout comme apt-get update se terminaient toujours par ce message d’erreur :

E: Method rred has died unexpectedly!
E: Le sous-processus rred a commis une violation d’accès mémoire

La solution trouvée pour récupérer la liste des paquets à mettre à jour a été de lancer la commande aptitude update avec l’option -o Acquire::Pdiffs=false :

:~# aptitude update -o Acquire::Pdiffs=false

Avec cette option on ne récupérée pas simplement la liste des paquets ayant été modifiés mais la totalité de la liste. Cela a bien sûr pour conséquence d’augmenter l’utilisation de la bande passante sur les miroirs.

Pour plus de détails sur cette option voir :

http://www.debian-administration.org/article/Avoiding_slow_package_updates_with_package_diffs

Curieusement, après avoir fait mon aptitude update une fois avec cette option, les autres “updates” se sont déroulés normalement sans avoir à entrer à nouveau ce paramètre.

cep

Topics : Général, debian | 2 Commentaires »

grub 2 et multiboot linux

posté par cep le 15 octobre 2009

Si vous possédez deux distributions linux sur le même pc, avec un grub installé dans le mbr et un second dans le secteur de boot d’une autre partition, lors de la mise à jour du noyau de la deuxième distribution le menu grub.cfg de la première distribution ne sera pas mis à jour, et donc ne portera pas les références de ce nouveau noyau.

Afin de pouvoir toujours démarrer ce nouveau noyau depuis le grub du mbr il est possible de créer un “script simplifié” dans le fichier /etc/grub.d/40_custom , fichier qui est lu à chaque update-grub pour configurer /boot/grub/grub.cfg.

Par exemple pour pouvoir lancer debian squeeze installé dans la deuxième partiton du disque 1, il faudra modifier le fichier /etc/grub.d/40_custom dans la première distribution dont le grub est installé dans le mbr, et y ajouter :

menuentry “lancement squeeze” {
set root=(hd0,2)
configfile /boot/grub/grub.cfg
}

Il est possible aussi de supprimer le lancement de os-prober afin de ne plus avoir dans grub.cfg toute une série de lignes de kernels de l’autre distribution. Pour cela ajouter dans le fichier /etc/default/grub les lignes :

# désactiver os_prober
GRUB_DISABLE_OS_PROBER=”true”

Après avoir fait ces modifications lancer la commande update-grub pour que grub.cfg soit reconfiguré.

Il est possible de faire cela sur chacune des distributions installées.

cep

p.s. si grub n’est pas dans /boot sur / mais dans une partition dédiée il faudra adapter l’adresse grub/grub.cfg

Topics : Général, debian, linux | 3 Commentaires »