Ashram de Swâmi Petaramesh - informatique

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 ;-)

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

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.

Modification de `/etc/rc.local`

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, économiser l'énergie pour augmenter l'autonomie de batterie, et activer le lecteur de cartes mémoire.

Ajouter les lignes :

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

# 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

echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo 20 > /proc/sys/vm/dirty_ratio
echo 10 > /proc/sys/vm/dirty_background_ratio

[ -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

Modification de `/etc/sysctl.conf`

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

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/modules`

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.

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

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-nr-r3366+ar5007 , que l'on se procurera ici : http://snapshots.madwifi.org/special/

Installer d'abord le package "build-essential" :

sudo aptitude install build-essential

Décompresser l'archive madwifi-nr-r3366+ar5007 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.

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.

Small is beautiful

Petaramesh — Sat, 12 Jul 2008 12:31:00 +0200

Permettez-moi de vous présenter ma nouvelle copine :

J'ai vendu il y a quelque jours mon brave Asus EeePC 701 sur eBay dans l'idée de le remplacer prochainement par un MSI Wind pour disposer essentiellement d'un écran un peu plus grand et d'un clavier plus confortable que le mini-clavier de l'EeePC, et pendant qu'on y était, d'une machine plus rapide avec davantage de mémoire et de stockage.

Mais voilà, le MSI Wind s'est fait désirer plus longtemps que prévu, il est sorti en France il y a une paire de jours seulement, et uniquement en version Windows pour le moment - ce qu'il est hors de question que j'achète - avec uniquement une batterie "3 cellules" lui offrant une autonomie un peu faible, la version Linux n'étant pas prévue avant fin juillet ou août si tout va bien, la battrie 6 cellules pas avant la rentrée, et la version Linux avec batterie 6 cellules peut-être bien jamais...
De plus, les distributeurs, prévoyant un gros succès pour la machine, se sont carrément gavés en la collant un bon 50 Euros au-dessus du "prix conseillé" du constructeur.
Tout ceci a fini par me gonfler, et je ne me voyais certes pas payer 450 Euros avec Windows une machine que je convoitais à 350 Euros avec Linux. Ça va pas la tête ?

Je me voyais donc déjà partir en vacances frustré avec mon gros machin, alors que je voulais une toute petite machine.

Et, la réflexion aidant, je viens de tomber amoureux du superbe Acer Aspire One dont je vais vous faire faire un petit tour du propriétaire.

La première chose à noter concernant cette machine est qu'elle est vraiment belle, ce qui, comme pour une femme, ne gâche rien ;-) et c'est bien souvent la première chose qu'on remarque avant de tomber de haut, mais ce ne sera pas le cas cette fois ;-)

La deuxième chose à noter, c'est qu'elle est disponible depuis hier chez grosbill.com qui a la bonne idée d'avoir un magasin dans le coin. Pour 300 Euros tout rond, soit le prix de l'EeePC 701 il y a quelques mois, et avec un Linux dessus^[1], que demande le peuple ?

La troisième chose, c'est qu'elle est vraiment petite, presque aussi petite qu'un EeePC 701 ou 900, pas plus épaisse, et pèse sur ma balance 970 grammes batterie comprise et en état de marche.

Posée sur un portable "15 pouces" de taille ordinaire, à savoir celui auquel j'ai fait bien des misères l'autre jour, la différence se passe de tout commentaire :

...Posée à côté d'objets usuels qui donnent l'échelle, on voit que cette machine est vraiment très petite :

25 centimètres par 17 pour moins de 3,5 d'épaisseur. Voilà qui tient sans conteste dans le sac à dos.

Si nous nous intéressons à l'interface homme-machine, nous trouvons un excellent écran très lisible bien que "brillant" de 8,9 pouces en 1024x600, ce qui permet enfin d'installer parfaitement à l'aise une Kubuntu normale et non pas un modèle taillé pour l'écran minuscule d'un EeePC 701. On a la place suffisante pour un surf confortable ou la rédaction de mails et tout l'affichage nécessaire pour les activités usuelles.

Côté clavier, la surprise est carrément excellente : c'est un des meilleurs claviers de portables sur lesquels j'ai travaillé, et je rédige ce billet dessus. Les touches sont plus petites que sur un portable classique, mais bien plus grandes que celles de l'EeePC, tombent parfaitement sous les doigts, et ont un toucher et une course absolument excellents. Un plaisir de taper là-dessus !

Le touchpad est un peu étroit en hauteur, prix à payer pour le large clavier, et a ses touches déplacées sur les côtés. Je ne trouve pas cela gênant, en dehors du fait que les touches "clic" sont nettement trop dures, seul élément d'inconfort sur cette machine.
La surface du touchpad est intégrée à la carrosserie de la machine et du même matériau^[2], je regrette qu'elle n'ait pas tout-à-fait la même "glisse" que les touchpads habituels.

Les voyants sont placés de manière à être parfaitement visibles machine ouverte ou fermée, et on dispose, contrairement à l'EeePC, de vrais voyants "Caps Lock" et "Num Lock" pratiquement indispensables quand on tape un mot de passe à l'aveugle.

Enfin, une webcam de faible définition, bien suffisante pour ce que j'en fais puisque je ne m'en sers jamais ;-)

Voyons maintenant sous le capot. Un processeur Intel Atom à 1,6 GHz, que Linux voit comme deux processeurs, je ne croyais pourtant pas que l'Atom était un dual-core...?
Il semble également 64-bit, mais compte tenu de la taille de mémoire disponible, j'ai bien évidemment installé une Kubuntu 32 bits.

512 Mo de RAM, ça fait un peu petit ; elle est extensible toutefois, et Linux montre tous les jours que contrairement à la concurrence, il est parfaitement capable de tourner dans 512 Mo de RAM.

Un "disque" flash SSD de 8 Go. Là, c'est vraiment petit,et c'est ce que je regrette le plus sur cette machine, ne pas avoir au moins 20 Go de stockage.
Ceci est compensé par la bonne idée d'Acer d'avoir mis deux lecteurs de cartes mémoire, l'un multiformat et l'autre SD seulement, permettant d'utiliser une carte SD à poste fixe comme "extension de disque dur", et d'en insérer une autre au besoin pour des transferts de données sans avoir besoin de retirer la première.

A noter que les lecteurs de cartes mémoires sont les seules choses que je ne suis pas encore parvenu à faire fonctionner sour Kubuntu sur cette machine, mais comme ils sont certainement pris en charge par le Linux d'origine que je n'ai regardé que 30 secondes avant de l'effacer, il doit sûrement y avoir moyen de faire.

Sous Kubuntu 8.04, disque entièrement chiffré, la vitesse de la machine est correcte sans plus, mais pour ce type de portable on ne s'attend pas à davantage et l'on ne recherche pas une bête de course.
À noter que l'accès au "disque SSD" me semble notablement plus lent que ce à quoi je me serais attendu, particulièrement en écriture. Ses performances semblent proches d'un disque dur de portable 5400 tours pas particulièrement rapide, enfin, je dis ça à simple vue de nez. On note des "figés" de quelques secondes surprenants lors de gros accès disque.

Pour le côté "regrets", je regrette un peu l'absence de bluetooth intégré, que la machine n'ait pas un peu plus de RAM (1 Go) et davantage de stockage, mais pour le reste c'est excellent.

Une superbe carrosserie, une petite cervelle, c'est vraiment une fille :-D ;-))

Dernier petit regret : la pochette cuir ou imitation fournie est peu adaptée pour protéger la machine des chocs, c'est vraiment une simple enveloppe, il faudra que je trouve autre chose avant de la balancer dans le sac à dos.

Voilà donc la nouvelle copine que j'emmènerai en vacances cet été, et je l'aime déjà beaucoup :-)

Notes

[1] Que je n'ai pas gardé, car c'est une version bridée orientée grand débutant...

[2] Brillant et qui prend vachement les traces de doigts...

Shit happens

Petaramesh — Sat, 14 Jun 2008 14:35:00 +0200

Alors voilà, j'ai voulu rajouter un module Bluetooth acheté à un chinois sur Ebay à mon portable Acer Aspire 3104WLMi...

Le module Bluetooth, c'est la petite carte minuscule avec un petit bout de câble, en bas au milieu, à gauche de la pièce d'un Euro qui donne l'échelle (cliquer sur l'image pour agrandi un poil)

Et pour rajouter un truc comme ça dans un portable Acer, c'est pas comme s'il fallait tout démonter, hein ? Ah si ? C'est même le truc pour lequel il faut le plus tout démonter, même la carte mère, même le radiateur du processeur en ruinant son interface thermique ? Ah oui. Ben hein, c'est pô de chance...

Surtout pour s'apercevoir en fin de compte que le connecteur de la carte vendue par le chinois est plus gros que celui de la carte mère du portable, et qu'il n'y a strictement aucun moyen de brancher l'un sur l'autre en l'état.

Shit happens.

You've got mail !

Petaramesh — Fri, 13 Jun 2008 08:48:00 +0200

Les petits veinards qui décident d'installer GNU/Linux sur leur portable ces jours-ci ne se doutent pas de la chance qu'ils ont : La plupart des fonctions de la plupart des portables (veille, hibernation, touches "[Fn]" de réglage de luminosité, de volume...) fonctionnent out of the box sans qu'il soit besoin de rien faire de spécial.
Il n'en allait pas de même il y a quelques années, époque où gérer avec GNU/Linux les spécificités des portables relevait encore de l'exploit.

Il y a cependant quelques petites choses que le linuxien de base ne pensera le plus souvent même pas à essayer de faire marcher, comme par exemple les touches spécifiques situées en dehors du clavier principal, et sur lesquelles on trouve des symboles du genre courrier, navigateur Internet, maison, etc.

Si vous avez un portable Acer Aspire, par exemple, vous avez 4 touches de ce genre à côté du bouton de mise sous tension, l'une d'elles étant la touche courrier qui, si on la regarde bien, comporte même un voyant LED.

Ne serait-il pas sympathique que cette LED clignote quand on a du courrier non lu ?

Nous allons voir dans cet article qu'il n'est franchement pas difficile de contrôler le clignotement de ce voyant, et de l'utiliser pour signaler la présence de nouveau courrier.^[1] Pour l'utilisation des touches elles-mêmes, nous verrons peut-être ça dans un prochain article...

Cet article est consacré à un portable de type Acer Aspire 3104 WLMi sous Kubuntu 8.04 Hardy, mais peut également être valable pour d'autres modèles, et même des portables de certaines autres marques qui peuvent aussi être gérés avec les pilotes Acer.

Si vous avez installé Ubuntu Hardy sur un portable Acer, il y a de bonnes chances que le module acer_acpi ait été automatiquement chargé. Si c'est le cas, vous verrez dans le répertoire virtuel /proc un sous-répertoire /proc/acpi/acer contenant divers pseudo-fichiers, dont un fichier "mailled".

# ls -l /proc/acpi/acer/
total 0
-rw-r--r-- 1 root root 0 2008-06-13 08:43 brightness
-rw-r--r-- 1 root root 0 2008-06-13 08:43 interface
-rw-r--r-- 1 root root 0 2008-06-13 08:43 mailled
-rw-r--r-- 1 root root 0 2008-06-13 08:43 threeg
-rw-r--r-- 1 root root 0 2008-06-13 08:43 version
-rw-r--r-- 1 root root 0 2008-06-13 08:43 wireless

Si vous ne voyez pas ce répertoire, vérifiez avec la commande "lsmod" que le module "acer_acpi" est chargé, sinon tentez de le charger avec la commande "modprobe acer_acpi".

# lsmod | grep acer
acer_acpi              18112  0
led_class               6020  1 acer_acpi
wmi_acer                9644  1 acer_acpi

Si vous voyez le fichier /proc/acpi/acer/mailled, essayez donc (comme root) :

echo 1 > /proc/acpi/acer/mailled
echo 0 > /proc/acpi/acer/mailled

Amusant, n'est-ce pas ?

Nous avons quand même un petit problème : Seul root peut normalement écrire dans ce fichier (donc contrôler la LED), et nous voudrions bien pouvoir l'utiliser pour signaler la présence de courrier pour un utilisateur "ordinaire".

On pourrait envisager de "chmod 666 /proc/acpi/acer/mailled" pour autoriser n'importe quel utilisateur à contrôler la LED, ce qui ne pose pas de problème de sécurité, mais /proc est un système de fichiers virtuel, et ce réglage disparaîtrait au prochain reboot, ou à la prochaine suspension ou hibernation de la machine.

Le plus simple pour contourner ce problème est alors de contrôler la LED via un petit script "/usr/local/bin/mail-led" que l'on appellera à travers "sudo", tout en indiquant à sudo qu'il peut exécuter ce script en tant que root, depuis n'importe quel utilisateur et sans demander de mot de passe. Voici le contenu du script "/usr/local/bin/mail-led" que je vous propose :

# Sets Acer mail LED on or off
#
# Needs to be run as root, use sudo with an /etc/sudoers entry such as:
# ALL ALL=NOPASSWD: /usr/local/bin/mail-led
#
[ $# -eq 1 ] || exit 1
[ -w /proc/acpi/acer/mailled ] || exit 1

case $1 in
        0|no|NO|No|off|OFF|Off|false|FALSE|False)
                echo 0 > /proc/acpi/acer/mailled
                ;;
        1|yes|YES|Yes|on|ON|On|true|TRUE|True)
                echo 1 > /proc/acpi/acer/mailled
                ;;
        *)
                exit 1
                ;;
esac
exit 0

Après l'avoir sauvegardé, rendez-le exécutable pour n'importe quel utilisateur : "chmod 755 /usr/local/bin/mail-led", puis utilisez la commande "visudo" qui appellera votre éditeur de texte standard pour vous permettre de modifier le fichier "/etc/sudoers".
À la fin de ce fichier, rajoutez simplement la ligne :

ALL     ALL=NOPASSWD: /usr/local/bin/mail-led

...et sauvegardez.

Essayez alors, depuis un terminal "utilisateur ordinaire" :

sudo mail-led on
sudo mail-led off

Ça devrait fonctionner, sans vous demander de mot de passe.

Maintenant que nous pouvons contrôler la LED à l'aise Blaise, il n'y a plus qu'à utiliser l'un des nombreux petits logiciels "notificateurs de courrier" disponibles, pour peu que celui-ci permette d'exécuter une commande arbitraire (pour allumer la LED) quand il détecte du nouveau courrier, et une autre commande (pour éteindre) quand il n'en détecte plus.

Sous KDE, le package "kbiff" fera parfaitement l'affaire. Sous Gnome ou d'autres environnements, vous pouvez utiliser le package "mail-notification".^[2] Vous n'avez plus qu'à configurer ce logiciel pour qu'il appelle "sudo mail-led on" pour signaler la présence de nouveau courrier, et, bien sûr "sudo mail-led off" quand il n'y en a plus.

Vous devrez également configurer dans ce logiciel les paramètres de votre serveur de courrier et de votre boîte-aux-lettres, puisque ce logiciel de notification est indépendant de votre "client mail" habituel. (Pour cette raison, il pourra y avoir un décalage entre le moment où vous lisez le courrier et le moment où la LED s'éteindra, puisqu'il faudra attendre que le logiciel de notification revérifie votre boîte pour qu'il se rende compte qu'il n'y a plus de nouveau courrier).

Moi, je trouve ce petit truc super-pratique ;-)

Notes

[1] Sur une machine ne disposant pas de LED "spéciale", il existe des outils permettant de contrôler le clignotement des LEDs habituelles du clavier (NumLock, etc...)

[2] Il existe aussi des packages spécialement "orientés gmail", comme chekckgmail, kcheckgmail ou kgmailnotifier...

Dent bleue

Petaramesh — Tue, 10 Jun 2008 16:40:00 +0200

Je fais mumuse depuis quelques jours avec du Bluetooth sous GNU/Linux, et je constate que la chose y fonctionne avec une facilité déconcertante : Impeccable pour transférer photos, musique et carnet d'adresses avec son téléphone mobile.

Dans KDE, on peut explorer les périphériques bluetooth directement avec Konqueror et coupier / copier / coller des fichiers comme on le ferait sur un répertoire monté en réseau.

Mais il y a aussi une petite chose couplée à KBluetooth que je trouve extrêmement utile : KBlueLock : Ce machin active l'économiseur d'écran et verrouille l'écran dès qu'un périphérique bluetooth choisi disparaît. En pratique, si on "choisit" comme périphérique son téléphone mobile, la portée du bluetooth étant d'une dizaine de mètres gromaxi, il suffit de s'éloigner de sa bécane téléphone mobile en poche ou à la ceinture pour que l'écran se verrouille aussitôt qu'il "voit" qu'on est parti :-)

Plus besoin de régler des délais d'économiseur d'écran très courts, et on peut même régler le machin pour qu'il déverrouille l'écran tout seul dès que le téléphone revient dans le coin. Magique ! ;-)

Pour ceux qui n'utilisent pas KDE mais Gnome, on peut faire la même chose en installant le package "blueproximity".

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é

C'est toujours les meilleurs qui s'en vont...

Petaramesh — Tue, 13 May 2008 00:04:00 +0200

Triste nouvelle : Les éditions O'Reilly France ont mis la clé sous le paillasson...

<deuil> Sniff... Les seuls bouquins d'informatique lisibles, bien écrits, et parlant de Logiciels Libres, bouhouhou </deuil>

Les merdes infâmes écrites avec les pieds en paraphrasant la doc avec des erreurs dedans demeurent...

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...

La fin programmée d'un règne ?

Petaramesh — Sat, 12 Apr 2008 18:10:00 +0200

Tiens, aujourd'hui j'ai jeté un coup d'oeil aux statistiques de ce modeste asham.

Oh, juste parce que j'ai mis à jour mon outil PHPmyVisites et que je voulais m'assurer qu'il fonctionnait toujours ;-)

Et je constate en regardant les stats cumulées depuis début 2008 quelques petites choses qui me mettent de bonne humeur, bon, c'est peut-être juste parce que j'ai besoin d'une bonne raison de me sentir de bonne humeur...

Alors, voici les systèmes d'exploitation utilisés par mes honorables visiteurs depuis le début de l'année :

Où je remarque avec joie un GNU/Linux bon second, devançant la dernière et calamiteuse mouture Windows Vista, laquelle devance elle-même les bizarres MachinTocs.

Rêvons un peu et parions que tous ceux qui mettront à jour leur Windows XP dans les mois qui viennent le feront pour une Ubuntu Linux ou une Kubuntu (My own personal choice ™)

C'est vrai ça, y'a encore des gros malins qui paient pour de la crotte en barre quand on leur offre du chocolat fin gratos ? Je n'ose imaginer que la majorité de mes honorables visiteurs puissent rester éternellement crétins ;-)

Côté navigateurs maintenant, en gros et en détail :

Là, l'intense satisfaction de voir se pérenniser la croupière que Firefox taille à Internouille Exploder, lequel a largement décroché bien qu'installé de série sur l'écrasante majorité des machines neuves commercialisées de nos jours, et l'on sait pourtant combien le windowzien est flemmard...

Mon seul petit regret : Voir l'excellent Konqueror faire imperturbablement un tout petit score, augmenté cependant du Safari du Mac, qui en est directement issu. Konqueror est le navigateur standard et de choix de l'environnement KDE, mais il subit la concurrence de Firefox sur la même plate-forme, et les versions plus anciennes de Konqueror présentaient parfois des problèmes de compatibilité sur certains sites (notamment à cause d'une prise en charge du Javascript qui fut médiocre...), ce qui a sans doute poussé pas mal de linuxiens à utiliser plutôt Firefox, à la compatibilité plus large. Mais je trouve que Konqueror vaut largement mieux que son modeste score.

Quoiqu'il en soit, l'Empire Monopolistique semble être plus fragile que par devant, on finira bien par s'en débarrasser un jour ;-)

Patchez vos noyaux !

Petaramesh — Tue, 12 Feb 2008 15:41:00 +0100

Un des plus "beaux" privilege escalation exploits qu'il m'ait été donnés de voir sous Linux jusqu'ici : le vmsplice local root exploit :

Quiconque exécute le programme "jess" sous un profil utilisateur ordinaire devient instantanément root. Je viens de vérifier : ça le fait effectivement, et ce jusqu'au noyau 2.6.24.2 qui vient de sortir pour contrer cet exploit.

Alors je n'ai qu'une chose à dire : Patchez vos noyaux !

Sinon, tout utilisateur "ordinaire" capable d'exécuter un programme sur votre machine peut également devenir root...

Error ? Success !

Petaramesh — Fri, 08 Feb 2008 17:02:00 +0100

Heureusement que c'est vendredi, y'a des jours où l'on ne peut même plus prétendre que ce genre de chose n'arrive que sous Windows...

partimage est certes bien utile, mais cette cochonnerie est bugguée de sa mère, et pas maintenue. S'en servir consiste essentiellement à ruser pour passer entre les bugs :~\

Cartes Flash "SD" et portables Ubuntu Linux

Petaramesh — Mon, 28 Jan 2008 14:26:00 +0100

Ce n'est pas histoire de faire de la pub' (sinon, j'accepte volontiers que Sandisk m'en envoie deux caisses ;-) mais après avoir pas mal galéré, j'ai pensé que l'info pourrait être utile à d'autres que moi...

Sur deux portables tournant sous Ubuntu Gutsy et possédant un lecteur de cartes SD/MMC :

Un Acer Aspire 3104 WLMi avec lecteur SD/MMC interne "ENE"
Un Asus EeePC avec lecteur interne SD/MMC vu en USB 2.0, s'identifant comme "Kingston technologies" mais laissant également à penser qu'il est fabriqué par "ENE"

Je constate que :

Les cartes Flash SD de marque / type Sandisk Ultra II, de capacité de 1 Go ou 2 Go, fonctionnent à la perfection, plein pot et sans la moindre erreur.
Toutes les autres cartes SD que j'ai essayées (5 ou 6 de marques et capacités différentes) merdoient lamentablement. Dans le meilleur des cas des gerbes d'erreurs de de retries dans /var/log/kern.log causant de considérables ralentissements, et dans l'écrasante majorité des cas, ça finit par foirer complètement.

Donc, sur ces machines et avec Linux, je ne me pose plus de questions oiseuses quant au type de cartes que j'achèterai à l'avenir.

Ashram de Swâmi Petaramesh - informatique

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

Modification de /etc/rc.local

Modification de /etc/sysctl.conf

Modification de /etc/initramfs-tools/modules

Modificaton de /etc/initramfs-tools/modules

Régénération de l'initramfs

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

Small is beautiful

Notes

Shit happens

You've got mail !

Notes

Dent bleue

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

C'est toujours les meilleurs qui s'en vont...

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

La fin programmée d'un règne ?

Patchez vos noyaux !

Error ? Success !

Cartes Flash "SD" et portables Ubuntu Linux

Modification de `/etc/rc.local`

Modification de `/etc/sysctl.conf`

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

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