f6k ~ Debian sur un Lenovo IdeaPad 100S-11IBY

Fichier créé le 2 octobre 2016 • Dernière mise à jour le 14 novembre 2016.

Ce fichier va retracer l’installation et la configuration de Debian testing sur un Lenovo IdeaPad 100S-11IBY. Cette machine n’est pas totalement bien supportée par l’univers GNU/Linux, aussi il ne faut pas s’attendre à ce que tout fonctionne out of the box. Je retranscris ici ce que j’ai pu effectuer comme manipulation sachant que ça n’est pas toujours très propre, ni dans le bon ordre. Ce fichier n’est donc pas du tout, en l’état, un tutoriel à suivre les yeux fermés. Les principales difficultés rencontrées ont trait à la prise en charge du Wi-Fi, à la mise en veille de la machine ou encore à la détection correcte de la batterie. Tout n’a pas encore été testé à fond, ni résolu complètement ; aussi ce fichier est susceptible d’être mis à jour. Si vous souhaitez connaître mes impressions et l’intérêt du processus en vous épargnant les détails techniques, vous pouvez directement sauter à la conclusion.

Commençons par voir les spécifications matérielles générales.

Composants Boot Notes Statut
Intel Atom CPU Z3735F 1.33GHz OK (Bay Trail) OK
Intel HD Graphics, VGA Contr. OK (Bay Trail) OK
DDR3L SDRAM 2Go 1333 MHz OK N/A OK
LED backlight 1366 x 768 (HD) OK N/A OK
SSD eMMC 32Go OK N/A OK
USB Controller OK N/A OK
Intel SST Audio Device (WDM) Non reconnu RT5640 /!\
Wi-Fi 802.11 bgn, Bluetooth Non détecté RTL8723BS OK (Wi-Fi)
keyboard, touchpad OK N/A OK
31,9 WHr Lithium-Ion Battery Non reconnu N/A /!\
Webcam 0.3MP, Dual Mic. Non testé N/A N/A

Le tableau évolutif ci-dessus montre la situation de la machine avec les principaux composants ; notamment la détection suite au premier boot, des remarques particulières (sur le type ou les modules à utiliser) ainsi que le statut final. En guise de résumé, l’installation de Debian va être faîte en passant par une clef usb. Étant donné que la carte Wi-Fi n’est pas détectée, qu’aucun module pour elle n’existe dans les dépôt Debian et qu’il n’y a pas de carte réseau pour du filaire, il va falloir utiliser une ISO contenant un maximum de paquet. Justement à propos du Wi-Fi. D’après ce que j’ai pu récupérer comme information c’est une Realtek RTL8723BS Wireless Lan SDIO Network Adapter. Ceci étant dit, elle n’est pas du tout détectée par Linux et, pour la faire fonctionner correctement, il faudra patcher le noyau avant d’installer le module adéquat. Ça n’est pas très user friendly mais avec du temps et de la patience, ça marche. À noter que la carte en question est censée aussi prendre en charge le Bluetooth ; cependant le module ne le gère pas, ça ne fonctionne donc pas. Pour ce qui est de la mise en veille prolongée, au moment où j’écris ces lignes, ça ne marche tout simplement pas. Par contre la mise en veille simple de l’écran et l’ajustement de la luminosité fonctionnent sans problème. Sur la question de la prise en charge graphique, rien à déplorer, Xorg fait une détection correcte et applique la bonne résolution. Au niveau du clavier, rien à dire, les touches de personnalisation sont globalement bien détectées et la souris fonctionne bien. Pour ce qui est de la carte son, elle est bien détectée mais elle est non reconnue. Une solution existe mais c’est en phase de test ; dans tous les cas le problème est en cours de résolution. Enfin, je ne me suis pas penché sur la caméra et son microphone intégré.

Sommaire

  1. De la préparation de la clef usb et de l’installation du système
  2. De la configuration du disque électronique
  3. De l’installation du module pour le Wi-Fi
  4. De l’image et du clavier
  5. De la question de la carte son
  6. De la prise en charge de la batterie
  7. De la mise en veille prolongée et de l’hibernation
  8. De l’intérêt d’installer GNU/Linux sur cette machine

De la préparation de la clef usb et de l’installation du système

Avant de commencer il faut savoir que l’architecture de cette machine est en 64 bits mais que le firmware de l’UEFI requiert du 32 bits. Sans commentaire. Par simplicité et parce que ça m’importe peu vu l’utilisation que je vais avoir de cette machine, je vais donc aller au plus rapide et utiliser directement l’image Debian en 32 bits qui contient le fichier EFI\boot\bootia32.efi. Si vous souhaitez utiliser la version Debian 64 bits, il faudra récupérer ce fichier pour le firmware 32 bits et le mettre dans le dossier correspondant sur la clef usb. Vous pouvez retrouver une discussion à ce sujet concernant Ubuntu par ici.

