Ashram de Swâmi Petaramesh - Ubuntu

Noyau 2.6.27 Ubuntu custom pour Acer Aspire One

Petaramesh — Mon, 01 Sep 2008 17:07:00 +0200

Tout chaud sorti du four, un beau noyau 2.6.27 Ubuntu custom pour votre Acer Aspire One !

Non, ce billet ne bégaie pas, c'est la même chose, mais dans une version plus récente ;-)

(Hé non les filles, le billet de fesses est encore reporté à une date ultérieure ;-)

Mis à jour le 09/09/2008

Et c'est donc enfin un 2.6.27 Ubuntu qui supporte l'ensemble des périphériques de l'Acer Aspire One :

Noyau allégé de tout ce qui est inutile sur un Aspire One.
Optimisé pour cette architecture.
Boote plus vite qu'un noyau Ubuntu de série à configuration identique.
Compilé aussi largement que possible de manière statique, économisant les chargements de modules, et permettant théoriquement (je n'ai pas testé) de booter sans utiliser l'initramfs pour un boot encore nettement plus rapide.
Inclut le support du Wi-Fi de l'Aspire One sans rien devoir installer d'autre, avec le module ath5k et non plus le module MadWifi.^[1] ^[2]
Inclut le pilote jmb38x_ms du lecteur de cartes multifonction et devrait supporter les memory stick.^[3]
Inclut le support alsa du son, qui fonctionne.
Inclut le module uvcvideo : La webcam fonctionne.
Bref, y'a tout qui fonctionne parfaitement chez moi à l'exception dérisoire du voyant du Wi-Fi, mais je ne garantis rien chez vous ;-)

Installation :

Télécharger les fichiers attachés (noyau, headers), puis :

sudo dpkg -i --force-overwrite linux-image-2.6.27-a1sp008_2.6.27-a1sp008-10.00.Custom_i386.deb linux-headers-2.6.27-a1sp008_2.6.27-a1sp008-10.00.Custom_i386.deb

Eteindre (normalement) la machine, la redémarrer, sélectionner le nouveau noyau.

Le fichier de config (qui m'a donné bien de la peine) est également joint pour les curieux qui voudraient l'examiner sans installer le noyo :-}

Vos retours et commentaires sont les bienvenus.

Addendum 06/09 : Le pilote Wi-Fi ath5k fonctionne, mais pas toujours. Il arrive qu'il ne parvienne pas à démarrer la carte Wi-Fi et se mette à bouffer 100% des ressources du système en essayant de le faire (???).

J'ai donc compilé un nouveau noyo 2.6.27-a1sp010 (ci-dessous) presque semblable au précédent, mais qui comporte à la fois le pilote ath5k et le pilote MadWifi,^[4] permettant de choisir aisément lequel on veut utiliser, et avec de plus le pilote acer_wmi que j'avais précédemment oublié (Ooops ;-)

L'installation se fait comme pour le précédent. Ensuite :

Si on veut utiliser le pilote MadWifi ^[5] :
- Mettre dans le fichier /etc/modules une ligne "ath_pci"
- Mettre dans le fichier /etc/modprobe.d/blacklist-local une ligne "blacklist ath5k"
- Eteindre la machine, puis la rallumer
- L'interface Wi-Fi s'appellera alors ath0

Si on veut utiliser le pilote ath5k :
- Mettre dans le fichier /etc/modules une ligne "ath5k"
- Mettre dans le fichier /etc/modprobe.d/blacklist-local une ligne "blacklist ath_pci"
- Eteindre la machine, puis la rallumer
- L'interface Wi-Fi s'appellera alors wlan0

Comme ça, chacun peut utiliser le pilote de son choix ;-)

Addendum 09/09 : Noyau 2.6.27-a1sp011, en attachement. Pratiquement identique au 2.6.27-a1sp010, mais compilé avec l'option "CONFIG_MMC_UNSAFE_RESUME=y" permettant de conserver (à vos risques et périls) le montage de la carte SD après une suspension / réveil.

N.B. : Les signatures GnuPG de tous mes noyaux et fichiers de config sont disponibles aux mêmes URLs que les fichiers eux-mêmes, en y ajoutant simplement pour chacun l'extension ".asc"

Notes

[1] Il faut donc charger le module ath5k...

[2] On perd au passage (temporairement ? ;-) la gestion de la LED Wi-Fi.

[3] Je n'en ai pas, donc je n'ai pas essayé.

[4] madwifi-hal-0.10.5.6-r3861-20080903

[5] La LED Wi-Fi pourra alors être utilisée

Noyau "Ubuntu" custom pour Acer Aspire One

Petaramesh — Sun, 24 Aug 2008 15:57:00 +0200

Tout chaud sorti du four, un beau noyau Ubuntu custom pour votre Acer Aspire One !

Billet mis à jour le 29/08/2008 : Noyau 2.6.24-19-a1sp010, très légèrement amélioré par rapport au précédent.

Voici donc le premier que j'ose sortir en public ;-)

Noyau allégé de tout ce qui est inutile sur un Aspire One.
Optimisé pour cette architecture.
Boote (au moins) 10 secondes plus vite qu'un noyau Ubuntu de série à configuration identique.
Compilé aussi largement que possible de manière statique, économisant les chargements de modules, et permettant théoriquement (je n'ai pas testé) de booter sans utiliser l'initramfs pour un boot encore nettement plus rapide.
Inclut le support du Wi-Fi de l'Aspire One sans rien devoir installer d'autre.
Fonctionne parfaitement chez moi, mais je ne garantis rien chez vous ;-)

Manque :

Le module uvcvideo de support de la webcam, qu'il faudra que je compile séparément par la suite (autrement dit, la webcam ne fonctionnera pas avec ce noyau seul)

Installation :

Télécharger les fichiers attachés (noyau, headers), puis :

sudo dpkg -i linux-image-2.6.24-19-a1sp010_2.6.24-19-a1sp010-10.00.Custom_i386.deb linux-headers-2.6.24-19-a1sp010_2.6.24-19-a1sp010-10.00.Custom_i386.deb

Eteindre (normalement) la machine, la redémarrer, sélectionner le nouveau noyau.

Le fichier de config (qui m'a donné bien de la peine) est également joint pour les curieux qui voudraient l'examiner sans installer le noyo :-}

Vos retours et commentaires sont les bienvenus.

Une clé de contact pour votre portable chiffré : Version 1.6

Petaramesh — Mon, 21 Jul 2008 23:12:00 +0200

Ce billet est là uniquement pour signaler une mise à jour du script bootkeyscript proposé dans mon précédent billet "Une clé de contact pour votre portable chiffré".

Avec la version 1.6, il est désormais possible de spécifier la partition où se trouve le fichier-clé déverrouillant le système, non seulement par son device (i.e. sdb1) mais également par son label de filesystem ou son UUID,^[1] ce qui permet d'utiliser une fichier-clé sur un périphérique dont le nom est susceptible de changer d'une fois sur l'autre.

Notes

[1] Si le filesystem contenant le fichier-clé est chiffré LUKS, il est seulement possible d'utiliser l'UUID du conteneur LUKS, mais pas le label ou l'UUID du filesystem qui est à l'intérieur.

Installation de KUbuntu sur un Acer Aspire One

Petaramesh — Wed, 16 Jul 2008 16:31:00 +0200

L'Aspire One est décidément une délicieuse petite machine dont je suis enchanté d'être l'heureux propriétaire.

Ce qui ne gâche rien, une Kubuntu 8.04 Hardy Heron y tourne comme une horloge.

Petit tutorial d'installation, non-geeks passez votre chemin ;-)

==> Billet mis à jour le 15 août 2008

Avertissement

Mon Aspire One souffre d'un bug de BIOS majeur : Le réglage dans le BIOS d'un "mot de passe superviseur" rend ensuite tout accès au BIOS impossible : le mot de passe est refusé dans tous les cas de figure. Seule solution, supprimer le mot de passe, mais si vous vous êtes arrangé entre-temps pour rendre votre machine imbootable, vous serez totalement coincé. Je vous déconseille donc fortement de définir un mot de passe dans le BIOS, et encore davantage avant d'avoir terminé l'installation de votre système d'exploitation.

Update 17/07 12:34 : Je me suis souvenu d'un vieux BIOS qui m'avait fait le même coup dans le temps, et j'ai finalement réussi à régler un mot de passe BIOS "superviseur" qui fonctionne en n'utilisant que des chiffres de la rangée du haut du clavier, sans la touche [Majuscule] - puisque c'est du QWERTY lors du boot, et que l'emploi de la touche [Majuscule] n'est vraiment pas conseillé avec les mots de passe de BIOS...

Créer le support d'installation

Télécharger une image ISO de CD Kubuntu Desktop live standard, et la transférer sur une clé USB rendue bootable avec l'utilitaire isotostick.sh.