Ayant une clef d’1 Go, j’ai donc récupéré l’image la plus petite que j’ai pu trouver, soit le CD 1 de Debian testing avec Xfce et, étant sur le Windows 10 préinstallé, j’ai utilisé Rufus avec toutes les options par défaut pour créer une clef usb bootable. Si vous avez une machine sous GNU/Linux accessible, l’utilitaire dd est parfait pour ça.

$ dd if=debian-testing-i386-xfce-CD-1.iso of=/dev/sdb bs=4M

Parce qu’aucun accès à internet ne sera possible une fois le système installé, et que je vais avoir besoin de compiler le module pour la carte Wi-Fi, il me faut aussi récupérer les paquets nécessaires à la compilation — qui ne sont pas présents sur l’image Debian que j’ai choisi. Le plus propre pour faire ça est d’utiliser aptly par exemple qui permettra de créer un dépôt personnel sur une autre clef — ou de gérer celui déjà présent sur la clef — afin d’y ajouter ce qui va nous manquer. Par souci d’honnêteté je dois dire que j’ai plutôt privilégié la manière sale en récupérant les paquets depuis les serveurs ftp et en gérant les dépendances à la main — je pensais que ce serait aussi simple à faire que sous Slackware mais il se trouve que non. Voici dans le désordre ce que j’ai mis dans un dossier tmp\debs à la racine de la clef usb :

build-essential_12.2_i386.deb   libmpx2_6.1.1-11_i386.deb
dpkg-dev_1.18.10_all.deb        libperl5.24_5.24.1~rc3-3_i386.deb
g++_6.1.1-1_i386.deb            libstdc++6_6.1.1-11_i386.deb
g++-6_6.1.1-11_i386.deb         libstdc++-6-dev_6.1.1-11_i386.deb
gcc_6.1.1-1_i386.deb            make_4.1-9_i386.deb
gcc-6_6.1.1-11_i386.deb         patch_2.7.5-1_i386.deb
libasan3_6.1.1-11_i386.deb      perl_5.24.1~rc3-3_i386.deb
libdpkg-perl_1.18.10_all.deb    perl-base_5.24.1~rc3-3_i386.deb
libgcc-6-dev_6.1.1-11_i386.deb  perl-modules-5.24_5.24.1~rc3-3_all.deb

Je fais une petite parenthèse ici. J’ai dit en effet plus haut que le module pour la carte Wi-Fi impliquait de patcher les sources du noyau pour fonctionner correctement ; or vous noterez qu’il manque ici, entre autre lesdites sources, les paquets kernel-package, debconf-utils, dpkg-dev, debhelper et fakeroot nécessaires à cette opération. Cela vient du fait que je n’avais pas perçu l’importance au départ de devoir recompiler le noyau en appliquant les patchs. Mais je reviendrai sur ce point dans la section concernant le Wi-Fi. Suivant cette méthode inappropriée, il faudra commencer par installer les différentes librairies, avant les paquets intermédiaires, pour finir par make et build-essential. Je vous invite cependant à ne pas suivre mon exemple — vu notamment les prises de tête que cela peut produire — et, je répète, à utiliser aptly. Il faut aussi penser à récupérer dès à présent les sources du modules rtl8723bs pour la carte Wi-Fi — j’y reviens plus bas — et les mettre quelque part sur la clef ; dans tmp\\ pour ma part. Continuons cependant.

La clef étant maintenant prête, il faut redémarrer pour aller faire un tour dans le BIOS afin de désactiver le Secure Boot. Pour ce faire, après avoir éteint la machine, la redémarrer en utilisant le bouton NOVO (le petit bouton à droite des deux leds). Ceci étant fait, il faut à nouveau redémarrer grâce au bouton NOVO pour, dans le menu de Boot du BIOS, trouver l’entrée qui concerne la clef usb et la charger. Ça démarre doucement et après quelques petits messages d’erreurs, on arrive sur le menu d’accueil. Je suis passé par l’installation en console, à l’ancienne, et celle-ci se passe sans heurts, sinon que l’installeur se plaint de ne pas trouver de carte pour accéder à internet. On continue malgré tout jusqu’à la fin sans problème. À noter que j’ai utilisé le partitionnement avec ext4 par défaut comme vous pouvez le voir ci-dessous. On remarque aussi que le lspci n’est pas très fourni.

# uname -a
Linux shabrya 4.6.0-1-686-pae #1 SMP Debian 4.6.4-1 (2016-07-18) i686 GNU/Linux
# fdisk -l
Disk /dev/mmcblk0: 29.1 GiB, 31268536320 bytes, 61071360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D012185B-81D9-4693-A01F-568055727E3C

Device            Start      End  Sectors  Size Type
/dev/mmcblk0p1     2048  1050623  1048576  512M EFI System
/dev/mmcblk0p2  1050624 57020415 55969792 26.7G Linux filesystem
/dev/mmcblk0p3 57020416 61069311  4048896    2G Linux swap
# lspci -v
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0f)
    Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register
    Flags: bus master, fast devsel, latency 0
    Kernel driver in use: iosf_mbi_pci

00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0f) (prog-if 00 [VGA controller])
    Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series Graphics & Display
    Flags: bus master, fast devsel, latency 0, IRQ 203
    Memory at 90000000 (32-bit, non-prefetchable) [size=4M]
    Memory at 80000000 (32-bit, prefetchable) [size=256M]
    I/O ports at 1000 [size=8]
    [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
    Capabilities: [d0] Power Management version 2
    Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
    Capabilities: [b0] Vendor Specific Information: Len=07 <?>
    Kernel driver in use: i915
    Kernel modules: i915

00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI (rev 0f) (prog-if 30 [XHCI])
    Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
    Flags: bus master, medium devsel, latency 0, IRQ 201
    Memory at 90800000 (64-bit, non-prefetchable) [size=64K]
    Capabilities: [70] Power Management version 2
    Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci

00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0f)
    Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine
    Flags: bus master, fast devsel, latency 0, IRQ 255
    Memory at 90700000 (32-bit, non-prefetchable) [size=1M]
    Memory at 90600000 (32-bit, non-prefetchable) [size=1M]
    Capabilities: [80] Power Management version 3
    Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit-

00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0f)
    Subsystem: Lenovo Atom Processor Z36xxx/Z37xxx Series Power Control Unit
    Flags: bus master, medium devsel, latency 0
    Capabilities: [e0] Vendor Specific Information: Len=0c <?>
    Kernel driver in use: lpc_ich
    Kernel modules: lpc_ich

De la configuration du disque électronique

Maintenant que le système est installé et afin de préserver le disque électronique, il est expliqué dans la documentation d’ubuntu-fr.org à propos du SSD qu’il est bien de rajouter l’option noatime pour tous les disques ce qui a pour fonction de diminuer « la fréquence d’écriture sur les partitions en évitant d’écrire sur le disque la date du dernier accès en lecture lorsqu’il n’y a pas d’écriture ». Techniquement il faut bien noter que cette machine ne possède pas de SSD mais une carte MMC. Comme je veux la préserver de la même manière des écritures intempestives, je vais suivre les mêmes conseils. L’option n’est pas activée par défaut sous Debian ; pour ce faire, il suffit de modifier le fichier /etc/fstab et de la rajouter pour toutes les partitions ext4. Au prochain redémarrage, ce sera pris en compte.

UUID=[UUID-DU-DISQUE]  /  ext4  noatime,errors=remount-ro  0  1

Il peut aussi être intéressant de déplacer les fichiers temporaires — notamment /tmp et /var/log — dans la mémoire vive de la machine à l’aide de tmpfs. L’intérêt est évidemment de préserver le disque ; l’inconvénient est la perte de ces données d’une session à l’autre. Autant, ça ne pose pas de problème pour le dossier temporaire du système que pour les journaux d’activité, dans le cas d’un dépannage après un crash par exemple, c’est plus équivoque. Je n’ai pas encore tranché la question pour le moment et remet cette possibilité à plus tard. Si le système s’avère stable dans le temps, je verrai à utiliser cette solution.

De l’installation du module pour le Wi-Fi

La première chose importante à faire est de se débrouiller pour avoir un accès à internet. Pour cela il va falloir faire fonctionner la carte Wi-Fi. dmesg, dmidecode et lspci étant totalement muet sur la question, il a fallu creuser un peu. Lors de mes recherches, suivant les tests de Tuxicate, j’ai cru que le module qui devait être utilisé était rtl8723be présent dans Debian au sein du paquet firmware-realtek. Or, Tuxicate a un IdeaPad 100-14IBY et je me suis très vite rendu compte que le module qui fonctionnait pour lui ne donnait aucun résultat pour moi — j’ai un 100S-11IBY, je le rappelle. Finalement, après avoir poussé un peu plus mes recherches, j’ai découvert (je ne sais plus sur quel forum) que le module à charger est rtl8723bs. Mais celui-ci n’est pas présent dans le paquet fourni par Debian — évidemment ça aurait été trop facile. Bastien Nocera a cependant mis en ligne les sources à compiler pour notre carte : https://github.com/hadess/rtl8723bs. Le souci est que, compilé simplement comme ça, le module rend le noyau quelque peu instable et généralement il finit par geler le système après une demi-heure ou une heure d’utilisation du Wi-Fi (une recherche dans un moteur de recherche donne de nombreux exemples). Tout cela sans parler du fait que l’accès à internet est lui-même assez erratique, souvent lent, et même conduit parfois à des timeout. Afin d’avoir un accès, j’ai malgré tout compilé le module en l’état après avoir installé le paquet linux-headers correspondant à mon noyau présent dans les dépôts de la clef usb.