Installation de Kubuntu

Démarrer normalement l'installation de Kubuntu, en choisissant le partitionnement manuel du disque SSD.

J'ai personnellement installé ça sous forme entièrement chiffrée avec clé de contact, mais je décris ici une installation plus ordinaire.

Suggestion de partitionnement du disque SSD:

sda1 : /boot, ext2, 96 Mo
sda2 : / (racine du filesystem), ext2, toute la place disponible moins 1 Go (le disque est trop petit pour qu'il soit sensé de perdre de la place en créant de multiples partitions...)
sda3 : Swap, 1 Go

On utilisera un filesystem ext2 plutôt qu'ext3 sur le SSD pour économiser les écritures de journal, lentes sur ce périphérique, et susceptible de l'user plus rapidement (les mémoires flash utilisées pour les disques SSD ayant un nombre de cycles d'écriture limité).

Installer ensuite normalement.

Après installation d'une Ubuntu / Kubuntu standard, les seules choses qui ne marchent pas sur l'Acer Aspire One sont :

Le Wi-Fi
Les lecteur de cartes mémoires

...ce qui est quand même embêtant.

Premières modifications

/boot/grub/menu.lst : Sélection du timer

On accélérera légèrement le boot en spécifiant le timer correct à utiliser : "clocksource=hpet" à ajouter tant dans la ligne pseudo-commentée "defoptions" que dans les lignes "kernel" correspondant à chaque noyau.

# defoptions=clocksource=hpet quiet splash

...

kernel /vmlinuz-2.6.24-19-generic root=/dev/sda2 ro clocksource=hpet quiet splash

Update 12/08/2008 : De même, on commencera à résoudre (partiellement...) le problème du SSD lent de l'Aspire One en réglant le noyau pour l'utilisation de l'IO scheduler "deadline", en ajoutant, dans le même fichier menu.lst, tant dans la ligne pseudo-commentée "kopt" que dans les lignes "kernel" correspondant à chaque noyau :

# kopt=root=/dev/sda2 ro elevator=deadline

...

kernel /vmlinuz-2.6.24-19-generic root=/dev/sda2 ro elevator=deadline clocksource=hpet quiet splash

Script de gestion du lecteur de cartes SD JMicron

J'ai récupéré le script jmb38x_d3e.sh sur la Linpus Linux fournie avec la machine.
Installer ce script dans le répertoire /usr/local/sbin, et le rendre exécutable (chmod 754 /usr/local/sbin/jmb38x_d3e.sh). Nous l'utiliserons par la suite.

Accélération de l'accès au disque SSD

(Paragraphe ajouté le 12/08/2008, modifié le 14/08)

Le disque SSD de l'Aspire One étant notoirement et tristement lent, ce qui se manifeste par des "blocages" périodiques du système de quelques secondes durant les phases d'écriture intense, nous allons tenter d'optimiser la méthode d'accès à ce disque.

Les paramètres que je propose ci-dessous sont encore expérimentaux, je les modifie régulièrement un peu ici ou là pour tenter d'améliorer les performances autant que faire se peut. Vous pouvez tester vos propres valeurs, celles-ci sont assez efficaces...

Pour cela, créons un script /usr/local/sbin/slowvm.sh dans lequel nous mettrons :

#! /bin/bash
#
# Swami Petaramesh, 2008/08/14
#
# slowvm.sh (pour Acer Aspire One)

# Controle de la LED Wi-Fi de l'Aspire One
echo 3 >/proc/sys/dev/wifi0/ledpin
echo 3 >/proc/sys/dev/wifi0/softled

# SP : Economisons le SSD
sysctl -q -w vm.swappiness=1            # Strongly discourage swapping
sysctl -q -w vm.vfs_cache_pressure=50   # Don't shrink the inode cache aggressively

# Utilise l'I/O Scheduler "deadline" pour privilegier les lectures
# aux dépens des écritures sur le SSD lentissime de l'Aspire One
echo deadline >/sys/block/sda/queue/scheduler
echo 512 >/sys/block/sda/queue/read_ahead_kb
echo 256 >/sys/block/sda/queue/nr_requests
echo 0 >/sys/block/sda/queue/iosched/front_merges
echo 50 >/sys/block/sda/queue/iosched/read_expire
echo 15000 >/sys/block/sda/queue/iosched/write_expire
echo 128 >/sys/block/sda/queue/iosched/writes_starved

# Evite les ecritures sur disque et les concentre
# mais pas trop...
echo 60 > /proc/sys/vm/dirty_ratio
echo 40 > /proc/sys/vm/dirty_background_ratio
echo 6000 > /proc/sys/vm/dirty_expire_centisecs
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

exit 0

Rendons maintenant ce script exécutable : chmod 755 /usr/local/sbin/slowvm.sh

Modification de `/etc/rc.local`

(Paragraphe mis à jour le 12/08/2008)

Nous allons ajouter à la fin de /etc/rc.local (avant la ligne "exit 0") un ensemble d'instructions destinées à diminuer les écritures sur le disque SSD (par appel du script précédent), économiser l'énergie pour augmenter l'autonomie de batterie, et activer le lecteur de cartes mémoire.

Ajouter les lignes :

# SP : Economisons le SSD
/usr/local/sbin/slowvm.sh

# SP: d'apres le rc.last.ctrl de Linpus
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

[ -L /sys/bus/usb/devices/1-5/power/level ] && echo auto > /sys/bus/usb/devices/1-5/power/level
[ -L /sys/bus/usb/devices/5-5/power/level ] && echo auto > /sys/bus/usb/devices/5-5/power/level

# SP: Accelere l'hibernation et reduit la taille de l'image
echo 0 > /sys/power/image_size

# SP: D'apres Linpus, pour lecteur de carte MMC multiformat
setpci -d 197b:2381 AE=47
nice /usr/local/sbin/jmb38x_d3e.sh &

# SP: D'apres Linpus
/usr/bin/setkeycodes e025 130
/usr/bin/setkeycodes e026 131
/usr/bin/setkeycodes e027 132
/usr/bin/setkeycodes e029 133
/usr/bin/setkeycodes e071 134
/usr/bin/setkeycodes e072 135
/usr/bin/setkeycodes e055 159
/usr/bin/setkeycodes e056 158
# /SP

Réglages ACPI

(Paragraphe ajouté le 12/08/2008, mis à jour le 15/08)

Nous allons enfin appeler le script /usr/local/sbin/slowvm.sh lorsque le système passe sur batterie ou sur secteur, faute de quoi le noyau pourrait remettre des valeurs par défaut moins performantes. Pour cela, créons simplement des liens symboliques :

ln -sv /usr/local/sbin/slowvm.sh /etc/acpi/ac.d/99-slowvm.sh
ln -sv /usr/local/sbin/slowvm.sh /etc/acpi/battery.d/99-slowvm.sh
ln -sv /usr/local/sbin/slowvm.sh /etc/acpi/resume.d/99-slowvm.sh

Modification de `/etc/sysctl.conf`

(Paragraphe mis à jour le 14/08/2008)

Ajouter les lignes suivantes à la fin de /etc/sysctl.conf :

# decrease swap usage to maximize SSD life
vm.swappiness = 1
# Don't shrink the inode cache aggressively
vm.vfs_cache_pressure = 50

# Controle de la LED Wi-Fi de l'Aspire One
dev.wifi0.ledpin = 3
dev.wifi0.softled = 3

Modification de `/etc/initramfs-tools/modules`

Ajouter les lignes :

fuse
softcursor
bitblit
font
tileblit
fbcon
fan
processor
thermal
usbcore
uhci_hcd
ehci_hcd
libata
ata_generic
ata_piix
pata_acpi
scsi_mod
sd_mod
sg
usb_storage
mmc_block
sdhci
mmc_core
pci_hotplug
pciehp
dm_mod
dm_crypt
blkcipher
cbc
aes_i586
sha256_generic
mbcache
ext2
pcspkr
button
battery
ac
wmi_acer
evdev
led_class
acer_acpi
cpufreq_conservative
freq_table
cpufreq_ondemand
cpufreq_powersave
cpufreq_stats
cpufreq_userspace
acpi_cpufreq
r8169

Modificaton de `/etc/initramfs-tools/initramfs.conf`

Modififier la ligne "MODULES=most" en "MODULES=dep"

Régénération de l'initramfs

Exécuter : sudo update-initramfs -u

Redémarrer ensuite la machine.

Son

Pour que le son continue de fonctionner après réveil d'une suspension ou d'une hibernation, ajouter à la fin du fichier /etc/modprobe.d/alsa-base la ligne :

options snd-hda-intel model=acer

(Merci à "EricNevers" pour cette info donnée dans le commentaire #52 et que j'inclus au billet pour plus de visibilité)

Webcam

La webcam doit fonctionner. Elle peut être essayée facilement avec le programme "ucview" que l'on peut installer comme suit :

wget -q http://www.unicap-imaging.org/downloads/public.key -O- | sudo apt-key add -

Ouvrir ensuite le gestionnaire de paquetages Adept, choisir de modifier les dépôts, et dans les "dépôts logiciels de tierces-parties", ajouter la ligne :

deb http://unicap-imaging.org/packages hardy main contrib

Installer ensuite le package "ucview". On pourra alors faire joujou avec la webcam.

Wi-Fi Atheros

(Paragraphe mis à jour le 12/08/2008)

L'Aspire One est équipé d'une carte Wi-FI Atheros AR5BXB63 (selon l'étiquette collée dessous) qui fait partie de la famille AR5007, présente sur de très nombreux portables et connue pour ne pas fonctionner brute de décoffrage sous Ubuntu.

Elle est reconnue par "lspci" comme :

Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)

...et avec "lspci -n" :

03:00.0 0200: 168c:001c (rev 01)

Il faudra compiler un package madwifi spécialement patché, à partir de ses sources : madwifi-hal-0.10.5.6-r3835-20080801 , que l'on se procurera ici : http://snapshots.madwifi.org/madwifi-hal-0.10.5.6/

Installer d'abord les package "build-essential" et "libc6-dev":

sudo aptitude install build-essential libc6-dev

Décompresser l'archive madwifi-hal-0.10.5.6-r3835-20080801 dans un répertoire de son choix, et se rendre (comme "root", après "sudo -s") dans le répertoire obtenu, puis :

cd scripts
./madwifi-unload
./find-madwifi-modules.sh -r
cd ..
make install

Une fois ceci fait, rebooter la machine, ensuite de quoi le Wi-Fi devrait fonctionner.

Conservez le répertoire source de madwifi sur la machine : à chaque fois que vous mettrez à jour votre noyau, ceci écrasera vos pilotes Wi-Fi, et il faudra en refaire alors l'installation, ce qui ne prend que quelques instants.

(Paragraphe partiellement modifié à la suite d'un commentaire #51 de "geo92".)

Lecteurs de cartes mémoires

L'Aspire One est équipé d'un lecteur JMicron JMB38X :

04:00.0 System peripheral: JMicron Technologies, Inc. Unknown device 2382
        Subsystem: JMicron Technologies, Inc. Unknown device 2382
        Flags: fast devsel, IRQ 255
        Memory at 74100000 (32-bit, non-prefetchable) [disabled] [size=256]
        [virtual] Expansion ROM at 73100000 [disabled] [size=64K]
        Capabilities: [a4] Power Management version 3
        Capabilities: [80] Express Endpoint IRQ 0
        Capabilities: [94] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-

04:00.2 SD Host controller: JMicron Technologies, Inc. Unknown device 2381 (prog-if 01)
        Subsystem: JMicron Technologies, Inc. Unknown device 2381
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at 74100100 (32-bit, non-prefetchable) [size=256]
        Capabilities: [a4] Power Management version 3
        Capabilities: [80] Express Endpoint IRQ 0
        Capabilities: [94] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-

04:00.3 System peripheral: JMicron Technologies, Inc. Unknown device 2383
        Subsystem: JMicron Technologies, Inc. Unknown device 2383
        Flags: fast devsel, IRQ 255
        Memory at 74100200 (32-bit, non-prefetchable) [disabled] [size=256]
        Capabilities: [a4] Power Management version 3



        Capabilities: [80] Express Endpoint IRQ 0
        Capabilities: [94] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-

04:00.4 System peripheral: JMicron Technologies, Inc. Unknown device 2384
        Subsystem: JMicron Technologies, Inc. Unknown device 2384
        Flags: fast devsel, IRQ 255
        Memory at 74100300 (32-bit, non-prefetchable) [disabled] [size=256]
        Capabilities: [a4] Power Management version 3
        Capabilities: [80] Express Endpoint IRQ 0
        Capabilities: [94] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-

Malheureusement, le module pilote de ce lecteur n'est disponible qu'à partir des noyaux 2.6.25, or Ubuntu Hardy possède un noyau 2.6.24.
Le noyau Linux Linpus fourni avec l'Acer Aspire One est un noyau spécialement patché pour y ajouter ce module, mais je n'ai pas réussi à en trouver le code source.^[1]
J'ai fait des essais peu concluants avec des noyaux 2.6.26, y compris des essais de compilation de noyaux custom, mais le module jmb38x obtenu semble différent et moins complet que celui fourni avec l'Aspire One.

Quoiqu'il en soit, avec les modifications déjà indiquées plus haut, les lecteurs de cartes SD devraient fonctionner (ils fonctionnent chez moi) avec le pilote sdhci, mais il sera probablement impossible de lire des Memory sticks ou des cartes XD dans le lecteur multiformat. Je n'ai pas essayé : je n'en avais pas sous la main.

A noter une particularité des lecteurs JMicron : Il s'agit de lecteurs PCI Hotplug, qui ne sont pas visibles dans lspci tant qu'une carte n'a pas été insérée dedans.

Pour une raison foireuse quelconque (probablement le manque du pilote jmb38x complet), seul le premier lecteur dans lequel une carte est insérée sera reconnu. Si on insère une carte dans le deuxième lecteur, pour que les deux cartes soient simultanément reconnues, il faudra faire :

sudo rmmod sdhci
sudo modprobe sdhci

Attention, la première carte ne doit pas être "montée" quand on fait cela !

Installer une extension mémoire d'un Go

Bien qu'Ubuntu puisse tourner dans 512 Mo de RAM, on est quand même beaucoup plus confortable avec plus, et surtout, on sollicitera moins le swap, ce qui rendra la machine plus rapide et ménagera la durée de vie du disque SSD, pour une vingtaine d'Euros et quelques dizaines de minutes de pure terreur et de sueurs froides ;-)

L'installation d'une extension mémoire sur cette machine est extrêmement délicate, puisqu'elle nécessite le démontage intégral de la machine et la dépose de sa carte mère. Les connecteurs ZIF qu'il sera nécessaire de débrancher pour cela sont minuscules et extrêmement fragiles, il faut faire pivoter leur partie marron vers le haut et non pas la tirer dans le sens de la nappe pour déconnecter les nappes. Le démontage est risqué et annule certainement la garantie de la machine, vous avez été prévenu ! Ne venez pas pleurer chez moi si vous massacrez votre Aspire One tout neuf !

J'ai installé dans cette machine une barrette de SO-DIMM Kingston 1 Go PC-5300 (667 MHz) qui est impeccablement supportée.^[2]

On peut trouver chez blogeee.net d'intéressantes photos de la machine démontée ...mais pas la manière de le faire.

Mode d'emploi :

Retirer la batterie.
Déposer le clavier : C'est une des étapes très délicates, et difficile à faire sans un peu "marquer" la machine. A l'aide d'un tournevis plat très fin, repousser les trois "clips" qui tiennent le clavier en haut de celui-ci, et dégager soigneusement le haut du clavier, puis le retirer. Déconnecter sa nappe du connecteur ZIF en basculant très délicatement la partie marron de celui-ci vers le haut. C'est plus que fragile !
Déposer les vis sous le boîtier : Déposer toutes les vis visibles. Attention, cette machine est montée avec de vis de nombreuses tailles différentes. En démontant, prendre soin de bien noter "quelle vis va dans quel trou". Il y a trois vis dans le compartiment de batterie, et deux sous les patins caoutchouc ("pieds") arrières de la machine (côté charnière de l'écran), que l'on pourra ensuite recoller si on les a très soigneusement décollés.
Ouvrir à nouveau la machine, et ôter toutes les vis situées sous l'emplacement du clavier et repérées par un triangle. Une de ces vis est couleur inox. Là aussi, bien noter quelle vis allait dans quel trou !
Déconnecter extrêmement soigneusement la nappe de connexion du touchpad de son connecteur ZIF.
Déclipser ensuite le haut du boîtier, et l'ouvrir.
Démonter la vis retenant la carte Wi-Fi, et déconnecter celle-ci.
Déconnecter très soigneusement la nappe de la carte fille de son connecteur ZIF.
Débrancher le connecteur du câble audio.
Ôter les vis restantes retenant la carte mère de manière à pouvoir soulever celle-ci.
Il n'est pas nécessaire d'enlever complètement la carte mère, seulement de pouvoir la soulever assez pour pouvoir insérer la barrette de RAM dans son slot, situé dessous.
Remonter ensuite l'ensemble dans l'ordre inverse des opérations. Veiller à bien ranger le câble d'antenne Wi-Fi qui ne doit pas être sur les cartes, sinon on ne pourra pas refermer correctement la machine.

Et voilà une machine avec 1,5 Go de RAM !

C'est à peu près toutes les notes que j'avais sous le coude pour l'instant ;-)

Addendum 19 juillet : Les performances du SSD de l'Aspire One

Je trouve depuis le début le SSD de l'Aspire One assez lent, particulièrement en écriture, avec des "figés" périodiques de quelques secondes du système, voyant disque allumé fixe.
Ma configuration est particulière avec une installation entièrement chiffrée sur LVM LUKS, AES 128, et il n'est donc pas évident de faire la part des choses entre la vitesse intrinsèque du SSD et l'overhead imposé au processeur par le chiffrement / déchiffement à la volée.

À titre indicatif, voici ce que me donnent quelques essais en lecture / écriture :

Test de lecture hdparm

# hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   1186 MB in  2.00 seconds = 593.20 MB/sec
 Timing buffered disk reads:   76 MB in  3.06 seconds =  24.83 MB/sec

La vitesse de lecture de 24.83 MB/sec semble compatible avec ce que j'observe du fonctionnement de la machine, vitesse à laquelle il faut rajouter les avantages spécifiques au SSD : Temp de démarrage nul, temps de seek nul, ce qui donne des performances pratiques en lecture supérieures à celles de la plupart des disques durs traditionnels de portables.

Tests d'écriture réels (à travers la couche de chiffrement, donc avec l'overhead)

Création sur disque d'un fichier de 100 Mo

$ time dd if=/dev/zero of=dummy bs=1M count=100; time sync
100+0 enregistrements lus
100+0 enregistrements écrits
104857600 octets (105 MB) copiés, 0,337884 s, 310 MB/s

real    0m0.351s
user    0m0.004s
sys     0m0.336s

=> La machine "rend la main" au bout de 0,35 seconde

real    0m9.865s
user    0m0.008s
sys     0m0.004s

=> L'écriture réelle sur disque (vidage du cache du noyau) prend 9,67 secondes supplémentaires

Le débit global d'écriture sur disque SSD est donc de ~= 9,79 Mo/sec. pour une fichier de 100 Mo, chiffrement inclus.

Création sur disque d'un fichier de 1000 Mo

$ time dd if=/dev/zero of=dummy bs=1M count=1000; time sync
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 127,92 s, 8,2 MB/s

real    2m7.930s
user    0m0.012s
sys     0m3.716s

=> La machine "rend la main" au bout de 2 minutes 8 secondes. On voit qu'on a dépassé le cache en écriture du noyau (avec 1,5 Go de RAM), et qu'on est donc impacté par la vitesse d'écriture réelle sur le disque.

real    1m15.527s
user    0m0.000s
sys     0m0.008s

=> L'écriture réelle sur disque (vidage du cache du noyau) prend 1 minute 15 secondes supplémentaires.

Le débit global d'écriture sur disque SSD est donc de ~= 4.92 Mo/sec. pour une fichier de 1000 Mo, chiffrement inclus. On voit qu'on est deux fois plus lent qu'avec un fichier de 100 Mo, et que là, c'est vraiment lent. L'overhead de chiffrement ne semble pas impliqué directement dans la différence de vitesse, mais plutôt simplement le fait d'avoir débordé le cache du noyau.
Il est également possible que les algorithmes de wear levelling du disque SSD entrent en ligne de compte, puisqu'ils sont potentiellement suceptibles de doubler le nombre d'écritures réelles sur le disque SSD (déplacement de blocs durant l'écriture).

Notes

[1] ...qui devrait être fourni par Acer par respect des obligations imposées par la GPL...

[2] D'après ce que j'ai lu ici ou là, mais non vérifié personnellement, une barrette supplémentaire d'1 Go de RAM est la taille maximale supportée par le BIOS de la machine.

Pôôôôôôôôôô !

Petaramesh — Sun, 01 Jun 2008 19:56:00 +0200

Après une matinée de distribution de tracts au marché sous une pluie battante, je me suis fait cet après-midi le grand plaisir annuel de la déclaration des pôôôôs accompagné du tri spécial années bissextiles de l'infâme pile de paperasses et des immondes boîtes d'archives... Rien que du bonheur !

Alors au passage un petit tuyau si jamais l'envie (enfin, l'envie...) vous prend de déclarer vos pôôôôôs en utilisant Firefox 3 Bêta sur une Ubuntu 8.04 Hardy.

En effet, le site du père Cepteur commencera par vous dire que votre navigateur n'est "peut-être pas compatible'' avant de cependant vous laisser continuer sans problème.

C'est seulement au moment de signer avec votre sang et votre certificat numérique la déclaration terminée que ça se corsera et que le système se coincera, si vous utilisez le Java 6 de Sun.

Pas de panique cependant, il vous suffit de désinstaller, éventuellement temporairement, le Java 6, d'installer le Java 5 et de recommencer. Le père Cepteur aura même eu la gentilesse de se souvenir de ce que vous aviez tapé, vous n'aurez donc plus qu'à faire "Suivant... Suivant... Suivant..." et à signer enfin en bas.

Pour désinstaller le Java 6 et passer au Java 5, il vous suffit en console root de...

aptitude purge sun-java6-plugin
aptitude install sun-java5-plugin

Une fois les pôôôôôs potames, pour désinstaller le Java 5 et réinstaller le java 6...

aptitude purge sun-java5-plugin sun-java5-jre sun-java5-bin
aptitude install sun-java6-plugin

...et la blague est faite.

Sinon mon p'tit bonhomme de même pas 6 ans est en larmes parce que sa petite amoureuse qui a passé la nuit à la maison est partie et qu'il ne la reverra pas avant demain matin... Ces deux-là sont salement accrochés :-}

Hibernatus

Petaramesh — Wed, 28 May 2008 18:03:00 +0200

Depuis que les CNILonautes ont été placés en hibernation dans leur caisson cryogénique en 1978 et n'en sont jamais ressortis, l'idée a fait son chemin.

C'est ainsi que désormais, Ubuntu gère très convenablement l'hibernation (et la suspension) des ordinateurs portables. Mais qu'est-ce donc ?

Les ordinateurs portables fonctionnant sur de misérables petites batteries pouilleuses, leur autonomie est fortement limitée. On a donc cherché dès l'origine à augmenter cette autonomie par diverses méthodes, la plus évidente étant de mettre en "veille" ou d'éteindre l'ordinateur dès qu'on ne l'utilise pas.

Eteindre l'ordinateur et le rallumer pose cependant deux problèmes :

Celui du temps nécessaire à l'extinction complète et au redémarrage (boot, ouverture de session...)
Celui de pouvoir retrouver les choses dans l'état exact où on les avait laissées (connexions réseau, affichage, documents ouverts...)

En l'absence de solution à ces problèmes, devoir éteindre et rallumer un ordinateur représente une importante perte de temps et est donc peu praticable.

Des méthodes "améliorées" ont donc été mises au point, et leur usage n'est d'ailleurs pas limité aux seuls ordinateurs portables - on peut très bien les utiliser avec une machine de bureau pour en limiter autant que possible la consommation électrique quand on ne s'en sert pas, par exemple.

Les versions récentes de GNU/Linux gèrent très bien ces méthodes sur les ordinateurs dont le matériel (ACPI) (et les périphériques !) les supportent, et Ubuntu Hardy sait aussi bien effectuer la suspension que l'hibernation des 3 modèles très différents de portables sur lesquels je les ai essayées.

La suspension "en RAM"

La suspension en RAM est la méthode la plus rapide, mais la moins complète. Elle consiste à placer les périphériques du système ^[1] soit :

Dans un état de "sommeil" à très faible consommation d'énergie
ou complètement hors-tension
ou à les laisser en fonction

...selon ce que chaque périphérique et le BIOS de la machine permettent, puis à interrompre le fonctionnement du processeur, laissant uniquement la mémoire RAM alimentée et rafraîchie, ce qui consomme très peu d'énergie.

Dans cet état, l'autonomie de la batterie du portable peut passer de quelques heures à plusieurs jours ; toutefois la machine n'est pas "éteinte" et continue de consommer. Une fois la batterie complètement vide, elle s'éteindra "pour de bon" ce qui aura sur le système un effet à peu près équivalent à ce qu'aurait eu une coupure de courant brutale, à ceci près que l'état des systèmes de fichiers sera meilleur au redémarrage (puisque les systèmes de fichiers auront été "synchronisés" juste avant la mise en suspension et qu'aucune écriture sur disque ne pouvait être en cours durant la suspension).

Le "réveil" de la machine depuis l'état de suspension est rapide (quelques secondes), puisque la mémoire RAM est restée chargée. Il n'y a pas de "boot" à faire ; le système doit "seulement" redémarrer son processeur et remettre les périphériques dans leur état de fonctionnement antérieur - ce qui est la partie le plus longue et la plus susceptible de causer des problèmes.

L'"hibernation" sur disque

L'hibernation sur disque est une méthode complète qui permet de réellement éteindre la machine, lui permettant de demeurer en l'état sans consommation électrique pour une durée indéfinie.
La mise en hibernation commence par la suspension de l'exécution de toutes les tâches en cours, puis l'enregistrement de l'état actuel des périphériques (quand cela est possible), puis la "compression" du contenu de la mémoire RAM suivie de l'écriture de cette "image mémoire compressée" dans la partition de swap. Une fois tout ceci fait, la machine est alors (complètement) éteinte et peut donc rester dans cet état indéfiniment.

Le "réveil" de la machine depuis l'état d'hibernation est plus long et plus complexe que pour la simple suspension. Pour le BIOS de l'ordinateur, c'est d'abord une mise en route "ordinaire", le chargement du bootloader (grub, lilo...), suivi du chargement de l'initramfs et du démarrage du noyau. Ça commence donc réellement comme un boot ordinaire.

Ensuite, le programme "resume" est appelé et decouvre la présence de l'image mémoire compressée dans la partition de swap. Le programme resume prend alors le pas sur la séquence de démarrage habituelle, il recopie et décompresse l'image mémoire sauvegardée en RAM, réinitialise les périphériques à partir de leur état sauvegardé (un peu comme lors d'un réveil de suspension), puis reprend l'exécution à partir de l'image restaurée en mémoire : l'ordinateur se trouve alors (théoriquement) dans l'état exact qui était le sien juste avant la mise en hibernation : utilisateur connecté, systèmes de fichiers montés, connections réseau, applications et fichiers ouverts, etc.^[2]

N.B.: Il est possible de booter normalement sans reprise une machine qui a été hibernée si l'on passe au noyau le paramètre de boot "noresume". Dans ce cas, la machine bootera "normalement" dans l'état qui aurait été le sien après avoir subi une coupure de courant brutale.

Problèmes techniques

Les plus gros problèmes rencontrés avec les systèmes de suspension ou d'hibernation sont ceux relatifs aux périphériques du système. En effet, en fonctionnement normal, ils ont été initialisés par le BIOS, puis par leur pilote, puis leur état a été éventuellement modifié par l'application qui les utilise, etc.
Au "réveil", l'application (qui n'a rien vu) s'attend à retrouver les périphériques dans l'état exact où ils étaient auparavant, sans avoir besoin de les initialiser à nouveau.
Ceci implique que le système de suspension / hibernation / réveil doit être en mesure de déterminer et enregistrer l'état précis de tous les périphériques (par exemple mode vidéo en cours, vitesse actuelle du port série, volume réglé sur la carte son, firmware chargé dans une carte Wi-Fi, etc...) avant de les éteindre, et de restaurer cet état précis au réveil, avant de rendre la main au fonctionnement normal du système. Or ce n'est pas toujours possible, certains périphériques (surtout les anciens ou ceux non prévus pour des ordinateurs capables d'hibernation) étant capables d'exécuter une commande de changement d'état, mais incapables de faire un "rapport" de leur état courant au système. D'autres périphériques peuvent avoir des états tellement complexes (carte vidéo) qu'il n'est pas forcément possible de récupérer l'ensemble des informations nécessaires.
On peut alors rencontrer des problèmes avec de tels périphériques,^[3] comme avoir un périphérique qui ne fonctionne plus au réveil, une image vidéo qui ne se rétablit pas complètement, une connexion réseau qui refuse de revenir, etc.
Ceci est d'autant plus vrai dans le mode hibernation, où les périphériques sont complètement éteints que dans le mode suspension où certains périphériques peuvent être placés en mode sommeil et conserver eux-mêmes leur "état" - ils ne sont pas complètement éteints.
De gros progrès ont été faits, et les suites logicielles d'hibernation et de réveil comportent des kyrielles de "méthodes spéciales" pour différents types de périphériques^[4] ; toutefois, il peut encore parfois demeurer des problèmes. Vous vous montrerez indulgent après avoir lu cet article ;-)

Pièges à prévoir

Problèmes liés à la suspension :
- Lors de la suspension, le système n'est pas complètement hors-tension. Il peut donc continuer à chauffer (et sur certains modèles, se décider à ventiler) dans certaines situations. De plus, il est possible que l'appui accidentel sur une touche^[5] provoque le réveil de la machine. Si vous enfermez votre portable suspendu dans une housse ou un sac et que celui-ci se réveille inopinément, ou chauffe, il risque de surchauffer et de griller faute de ventilation et par excès d'isolation ! Étudiez bien votre machine pour connaître son comportement avant de vous décider ou non à la trimballer suspendue dans un sac (ce que je fais sans problème régulièrement avec mon Asus EeePC par exemple).

Problèmes liés à l'hibernation :
- Pour pouvoir hiberner votre machine, vous devez disposer d'une partition de swap de taille appropriée, typiquement grosso-modo 2 fois la taille de la RAM de votre machine, et l'ensemble de vos périphériques doit accepter l'opération sans casse (faut essayer ;-)

Problèmes liés à la suspension et à l'hibernation :
- Retrait ou ajout de périphériques : Quand votre ordinateur est hiberné, et dans une certaine mesure, suspendu, il ne peut pas se rendre compte de l'ajout ou de la suppression de nouveaux périphériques (branchement ou débranchement d'un câble secteur, d'un bidule USB, etc). Il se peut qu'au réveil il ne puisse pas effectuer les actions nécessaires à ce changement dont il ne se sera pas aperçu (changement du mode de gestion d'énergie, prise en compte du nouveau périphérique...). Pour cette raison, je conseille, si vous prévoyez de déplacer votre portable après l'avoir suspendu ou hiberné, de toujours retirer les périphériques (cordon secteur, clés USB...) avant de le suspendre, et de toujours le réveiller complètement avant de les reconnecter, de manière à ce qu'il soit toujours dans le même état précis à l'endormissement et au réveil et qu'il prenne en compte les changements de périphériques alors qu'il est "pleinement réveillé".
- Systèmes de fichiers sur périphériques USB : À la suspension ou l'hibernation, le système perd le montage de tous les systèmes de fichiers sur périphériques USB, ce qui peut poser problème (perte de données) s'il y a des fichiers ouverts ou des caches non vidés pour ces périphériques. Il est donc conseillé de démonter et ôter les périphériques de stockage USB avant de suspendre ou d'hiberner. Sur les noyaux 2.6.24 et supérieurs, la fonction "usb persist" permet de résoudre le problème et de conserver les montages USB au réveil.^[6] Ceci marche particulièrement bien avec mon Asus EeePC pour conserver l'accès à sa carte mémoire SD à travers une suspension ou une hibernation.^[7]

Considérations de performances

Si la suspension et son réveil sont généralement très rapides, l'hibernation et son réveil peuvent prendre beaucoup de temps. Sur une machine relativement peu puissante, il peut être bien plus long de l'hiberner que de l'arrêter normalement, et bien plus long de la réveiller que de faire un démarrage normal "à froid".
Ceci remet fortement en question l'intérêt de l'hibernation puisqu'elle ne fait plus gagner aucun temps, et peut même en faire perdre, le seul intérêt demeurant alors est de retrouver le système dans l'état exact où on l'avait laissé, intérêt toutefois minoré par la capacité de KDE à restaurer au démarrage toutes les applications (ou presque) qui étaient en cours quand il a été arrêté.

Il y a moyen (voir plus bas) d'agir sur le temps de mise en hibernation, mais ce sera au prix de la vitesse et de la réactivité de la machine après son réveil.

En effet, une machine réveillée après hibernation se montrera pour un temps plus lente et moins réactive qu'une machine fraîchement bootée, notamment parce que son cache-disque et ses buffers auront été vidés et qu'une partie de sa mémoire aura été (et sera encore) swappée...

Considérations de sécurité

La suspension et l'hibernation peuvent avoir d'importantes conséquences sur la sécurité d'un portable, ne serait-ce que parce que toutes deux réveillent le système dans l'état où il était à sa mise en veille, toutes applications et documents ouverts, et notamment que l'utilisateur n'a pas besoin de rouvrir sa session en tapant son login et son mot de passe.
Normalement, une session graphique au réveil soit se retrouver en mode "verrouillé et économiseur d'écran activé", ce qui nécessite la frappe du mot de passe de l'utilisateur pour accéder à la session, mais j'ai vu des cas plus ou moins imprévisibles où la session n'était pas verrouillée au réveil.
D'éventuelles sessions ouvertes sur des "consoles texte" ne seront pas verrouillées au réveil de la machine.

La suspension d'une machine peut être considérée du point de vue de la sécurité comme strictement équivalente à laisser la machine allumée avec la session verrouillée par un économiseur d'écran, ce qui est une sécurité assez "moyenne", et encore faut-il que l'économiseur d'écran s'active effectivement...

L'hibernation d'une machine a des conséquences très différentes :
- Tout d'abord, l'hibernation d'une machine est compatible avec une installation sur un disque complètement chiffré (LVM chiffrée contenant également le swap), ce qui protège pleinement la machine pendant son hibernation si on est dans un tel cas de figure.
- Comme la machine doit booter avant de se réveiller, elle pourra être verrouillée par un éventuel mot de passe de BIOS (qui n'offre par ailleurs pas une sécurité bien grande).
- Si la machine est installée sur LVM chiffrée, il faudra déverrouiller la LVM (comme lors d'un boot normal) pour pouvoir réveiller une machine hibernée.

L'hibernation d'une machine au swap non chiffré pose de sérieux problèmes de sécurité !
- Pensez qu'au moment de la mise en hibernation, absolument tout ce qui se trouve en mémoire vive est copié sur le swap et y demeurera éventuellement un temps indéfini, y compris tous documents ouverts ainsi que des éléments qui sont d'habitude éventuellement protégés par le noyau pour ne pas être écrits sur le swap en fonctionnement normal, comme des clés de chiffrement, des mots de passe, etc...
- Le programme swsusp possède une fonction de chiffrement de l'image mémoire avec une "clé jetable", mais celle-ci ne semble pas active sur Ubuntu 8.04. Quoi qu'il en soit, cette fonction permet de rendre inutilisable ce qui avait été écrit sur le swap après le réveil de la machine, mais elle reste entièrement vulnérable pendant qu'elle est en état hiberné, puisque la clé de déchiffrement doit également être stockée dans le swap pour permettre le réveil de la machine. Ceci de mon point de vue proscrit l'usage de l'hibernation pour toute machine pouvant contenir des données confidentielles, sauf si l'hibernation est effectuée sur un swap situé à l'intérieur d'une LVM entièrement chiffrée.
- L'utilisation d'un swap dans une LVM chiffrée protège de ce problème, mais offre une sécurité moindre que celle apportée par un swap chiffré séparément par une clé aléatoire générée à chaque boot (ce qui est incompatible avec l'hibernation...). En effet, dans ce dernier cas, après chaque boot le contenu précédent du swap est irrémédiablement perdu pour tout le monde, tandis que dans le cas du swap en LVM chiffrée, celui qui obtiendrait par force ou par ruse la clé de déchiffrement de la LVM pourrait alors aller farfouiller également dans les anciens contenus du swap.

Résolution de problèmes

Si vous avez une machine qui vous dit swsusp: Not enough free memory quand vous tentez de l'hiberner, puis se réveille aussitôt, essayez :

echo 2048248 > /sys/power/image_size

...et recommencez.^[8]

Si vous trouvez que votre machine est bien trop longue à hiberner et à se réveiller, essayez :

echo 0 > /sys/power/image_size

...vous obtiendrez en contrepartie une machine qui hibernera plus vite mais sera plus lente pendant un temps après s'être réveillée.

Une fois que vous avez trouvé la commande qui vous convient, ajoutez-la une fois pour toutes dans /etc/rc.local.

Pour plus d'infos à ce sujet, installer le package linux-doc-2.6.24 et lire le document /usr/share/doc/linux-doc-2.6.24/Documentation/power/swsusp.txt.gz.

Voilà, on dira que ça sera tout pour cette fois ;-)

Notes

[1] Affichage, carte vidéo, carte réseau, modem, disques, contrôleurs de disque, contrôleurs USB, etc...

[2] Pour plus d'infos sur l'hibernation, installer le package linux-doc-2.6.24 et lire les documents /usr/share/doc/linux-doc-2.6.24/Documentation/power/swsusp*.

[3] En particulier certains périphériques qui utiliseraient des pilotes Windows via ndiswrapper risquent de ne pas aimer...

[4] Jetez donc un coup d'oeil au contenu des répertoires /etc/acpi/suspend.d et /etc/acpi/resume.d...

[5] Avec certains portables, cela peut se produire si on appuie fort sur le "couvercle", même fermé...

[6] Pour plus d'infos sur "usb persist", installer le package linux-doc-2.6.24 et lire le document /usr/share/doc/linux-doc-2.6.24/Documentation/usb/persist.txt.gz.

[7] Le lecteur de carte mémoire de l'Asus EePC a en interne une interface USB...

[8] Sur l'un de mes portables, j'utilise la valeur 268435456.

Ubuntu: Verrouillage numérique au démarrage

Petaramesh — Wed, 28 May 2008 12:10:00 +0200

Un des petits détails chiants avec une Ubuntu (ou une Kubuntu, ou une Debian...) brute de décoffrage, c'est de ne pas avoir le verrouillage numérique (NumLock) activé automatiquement au démarrage de la machine, et de devoir le faire à la main.

Pire encore, certaines machines ayant un clavier en interface USB allument dès le démarrage le voyant NumLock alors qu'il n'est en fait pas activé, et il faut appuyer deux ou trois fois sur la touche NumLock pour que le voyant reflète fidèlement l'état réel du clavier.

Il existe sur le 'net de multiples articles apportant des solutions à ces problèmes, mais ces solutions sont souvent suboptimales. Voici donc des solutions simples et efficaces ;-)

Si vous utilisez le gestionnaire de session graphique KDM de KDE, sur Kubuntu par exemple :

C'est le plus simple ! Pour avoir le verrouillage numérique activé dès le démarrage de votre session graphique, éditez (comme root) le fichier /etc/kde3/kdm/kdmrc, recherchez la ligne :

#NumLock=Off

...et remplacez-la simplement par

NumLock=On

N'oubliez pas d'enlever le "#" de début qui en faisait un commentaire, enregistrez, et voilà !

Pour avoir le NumLock dans les "consoles texte" :

À peine plus compliqué. Éditez (comme root) le fichier /etc/rc.local et, avant la ligne "exit 0" finale, ajoutez le paragraphe suivant :

# Petaramesh: Active NumLock sur les consoles
if [ -x /usr/bin/setleds -a -s /etc/default/console-setup ]; then
   . /etc/default/console-setup
   if [ -n "${ACTIVE_CONSOLES}" ]; then
      for cons in ${ACTIVE_CONSOLES}; do
         if [ -c "${cons}" ]; then
            /usr/bin/setleds -D +num < ${cons}
         fi
      done
   fi
fi
# /Petaramesh

Si vous utilisez le gestionnaire de session graphique GDM de Gnome, sur Ubuntu :

Installez le package numlockx :

sudo aptitude install numlockx

...puis éditez le fichier /etc/gdm/Init/Default et, avant la ligne "exit 0" finale, ajoutez le paragraphe suivant :

if [ -x "/usr/bin/numlockx" ]; then
   /usr/bin/numlockx on || /bin/true
fi

Et voilà !

Retailler à la volée une LVM chiffrée LUKS

Petaramesh — Tue, 27 May 2008 11:58:00 +0200

(English abstract at end.)

Et encore un article en bas moldave qui s'annonce ;-)

J'explique ci-dessous comment il est possible d'agrandir à la volée une LVM chiffrée LUKS sur laquelle est installé tout un système GNU/Linux chiffré (ici une Ubuntu 8.04 Hardy).

Si cela vous parle autant que l'élevage du Yaka-Faucon en Patagonie septentrionale, passez votre chemin ;-)

Ma problématique pour cette manip' était la suivante : un ordinateur portable entièrement chiffré (sauf /boot) dont le disque dur était partitionné de la manière suivante :

sda1: /boot (non chiffré)
sda2: LVM chiffrée contenant le root filesystem et la quasi-totalité des volumes logiques usuels (/var, /home...)
sda3: un /tmp chiffré utilisant une clé aléatoire générée au boot.
sda4: un swap chiffré utilisant une clé aléatoire générée au boot.

L'objectif de la manip était d'"incorporer" le /tmp et le swap à l'intérieur de la LVM chiffrée principale et non plus à l'extérieur de celle-ci, de manière à pouvoir utiliser la fonction "hibernation sur disque" de la machine, qui nécessite en pratique que le déchiffrement du root filesystem au boot permette également l'accès au swap sur lequel est stocké le fichier de reprise, le plus simple étant alors de mettre le swap dans la même LVM chiffrée que le reste des partitions.

La même manip pourrait être utilisée à d'autres fins, par exemple augmenter l'espace disque utilisable après avoir recopié l'ensemble d'un système chiffré sur un disque neuf plus gros.

Pour que ça soit plus drôle, nous allons faire ça en live, sur le système tournant et bien chaud, et sans recourir au boot sur un CD-Rom.

Cet article est en partie inspiré de l'article de Bodhi.Zazen : How to Resize a LUKS Encrypted File System.

Avertissement : Ce type de manipulation est susceptible de provoquer la perte irréparable de l'ensemble des données présentes sur votre disque, si vous faites la moindre erreur durant les opérations, ou si j'ai fait la moindre erreur en les décrivant ! Faites une copie de sauvegarde de l'ensemble de votre système, vous êtes seul(e) responsable des dégâts que vous vous apprêtez à causer, même si une erreur s'est glissée dans mon article et si c'est moi qui vous ai foutu dedans. À vos risques et périls ! ;-)

Dans mon cas particulier, je vais donc commencer par supprimer les partitions sda3 et sda4, dont le contenu sera perdu durant l'opération, mais cela est sans importance s'agissant d'un /tmp et d'un swap, puis je vais étendre la partition sda2 sur laquelle réside la LVM chiffrée afin de récupérer dedans l'espace laissé libre par les partitions supprimées, puis j'agrandirai le container chiffré qui occupe cette partition, puis j'agrandirai le volume physique de LVM qui est dedans, ce qui ajoutera à la LVM chiffrée l'espace ainsi récupéré, permettant alors d'y créer de nouveaux volumes logiques, ou d'étendre les volumes logiques existants.

Dans le cas général, on considèrera que nous disposerons d'une manière ou d'une autre d'espace disque libre immédiatement après la partition contenant la LVM chiffrée à étendre.

Dans mon cas particulier, il me faut commencer par désactiver le swap (swapoff -a) dont je vais supprimer la partition, démonter le /tmp, et le démontage du /tmp nécessite de fermer toute session graphique X (KDE ou Gnome) et d'arrêter le gestionnaire de session graphique (invoke-rc.d kdm stop ou invoke-rc.d gdm stop selon le cas), ce qui me fera donc travailler en mode console texte. Il me faudra ensuite désactiver les volumes chiffrés correspondants avant de pouvoir en supprimer les partitions.
Dans le cas général, si vous n'avez pas besoin de démonter une partition nécessaire, vous pouvez travailler dans un terminal depuis une session graphique.

Retaillage des partitions

Commençons donc par décrire l'étape de suppression des partitions inutiles, et de redimensionnement de la partition à agrandir.

Nous allons pour cela utiliser le bon vieux fdisk en console, et non pas un outil graphique, car seul fdisk nous permettra de supprimer notre partition essentielle (celle de la LVM chiffrée) et de la recréer exactement au même endroit, mais plus grande.

Lançons donc: fdisk /dev/sda

La première chose à faire est d'afficher la table de partitions actuelle en utilisant la commande "p", et de noter absolument tous les jolis chiffres qui apparaîssent alors, de manière à pouvoir remettre manuellement les choses en l'état en cas de problème.

Puis nous utiliserons la commande "d" de fdisk afin de détruire sans regret les partitions "4" et "3" dont nous n'avons plus besoin.

Puis nous arrivons à l'étape vraiment terrifiante de la manoeuvre, qui consiste à supprimer la partition sda2, c'est-à-dire celle de notre LVM chiffrée, ce qui revient très exactement à scier la branche sur laquelle notre système est assis. Supprimons donc courageusement la partition "2" à l'aide de la commande "d".

Pas de panique toutefois, les modifications ne seront réellement apportées sur le disque qu'au moment où nous exécuterons la commande "w" finale, et nous aurons recréé la partition vitale d'ici-là, mais en plus grand. D'autre part, la modification de la table de partitions sera alors écrite sur le disque dur lui-même, mais le noyau Linux n'en tiendra aucun compte puisqu'il est incapable de relire la table de partitions d'un disque ayant des partitions montées. Il faudra donc rebooter le système pour que le changement de taille de la partition concernée soit pris en compte.

Après avoir supprimé la partition "2", nous la recréons maintenant aussitôt, comme partition primaire, en utilisant la commande "n". Nous veillerons alors à ce que la "nouvelle partition 2" commence à l'endroit exact du disque (numéro de cylindre) où elle commençait précédemment, et nous la laisserons s'étendre jusqu'à la fin du disque, utilisant ainsi tout l'espace disponible.

Après avoir recréé la partition, utilisons la commande "p" pour afficher la nouvelle table de partitions, et vérifions soigneusement à l'aide de nos notes qu'elle commence effectivement exactement au même endroit que précédemment.

Si c'est bien le cas, nous pouvons alors écrire nos modifications de manière définitive avec la commande "w", qui nous fera également quitter fdisk.

Nous allons maintenant devoir rebooter le système pour que la nouvelle table de partitions soit prise en compte. Toutefois, si nous avons (dans mon cas particulier) supprimé des partitions qui servaient antérieurement, nous devons en faire disparaître toute trace dans /etc/fstab et /etc/crypttab, puis régénérer notre initramfs (update-initramfs -u) pour éviter de cruelles erreurs lors du reboot.

Rebootons donc bien proprement le système. Ceci devrait se dérouler sans erreur.

Extension du volume LUKS chiffré

Après avoir rebooté, il nous faut théoriquement agrandir le volume chiffré supportant notre LVM. Je dis théoriquement car mes observations semblent démontrer que le volume chiffré utilise automatiquement la nouvelle taille entière de la partition, mais comme je n'en suis pas absolument certain, le redimensionner quand même ne fera pas de mal.

Affichons tout d'abord la taille actuelle de notre container de LVM chiffrée, supposant qu'il s'appelle "encVG" par exemple :

# cryptsetup status encVG
/dev/mapper/encVG is active:
 cipher:  aes-cbc-essiv:sha256
 keysize: 192 bits
 device:  /dev/sda2
 offset:  1032 sectors
 size:    312061593 sectors
 mode:    read/write

"Agrandissons" (en théorie) maintenant le container :

cryptsetup resize encVG

Affichons de nouveau sa taille (cryptsetup status encVG) : Surprise : il semble que rien n'a changé, et que notre manip n'a donc servi à rien ? Ce n'est pas grave : nous utilisons désormais bel et bien la totalité de l'espace attribué à la partition sda2.

Agrandissement du volume physique de la LVM

C'est là que nous allons nous apercevoir que la manip' a marché !

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   144.80G    0

pvresize /dev/mapper/encVG

# pvs
 PV                       VG   Fmt  Attr PSize   PFree
 /dev/mapper/encVG VG1 lvm2 a-   148.80G    4.0G

Eh oui ! le "pvresize" nous a bien fait gagner 4 Go d'espace libre dans la LVM chiffrée !

Création des nouveaux volumes logiques

Nous pouvons maintenant créer (lvcreate) un ou plusieurs nouveaux volumes logiques dans l'espace désormais disponible sur la LVM. Dans mon cas, j'en recréerai deux, pour le /tmp et pour le swap bien sûr.

Si vous souhaitez utiliser ce nouvel espace non pas pour créer de nouveaux volumes logiques, mais pour agrandir un volume déjà existant (lvextend), je vous conseille toutefois de commencer par créer un nouveau volume logique, que vous supprimerez ensuite, mais entre-temps vous l'aurez rempli de données aléatoires, ce qui est toujours conseillé avant de commencer à utiliser un volume chiffré.

Remplissage des nouveaux volumes logiques avec des données aléatoires

Par exemple :

dd if=/dev/urandom of=/dev/mapper/VG1-newvolume bs=1M

(Si vous voulez accélérer cette étape, vous pouvez utiliser /dev/zero à la place de /dev/urandom, puisque, s'agissant d'un volume chiffré, le chiffrement donnera de toute manière un aspect parfaitement aléatoire aux données qui seront physiquement écrites sur le disque (les zéros seront transformés en random apparent).

Formatage des nouveaux volumes logiques

Nous n'avons plus désormais qu'à formater les nouveaux volumes logiques en fonction de leur utilisation projetée : mke2fs, mkswap, etc... ou, pour l'extension d'un volume existant, lvextend puis resize2fs^[1] par exemple.

Mise à jour de fstab

Enfin, nous pouvons monter nos nouveaux volumes, sans oublier bien sûr de les mentionner dans /etc/fstab - il n'y a rien à ajouter dans /etc/crypttab puisque l'entrée servant à déverrouiller globalement la LVM chiffrée y figure déjà.

That's all, folks !

English abstract : This article explains how to expand a LUKS-encryped LVM on which resides a fully encrypted GNU/Linux System, including its root filesystem. This can be done on the "live" system without needing to boot from a live CD or the like. Use an online translator such as Google translate or babelfish to obtain a truly bad, automated translation of this document ;-)

Help Google : resize enlarge expand LUKS encrypted partition LVM container on the fly

Notes

[1] À effectuer sur un volume préalablement démonté

Une clé de contact pour votre portable chiffré : Mise à jour

Petaramesh — Sun, 11 May 2008 09:46:00 +0200

Ce billet est là uniquement pour signaler une importante mise à jour de mon précédent billet Une clé de contact pour votre portable chiffré et du script bootkeyscript^[1] qu'il propose.

En effet, ce script s'est avéré dans sa version précédente pouvoir très mal fonctionner avec une clé non chiffrée sur une clé USB formatée en FAT. Le voici maintenant bien débuggé, partiellement réécrit et enrichi, ainsi que les explications qui vont avec.

Que demande le peuple ? ;-)

Instructions de mise-à-jour :

Si vous utilisiez la précédente version de mon script bootkeyscript, il vous suffit d'installer la nouvelle à la place de la précédente (typiquement dans /usr/local/sbin) et de régénérer votre initramfs avec "update-initramfs -u". C'est tout.

Bon c'est pas tout ça, faut qu'on va aller pique-niquer ;-))

(Rectificatif : Ah non, tiens, le programme de la journée a l'air plutôt réglé sur "Monstre engueulade familiale et hurlements uxoriens"... Soyons zen...)

Notes

[1] (Signature GnuPG, licence GPL)

Mise à jour (K)Ubuntu 7.10 Gutsy => 8.04 Hardy LTS

Petaramesh — Wed, 30 Apr 2008 15:20:00 +0200

Plusieurs estimés disciples m'ont demandé par mail quelques infos ou conseils pour la mise à jour de leur machine vers la toute nouvelle (K) Ubuntu 8.04 Hardy LTS.

Je n'avais pas encore fait cette mise à jour ; je viens de la faire sur deux machines : Au rapport !

Je viens donc de mettre à jour deux Kubuntu 7.10 vers 8.04, et la bonne nouvelle c'est que ça s'est plutôt très bien passé, comme une lettre à la poste, en utilisant l'updateur de Kubuntu et sans rien faire de particulier.

Si ça c'est bien passé avec Kubuntu, je m'attends à ce que ça se passe encore plus facilement (si toutefois c'est possible) avec Ubuntu.

Les deux machines que j'ai mises à jour étaient une station de travail (Bipro Intel Xeon, système installé sur LVM) et mon bon vieux portable (système entièrement installé sur LVM chiffrée). Ce ne sont donc pas les configs les plus simples qui soient, et ça fait un bon test de mise à jour.

Première note : Ces jours-ci, les miroirs primaires FTP Ubuntu sont totalement saturés. On comprend pourquoi. Je vous conseille donc très fort de sélectionner comme source de paquetages des miroirs alternatifs avant de lancer la mise à jour :

Mise à jour de mon portable en utilisant les miroirs de free.fr : 2 heures.
Mise à jour de l'autre station en utillisant le miroir "primaire France" : Plus de 24 heures.

Qu'on se le dise ;-)

Après mise à jour, tout fonctionne impec sur les deux machines, y compris le Wi-Fi de mon portable qui utilise pourtant ndiswrapper, typiquement le truc qui se casse à la mise à jour, ben là, même pas.

Je note un problème après cette mise à jour : Mon portable a une carte graphique ATI^[1] et j'utilisais le pilote propriétaire fglrx. Là, j'ai vu une belle marche arrière :

Avec Ubuntu 7.04 : Tout marchait parfaitement
Avec Ubuntu 7.10 : Impossible d'utiliser la "suspension" ou "l'hibernation" du portable. le pilote fglrx coince.
Avec Ubuntu 8.04 : Impossible de sortir de l'environnement graphique. Plantage systématique en quittant ou fermant la session (écran noir, plus rien ne répond, il est cependant possible de débloquer la machine en utilisant la MagicSysRq key "E", qui tue tous les processus et permet alors de réobtenir la console et de voir ensuite la machine s'arrêter normalement).

Pour cette raison, je viens (pour le moment) d'abandonner l'usage du pilote propriétaire fglrx pour le pilote ATI générique libre, abandonnant au passage l'utilisation de l'accélération 3D matérielle de ma carte graphique (dont je n'ai cependant que faire 98% du temps) et divisant par 2 les performances OpenGL. Bon.

Je ne peux cependant pas en vouloir à Ubuntu, car il semble que c'est ATI qui rame très loin derrière les versions de noyau et de xorg dans le développement de son pilote propriétaire... Espérons (voeu pieux) qu'ATI va se décider à pondre une mise à jour qui marche pour son pilote. Ils commencent à me flégon... :-/

Si vous avez une carte ATI utilisant fglrx, je vous suggère de le désactiver (repasser au pilote ordinaire) et de rebooter ensuite votre machine avant de lancer la mise-à-jour vers Hardy.

Pour le reste, RÀS, alors si vous vous sentez l'âme aventureuse, vous pouvez tenter le coup - sachant bien que si vous cassez votre bécane, ce ne sera pas ma faute ;-)

Addendum 2 mai 2008 10:36 : Mon problème de blocage à la fermeture de session avec le pilote fglrx a été résolu comme décrit ici, merci à Olivier Lacroix pour le tuyau.

Solution reçue moins de 24h après avoir posé la question. Décidément, le support de la communauté dans le Logiciel Libre, c'est vraiment que du bonheur ! Ramez une fois dans votre vie avec un problème similaire sous Windows, vous comprendrez la différence... (Typiquement, vous n'aurez la solution qu'en attendant 2 ans une hypothétique corrective, ou à défaut le jour où vous changerez de matériel...)

Notes

[1] J'en vois déjà des qui rigolent...

LFD: Mise à jour

Petaramesh — Fri, 18 Jan 2008 14:19:00 +0100

Voici une mise-à-jour de mon script "LUKSfile for dummies".

Cette nouvelle version permet désormais (optionnellement) la création et le montage de containers chiffrés LUKS intérieurement formatés en FAT16 ou FAT32, les rendant ainsi utilisables sous Windows grâce au logiciel FreeOTFE pour Windows.

On peut ainsi créer des containers chiffrés sur support amovible (clé USB, etc.) qui pourront être utilisés dans les deux environnement GNU/Linux ou Windows.

N.B.: Créer des containers chiffrés formatés en FAT est déconseillé si ce n'est pas pour les partager entre les deux environnements. En effet :

Il est impossible d'effectuer un fsck sur un container formaté en FAT, rendant toute réparation délicate en cas d'endommagement du filesystem.
FAT est intrinsèquement beaucoup plus fragile qu'ext3 employé par défaut.
Un filesystem en FAT ne gère pas les droits Un*x.

Ashram de Swâmi Petaramesh - Ubuntu

Noyau 2.6.27 Ubuntu custom pour Acer Aspire One

Notes

Noyau "Ubuntu" custom pour Acer Aspire One

Une clé de contact pour votre portable chiffré : Version 1.6

Notes

Installation de KUbuntu sur un Acer Aspire One

Avertissement

Créer le support d'installation

Installation de Kubuntu

Suggestion de partitionnement du disque SSD:

Premières modifications

/boot/grub/menu.lst : Sélection du timer

Script de gestion du lecteur de cartes SD JMicron

Accélération de l'accès au disque SSD

Modification de /etc/rc.local

Réglages ACPI

Modification de /etc/sysctl.conf

Modification de /etc/initramfs-tools/modules

Modificaton de /etc/initramfs-tools/initramfs.conf

Régénération de l'initramfs

Son

Webcam

Wi-Fi Atheros

Lecteurs de cartes mémoires

Installer une extension mémoire d'un Go

Test de lecture hdparm

Tests d'écriture réels (à travers la couche de chiffrement, donc avec l'overhead)

Notes

Pôôôôôôôôôô !

Hibernatus

La suspension "en RAM"

L'"hibernation" sur disque

Problèmes techniques

Pièges à prévoir

Considérations de performances

Considérations de sécurité

Résolution de problèmes

Notes

Ubuntu: Verrouillage numérique au démarrage

Si vous utilisez le gestionnaire de session graphique KDM de KDE, sur Kubuntu par exemple :

Pour avoir le NumLock dans les "consoles texte" :

Si vous utilisez le gestionnaire de session graphique GDM de Gnome, sur Ubuntu :

Retailler à la volée une LVM chiffrée LUKS

Retaillage des partitions

Extension du volume LUKS chiffré

Agrandissement du volume physique de la LVM

Création des nouveaux volumes logiques

Remplissage des nouveaux volumes logiques avec des données aléatoires

Formatage des nouveaux volumes logiques

Mise à jour de fstab

Notes

Une clé de contact pour votre portable chiffré : Mise à jour

Instructions de mise-à-jour :

Notes

Mise à jour (K)Ubuntu 7.10 Gutsy => 8.04 Hardy LTS

Notes

LFD: Mise à jour

Modification de `/etc/rc.local`

Modification de `/etc/sysctl.conf`

Modification de `/etc/initramfs-tools/modules`

Modificaton de `/etc/initramfs-tools/initramfs.conf`