À ce propos, nouvelle parenthèse, pour installer des paquets, j’ai dû modifier un peu le fichier /etc/apt/soures.list afin d’y rajouter une ligne en accord avec le point de montage de ma clef et de commenter tout le reste.

deb file:/mnt/memory stretch main

Après ça, il faut mettre à jour la base de donnée en s’abstenant de faire la vérification des signatures du dépôt — la date de validité étant dépassée dans mon cas. Il se plaint un peu mais ça passe.

# apt-get -o Acquire::Check-Valid-Until=false update

Mon module étant compilé et chargé, je confirme que le système, après un certain temps, a des problèmes et envoie des interruptions matérielles (IRQ). Aussi je n’ai activé le Wi-Fi que pour faire les mises à jour du système et récupérer ce qu’il faut pour la suite, priant à chaque fois pour que le système ne plante pas — ce qui est quand même arrivé deux fois, sans parler d’un reisub salvateur. Ça n’est vraiment pas idéal et le mieux est, à nouveau, si on dispose d’une autre machine, de se faire un dépôt sur une clef usb à l’aide d’aptly.

Je continue donc avec un accès internet fonctionnel, même si précaire. L’idée est maintenant de recompiler le noyau après y avoir appliqué les patches fournis dans les sources de notre module, en utilisant les explications présentes sur le wiki de debian-fr.xyz. Je vais développer un peu le processus parce que j’ai rencontré quelques petites embûches. Notez que j’ai testé l’application des patches sur le noyau dans sa version 4.7 mais ils ne sont pas à jour et ne s’appliquent pas correctement (notamment le second sur shdci, voir ici pour plus de détails) ; je reste donc sur la même branche du noyau installé. Pour information, le numéro de version au moment où j’écris ces lignes est 4.6.0-1-686-pae. Il m’a donc fallu récupérer les sources correspondantes contenant déjà les patches Debian et y appliquer les patches du module fournis pour les noyaux supérieurs ou égaux à 4.5 (présent dans le dossier patches_4.5/).

Après avoir mis à jour mon sources.list, je commence par installer les outils nécessaires à la compilation du noyau — sachant que j’avais déjà installé, à l’aide de dpkg et pour ma première compilation du module, build-essential et les autres paquets que j’ai mis à la main sur ma clef. On notera dans ce qui suit la présence d’une part de libncurses5-dev pour pouvoir utiliser plus tard l’outil de configuration du noyau ainsi que de libssl-dev parce que, lors de ma première tentative, il s’est plaint de l’absence de openssl/opensslv.h.

# apt-get install kernel-package debconf-utils dpkg-dev debhelper fakeroot libssl-dev libncurses5-dev

Il faut maintenant créer un répertoire de travail, télécharger les sources de notre noyau, les copier dans notre répertoire de travail, appliquer les patches pour le module et configurer le tout.

$ mkdir ~/src
$ wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-source-4.6_4.6.4-1_all.deb
# dpkg -i linux-source-4.6_4.6.4-1_all.deb
$ cp /usr/src/linux-source-4.6.tar.xz ~/src && cd ~/src
$ tar xvf linux-source-4.6.tar.xz && cd linux-source-4.6/
$ patch -p1 < ~/rtl8723bs-master/patches_4.5/0001-PM-QoS-Add-pm_qos_cancel_request_lazy-that-doesn-t-s.patch
$ patch -p1 < ~/rtl8723bs-master/patches_4.5/0002-mmc-sdhci-get-runtime-pm-when-sdio-irq-is-enabled.patch
$ patch -p1 < ~/rtl8723bs-master/patches_4.5/0003-mmc-sdhci-Support-maximum-DMA-latency-request-via-PM.patch
$ patch -p1 < ~/rtl8723bs-master/patches_4.5/0004-mmc-sdhci-acpi-Fix-device-hang-on-Intel-BayTrail.patch
$ patch -p1 < ~/rtl8723bs-master/patches_4.5/0005-mmc-sdhci-pci-Fix-device-hang-on-Intel-BayTrail.patch
$ cp -vi /boot/config-4.6.0-1-686-pae .config

Normalement, il est possible avec make localmodconfig d’adapter le fichier .config à sa machine en y faisant le ménage ; mais comme je ne connais pas bien cette machine, que certaines choses n’ont pas l’air d’être détectées correctement, j’ai privilégié la configuration par défaut du noyau. La compilation est dès lors beaucoup plus longue et intègre des choses qui ne me serviront pas, mais je préfère être prudent. Enfin, on peut aller vérifier ladite configuration grâce à menuconfig.

$ make menuconfig

Par ailleurs, il est bien de prendre soin de vérifier que l’option CONFIG_WIRELESS_EXT est bien mise à y dans le fichier .config — sinon le faire manuellement parce que c’est nécessaire pour la compilation du module. De plus, pour éviter d’avoir une erreur sur la signature des modules à la compilation, il faut aussi vérifier que les options CONFIG_MODULE_SIG_ALL, CONFIG_MODULE_SIG_KEY et CONFIG_SYSTEM_TRUSTED_KEYS dans le fichier sont commentées. Lors de l’étape suivante, il sera généré une nouvelle clef. À ce propos, il est maintenant temps de lancer la compilation du nouveau noyau en profitant des quatre cœurs du processeur.

$ make-kpkg clean # inutile lors de la première tentative
$ fakeroot make-kpkg -j 4 --initrd --append-to-version=-$(whoami)-02 kernel-image kernel-headers

Il y a beau avoir plusieurs cœurs, l’opération prend tout de même un sacré bout de temps ; c’est donc un bon moment pour aller se faire un café et d’en profiter pour prendre une pause. Au final, deux paquets seront présents dans le dossier supérieur qu’il suffit d’installer. Je précise en passant qu’il faut pas mal de place ; mon dossier de source, à la fin de la manœuvre, pesait environ 9 Go.

# dpkg -i linux-image-4.6.4-f6k-02-10.00.Custom_i386.deb
# dpkg -i linux-headers-4.6.4-f6k-02-10.00.Custom_i386.deb

Après avoir redémarré sur le nouveau noyau, on se dirige vers les sources du module pour le compiler et l’installer.

$ uname -a
Linux shabrya 4.6.4-f6k-02 #1 SMP Mon Oct 3 16:54:56 CEST 2016 i686 GNU/Linux
$ cd ~/b/rtl8723s-master
$ make
(...)
# make install
install -p -m 644 r8723bs.ko /lib/modules/4.6.4-f6k-02/kernel/drivers/net/wireless
/sbin/depmod -a 4.6.4-f6k-02
# modprobe r8723bs

Après cela, on verra apparaître grâce à la commande iwconfig une entrée pour wlan0 portant le nom de WIFI@REALTEK. Il suffit alors de configurer son réseau via /etc/network/interfaces par exemple et de lancer ifup wlan0 pour accéder à une connexion Wi-Fi stable.

De l’image et du clavier

Je ne vais pas m’étendre sur la prise en charge graphique car tout marche parfaitement. La résolution est bien détectée et est automatiquement gérée par le système tant dans la console que sous Xorg. À ce propos il est tout à fait possible de gérer la luminosité de l’écran, notamment via /sys/class/backlight/intel_backlight/brightness. La mise en veille de l’écran fonctionne elle aussi très bien ; l’appui sur une touche le réveille. Pour ce qui est du clavier et de la souris, tout fonctionne bien aussi y compris les touches de fonctions ; j’ai mis la configuration par défaut en français avec pc105. Je vais par contre faire un point sur les touches spéciales du clavier — c’est-à-dire les touches pour faire varier le volume, la luminosité, etc. Elles sont dans leur majorité bien détectées et fonctionnelles. Dans le tableau qui suit, je vais pointer ce qu’elles sont censées faire, leur emplacement, comment elles sont détectées par Xorg (grâce à xev) et leur état — c’est-à-dire si elles fonctionnent.

Fonction Fn Xorg Statut
Volume muet F1 XF86AudioMute OK
Baisser le volume F2 XF86AudioLowerVolume OK
Augmenter le volume F3 XF86AudioRaiseVolume OK
Fermer la fenêtre F4 F4 /!\
Rafraîchir la page F5 F5 OK
(dés)Activer la souris F6 N/A OK
Mode avion F7 N/A N/A
Tabulation F8 Tab OK
Éteindre/Allumer l’écran F9 N/A OK
Passer sur un autre écran F10 N/A N/A
Baisser la luminosité F11 XF86MonBrightnessDown OK
Augmenter la luminosité F12 XF86MonBrightnessUp OK

Deux touches ne produisent aucun effet ; celle qui est censée passer la machine en mode avion (équivalent F7) ainsi que celle qui doit fermer la fenêtre courante (équivalent F4). La première n’est pas du tout détectée par xev tandis que la seconde renvoie simplement F4 — comme la touche de fonction équivalente. Celle qui permet d’activer et ou de désactiver la souris (équivalent F6) — pratique lorsqu’on tape des documents par exemple — fonctionne parfaitement même si xev ne renvoie rien du tout. De même pour la touche permettant d’éteindre ou d’allumer l’écran (équivalent F9) qui fonctionne parfaitement sans renvoyer quoique ce soit. Il faut remarquer que je n’ai pas pu tester complètement la touche pour passer sur un autre écran (équivalent F10) car je n’en possède pas. Les autres touches fonctionnent comme attendu.

De la question de la carte son

À nouveau, par défaut, la carte son ne marche pas. Pour information la carte sur cette machine est une Intel SST Audio RT5640. Deux rapports de bug notamment sont ouverts sur kernel.org à ce propos, à savoir ici et ici — les commentaires sur le deuxième étant bien plus fournis. La bonne nouvelle c’est que le problème est en cours de résolution. Si l’on se réfère à un autre rapport de bug sur cette carte, il est possible de la faire marcher en utilisant le firmware fw_sst_0f28_ssp0.bin — en lieu et place du fw_sst_0f28.bin du paquet firmware-intel-sound qui lui ne marche pas. Pour faire ça, nous allons suivre les explications d’Antonio Cao pour cette carte. Attention cependant, prévient-il, tout ceci est encore en phase de test et certains utilisateurs ont rapporté qu’utiliser cette carte à ce stade de développement pouvait donner un son distordu et, même, que les enceintes pouvaient être endommagées si le son était mis trop fort. De plus le passage des enceintes aux écouteurs n’est pas encore automatique ; il faudra donc le faire à la main — Antonio recommande l’utilisation de pavucontrol pour ceux qui sont sous PulseAudio.

Il faut donc récupérer le dossier sound/ depuis son dépôt. Ce dossier contient entre autre le firmware en question et des fichiers de configurations. Il faut aussi récupérer un Use Case Manager (UCM) pour Alsa (bytcr-rt5460/), spécifique pour cette carte. Je vais tout d’abord vérifier que le paquet de Debian est bien installé puis faire une copie du firmware original pour le remplacer par le nouveau. Ensuite, il faudra rajouter la configuration pour Alsa avant d’y ajouter les fichiers UCM.

$ cd ~/b/sound/
# apt-get install firmware-intel-sound
# cp /lib/firmware/intel/fw_sst_0f28.bin /lib/firmware/intel/fw_sst_0f28.bin.orig
# cp firmware/fw_sst_0f28_ssp0.bin /lib/firmware/intel/fw_sst_0f28.bin
# cp asound.state /var/lib/alsa/
# alsactl restore
# sh set-alsa-bytcr-rt5640.sh
# cp -rf ~/b/bytcr-rt5640/ /usr/share/alsa/ucm/

Au final, après avoir joué avec le mixer d’Alsa, la carte son marche à peu près mais il est clair que ça n’est pas prêt pour une utilisation normale. Cependant des progrès ont été fait et les développeurs sont sur la bonne voie. Il ne reste donc plus qu’à attendre d’avoir un firmware et une configuration plus stable.

De la prise en charge de la batterie

Voici un point épineux. Les informations concernant la batterie se trouvent bien dans /sys/class/power_supply/BMBT/ mais elle est très mal détectée. Ainsi il n’y a pas moyen de savoir le niveau de batterie, si elle est en charge ou non, ni d’agir sur elle. Voici cependant les informations que je tire de dmidecode.

Handle 0x001A, DMI type 22, 26 bytes
Portable Battery
    Location: I2C2
    Manufacturer: Intel SR 1
    Manufacture Date: Date
    Serial Number: 123456789
    Name: SR Real Battery
    Chemistry: Lithium Ion
    Design Capacity: 0 mWh
    Design Voltage: 3750 mV
    SBDS Version: CRB Battery 0
    Maximum Error: Unknown
    OEM-specific Information: 0x00000000

Bien que j’ai plus de données que d’autres, on voit que mon BIOS (version EC2N13WW, à jour) envoie des informations douteuses — le numéro de série notamment. D’après ce que je comprend en suivant cette discussion suite au rapport de bug, le problème avec la batterie viendrait probablement du firmware qui n’est pas adapté ; mais il ne sera pas révisé avant qu’un nouveau BIOS ne soit diffusé par Lenovo réglant la détection pour cette machine (voir le commentaire 8). Autrement dit le problème n’est pour le moment pas réglé, et personne ne semble travailler dessus. De plus, quand on se rend compte que la dernière mise à jour du BIOS date de la fin janvier de cette année, on peut se dire que Lenovo n’est pas prêt de régler ce souci — surtout quand on voit comment est géré le support du BIOS pour Linux sur d’autres modèles grands publics de la marque. Subséquemment, il n’y a qu’un pas à faire pour dire que la batterie n’est pas prête de fonctionner pleinement sous Linux. Ceci étant dit, d’après mon expérience au jour le jour, j’ai l’impression que la batterie tient normalement.

De la mise en veille prolongée et de l’hibernation

Pour la question de la mise en veille prolongée — je ne vais pas ménager de suspens — ça ne marche pas, pas plus que l’hibernation. Pour rappel, d’une part la machine dispose de 2 Go de RAM, ce qui est amplement suffisant pour suspendre mon système vu l’utilisation minimale que j’en ai. D’autre part, étant sous Debian testing, c’est systemd qui est installé et qui gère cette partie. Tous les tests effectués ne donnent pas grand chose. C’est-à-dire qu’un sudo systemctl suspend ou un sudo tee /sys/power/state <<< freeze ne font rien d’autre que geler le système sans possibilité d’en sortir — pareil pour l’hibernation. J’ai lu que chez certains, l’ordinateur se plongeait tout de même en veille au sens où l’écran devient noir et les leds s’éteignent. Ce n’est pas le cas chez moi ; après avoir entré ces commandes l’écran se fige et plus rien n’est accessible. La seule solution est d’éteindre la machine en maintenant un appui long sur le bouton d’alimentation. De plus, les journaux systèmes ne sont pas très prolifiques en informations comme on peut le voir avec les tentatives de mise en veille prolongée.

# grep -i suspend /var/log/daemon.log
Oct  3 04:08:07 shabrya systemd[1]: Starting Suspend...
Oct  3 04:08:07 shabrya systemd-sleep[3132]: Suspending system...

Pour ce qui est du journal de systemd, il n’en dit pas plus. La question de la mise en veille prolongée et de l’hibernation est connue pour être problématique sur les Intel Bay Trail. Si l’on suit les explications d’Antonio Cao, le circuit intégré s’occupant de la gestion d’énergie (power management integrated circuit (PMIC) en anglais) sur ces Intel se nomme Crystal Cove et le support n’est pas pleinement pris en charge par les noyaux Linux dans leur version 4.x. De plus, si l’on en croit ce rapport de bug sur kernel.org, le défaut pour notre machine aussi, et à nouveau, viendrait du BIOS (voir le commentaire 3). Même solution donc que précédemment ; on attend que Lenovo veuille bien mettre à jour le BIOS ou bien on attend une version supérieure du noyau en espérant qu’un développeur trouve une façon de contourner le problème.

De l’intérêt d’installer GNU/Linux sur cette machine

Le Lenovo IdeaPad 100S-11IBY est un ordinateur intéressant pour qui veut avoir une machine nomade sous la main. Elle pèse à peu près un kilogramme et sa taille de 11 pouces fait qu’elle se glisse très facilement dans un sac. Propulsée par un Intel Atom quatre cœurs, disposant de 2 Go de RAM et de 32 Go de mémoire morte (MMC), il ne faut pas s’attendre à de grandes performances. Cependant pour de la bureautique et de la navigation sur internet, il ne faut vraiment pas plus. Les spécifications annoncent aussi une autonomie sur batterie de plus de 10 heures en utilisation normale et ça n’est pas un mensonge. Ayant eu besoin en début d’année scolaire d’un ordinateur pour remplacer mon vieillissant IBM Thinkpad x60, je me suis dirigé vers cette machine que j’ai acheté sur Cdiscount pour 190 euros. Je dois dire que pour les cours, elle fait le travail et, si l’on met de côté le Windows 10 préinstallé, je n’ai franchement pas à m’en plaindre. Il faut noter que je n’avais pas touché à un Windows depuis plus de dix ans ; autant dire que la transition vers la dernière mouture de la firme de Redmond a été difficile. À cause de la baleine qu’est ce système d’exploitation, certaines opérations étaient vraiment lourdes, cela malgré les assez bonnes spécifications de la machine — il faut plusieurs longues secondes par exemple pour lancer Firefox même sans aucun module supplémentaire. Après un mois, j’ai donc finalement décidé de tenter l’aventure du libre sur cette machine et cela malgré tous les messages alarmants que l’on peut trouver aux quatre coins du web. Au programme, des problèmes pour démarrer n’importe quelle distribution de GNU/Linux, une carte Wi-Fi non détectée, une carte son non reconnue, et les joies de l’Intel Bay Trail très mal supporté par le noyau Linux.

Au bilan des opérations, et après avoir passé environ quatre jours à me battre avec cet IdeaPad, Debian tourne comme il faut et est rapide. Le Wi-Fi est parfaitement fonctionnel pourvu que compiler un noyau ne fasse pas peur. La carte son, quant à elle, n’est pas au mieux de sa forme, ça marche mais ça ne va pas loin. Sur les points noirs, la gestion de la batterie est impossible et, pire dans mon cas, impossible de mettre la machine en veille prolongée ou même en hibernation. Étant donné que je me balade toute la journée sur le campus, mon ordinateur à la main, me déplaçant d’amphithéâtres en salles de cours, ce dernier point est vraiment problématique. Autant il est concevable d’éteindre et de rallumer sa machine une fois ou deux par jour, autant devoir le faire une douzaine de fois dans la journée devient assez vite barbant. L’autre solution est de considérer l’option où on laisse la machine allumée tout le temps même lors des déplacements — solution que je ne retiens pas.

Alors est-ce que le passage sous Debian vaut le coup ? Du point de vue de l’investissement en temps pour le résultat obtenu, clairement pas. Comme beaucoup, je n’ai malheureusement pas le temps, j’ai simplement besoin que ça marche. La pierre n’est pas à jeter du côté des développeurs du noyau ; on voit très vite qu’ils se donnent beaucoup de mal pour que la matériel soit pris en charge, et il est de toute façon normal d’avoir à attendre un peu avant que tout soit parfaitement reconnu. Si vous avez lu les sections supérieures de ce fichier, vous avez compris que les deux problèmes majeurs viennent d’un BIOS qui n’est pas au point ; Lenovo n’ayant rien fait en près de huit mois pour régler le souci qui implique, simplement, de faire en sorte que le matériel y soit bien détecté. Ainsi, en attendant d’avoir un noyau Linux qui contourne les problèmes pour mieux prendre en charge cet ordinateur, je dirais que si on a besoin d’une machine à écrire performante en mettant de côté la possibilité d’une utilisation très nomade et l’investissement temps pour arriver à un résultat mitigé, alors oui je pense que ça pourrait valoir le coup. Mais, autant dire que dans mon cas, le côté nomade étant un point sensible, je me pose sérieusement la question de remettre Windows dessus et de m’arranger avec les logiciels libres qui y sont disponibles couplés à un serveur personnel qui, lui, tournerait sous GNU/Linux. J’ai choisi Lenovo parce que j’ai un peu d’expérience avec eux mais il est évident qu’il est de plus en plus difficile d’avoir un système alternatif libre fonctionnel sur leurs nouveaux modèles. Et ça n’est pas une question de prix ; des problèmes similaires, voir bien plus graves, existent chez Lenovo sur des machines bien plus onéreuses et il est évident qu’ils ne mettent en plus aucune bonne volonté pour faciliter l’installation et l’utilisation d’autre chose que Windows. Est-ce que j’aurai du éviter Lenovo ? Peut-être. Peut-être aurais-je du acheter l’Asus 11 pouces que j’ai vu et qui est dans la même gamme de prix mais, sincèrement, je ne pense pas que j’aurai eu moins de problèmes. Il suffit d’aller faire un tour sur les forums de toutes les distributions. Ils sont remplis de personnes qui ont des soucis avec des ordinateurs portables récents, qu’importe la marque et qu’importe la gamme de prix ; et les solutions sont finalement peu nombreuses au regard de tous les problèmes posés.

Je me souviens encore de la bulle d’oxygène il y a quelques années où les ordinateurs étaient libérés les uns après les autres, grâce notamment aux efforts de la communauté Ubuntu. Cela laissait présager un bel avenir pour les systèmes alternatifs en général et nombreux étaient ceux à prédire la mort lente, mais implacable, de Windows. Avec le recul il est évident de constater que la réalité aujourd’hui est bien différente. J’aurai peut-être du m’acheter une machine plus vieille sur eBay, une seconde voire même troisième main avec beaucoup moins d’autonomie malgré sa batterie neuve. Peut-être que je n’aurai pas du succomber, comme tant d’autres, aux sirènes de la modernité, de la légèreté et de l’autonomie d’une machine récente très exotique produite uniquement pour ne fonctionner correctement qu’avec un Windows 10 dernier cri.