Il y a un truc qui m'a toujours gonflé sur mon RPi et mon OlinuXino (que j'utilise en tant que serveurs à la maison, voir
http://www.guiguishow.info/2013/08/08/auto-hebergement-sur-raspberry-pi/ et
http://www.guiguishow.info/2013/09/07/auto-hebergement-sur-olinuxino/ ), c'est d'avoir un noyau custom en dehors du système de packages.
Alors oui, ça permet au fabricant de fournir quelque chose d'entièrement fonctionnel, avec tous les pilotes, notamment pour la partie audio/vidéo, chose qu'on n'a pas encore avec un noyau upstream/Debian. Mais d'un autre côté, ça veut dire qu'il n'y a aucun suivi de la sécurité sur le noyau. Donc, le jour où une faille de sécurité est découverte, on est mal : car on est vulnérable, exposé (c'est le principe même d'un usage serveur), qu'on ne sait pas si ça sera corrigé ni en combien de temps ça le sera et, enfin, car la mise à jour ne sera pas distribuée via le système de package et qu'il faudra donc creuser un peu pour mettre à jour.
On pourrait penser que seule une faille exploitable à distance peut nous affecter et que, vu qu'elles se comptent sur les doigts des mains dans Linux, on est peinard. Mais il n'en est rien : une faille exploitable localement (qui requiert d'avoir un compte utilisateur sur la machine) peut aussi être exploitée via un serveur web et un site web sur lequel il est possible de poster du contenu. Il faut donc deux failles (site web et faille locale dans le noyau) mais c'est une hypothèse crédible.
ÉDIT DU 29/10/2016 À 19H15 : sans compter ce genre de petites plaisanteries :
http://www.silicon.fr/bug-noyau-linux-allwinner-147233.html - « Comme l’interface de débogage du constructeur est directement accessible via un élément du dossier /proc, un simple « echo « rootmydevice » > /proc/sunxi_debug/sunxi_debug » permet dans la pratique de gagner un accès administrateur. Une faille qui touche tous les terminaux (tablettes, set-top boxes, media players, etc.) équipés d’une puce Allwinner et d’une version officielle d’Android fonctionnant sous Linux 3.4. »
FIN DE L'ÉDIT.
Ce shaarli n'est donc pas exclusivement du pinaillage mais en réaction à quelque chose qui peut péter à la gueule.
Résumons ce que l'on cherche à faire : on ne veut pas compiler un noyau plus récent, on veut vraiment installer le noyau packagé par Debian pour profiter du suivi de sécurité de la team Debian security. On ne veut pas repartir de 0 sur une nouvelle image disque, on veut garder nos binaires et notre configuration actuelle.
Évidemment, je n'ai pas d'écran (ordinateur portable only spotted) et l'OLinuXino veut du 3,3V sur son port série alors que mon câble USB<->RS232 est en 5V. Donc, je n'ai aucun moyen de voir les messages d'erreur au boot, je suis totalement aveugle tant qu'il n'y a pas d'écriture dans les logs ou un sshd en cours de fonctionnement. #YOLO
Et bien entendu, avant de se lancer dans l'aventure, on fait une sauvegarde, c'est à dire un dd de la carte SD !
Pour la Raspberry Pi avec Raspbian :
J'ai tenté d'installer le package linux-image-rpi et de faire la modification dans u-boot comme indiqué ici
http://www.eevblog.com/forum/reviews/howto-get-the-raspian-kernel-installed-with-headers/ mais ça n'a pas fonctionné, la carte ne boote pas. Je pense qu'une mise à jour du firmware est nécessaire.
Il est toujours possible d'utiliser rpi-update (rpi-update ou BRANCH=next rpi-update pour avoir la version en cours de développement), voir
https://www.raspberrypi.org/forums/viewtopic.php?t=113753 qui met à jour le firmware et le noyau. En revanche, les questions initiales ressurgissent ici : en combien de temps la version corrigée d'un noyau est-elle distribuée ?
Pour l'OLinuXino A20-Micro avec l'image Debian fournit par Olimex (« ULTIMATE A20 Debian 4GB SD-card image release-7 with hardware accelerated video » dans mon cas) :
Aeris (
https://imirhil.fr/) signalait sur Twitter avoir réussi à installer le noyau packagé par Debian sur son OLinuXino Lime2 : il faut utiliser installer les packages u-boot-tools, flash-kernel et linux-image-armmp. Sauf qu'au reboot, ça ne boote pas.
Il faut peut-être installer un u-boot plus récent (mainline ou sunxi mais plus récent, Aeris utilise u-boot mainline 2016.01-rc). Soit, on reflash la SD avec notre sauvegarde et on recommence le point précédent. On installe le package u-boot-sunxi et on lance un dd if=/usr/lib/u-boot/BOARD/u-boot-sunxi-with-spl.bin of=/dev/mmcblkX bs=1024 seek=8 comme indiqué dans la doc (/usr/share/doc/u-boot-sunxi/README.Debian). Ça ne fonctionne pas mieux...
Aeris m'indique que les versions récentes d'u-boot ne tolèrent plus la présence de la première partition FAT. Je me souviens d'avoir lu qu'au contraire, les versions récentes cherchent sur toutes les partitions les fichiers dont elles ont besoin pour initialiser le système mais je ne retrouve plus ma source. Soit, je supprime la première partition avec fdisk ( d -> 1 -> w ). Mais la deuxième (devenue première) partition est toujours pointée par la deuxième entrée de la table des partitions. On note l'offset de début de cette partition, on la supprime et on en recréer une, de même type, qui commence au même secteur (pour ne pas perdre des données !). Même avec tout ça, l'OLinuXino ne boote pas.
ÉDIT DU 10/05/2016 À 19h15 : heeeeeeu plutôt que de supprimer la 2e partition puis la recréer afin de remettre en ordre la table des partitions, il vaut mieux utiliser la commande « f » du mode expert de fdisk. Voir
http://thelinuxfaq.com/133-partition-table-entries-are-not-in-disk-order-how-to-solve . Via
http://home.michalon.eu/shaarli/?8WzDbg FIN DE L'ÉDIT.
Hors de question que je crosscompile u-boot : la crosscompilation, c'est toujours la merde le temps de trouver une toolchain fonctionnelle. Je ne fais plus jamais ça, no way. On va donc faire un détour. Pour ceux et celles qui veulent crosscompiler :
https://raymii.org/s/articles/Olimex_OlinuXino_A20_Lime2_Kernel_3.19_uBoot_Debian_7_image_building.html et
http://techieventures.blogspot.fr/2014/10/install-debian-jessie-with-debian-u.html
On repart de zéro (donc sans installer les packages mentionnés ci-dessus) et on installe linux-image-armmp sur l'OLinuXino. Si l'on ne le fait pas, l'OlinuXino ne bootera pas après que l'on ait écrasé le rootfs d'Armbian avec notre "ancien" rootfs car le noyau packagé par Debian est modulaire et les modules seront absents de /lib/modules. On fait un dd de la carte SD.
On télécharge Armbian pour OlinuXino Micro, version jessie vanilla (
http://www.armbian.com/olimex-micro/). On dd l'image sur la carte SD, on assigne une IP dans /etc/network/interfaces et on boote l'OLinuXino avec. Le noyau utilisé est un noyau custom 4.0+ mais on peut désormais installer le noyau packagé par Debian grâce à un u-boot plus récent.
On vire le package linux-image-next-sunxi et on installe le package flash-kernel (si on ne vire pas le package du noyau actuel, flash-kernel échouera...).
On indique le modèle de notre carte à flash-kernel : echo "Olimex A20-Olinuxino Micro" > /etc/flash-kernel/machine .
On modifie le cmdline du noyau dans /etc/default/flash-kernel : « LINUX_KERNEL_CMDLINE="quiet" » devient « LINUX_KERNEL_CMDLINE="quiet console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1". Ces paramètres sont ceux utilisés par Armbian (voir /boot/boot.cmd). Si vous voulez changer l'IO scheduler, c'est aussi ici que ça se passe (en ajoutant « elevator=noop », par exemple).
On installe le package linux-image-armmp. flash-kernel sera déclenché par un trigger en post-build de l'initrd et générera un boot.scr et copiera le dtb (device tree blob) dans /boot. On peut rebooter. Au reboot, uname -a nous montre : « Linux micro 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) armv7l GNU/Linux ». \o/
Maintenant, il faut récupérer notre ancien rootfs avec nos binaires et nos configurations. Certain-e-s préféreront y aller à coup de rsync ou de cp -a, mais je préfère être plus bourrin. :D
On halt l'OlinuXino, on récupère la SD et on fait un sudo cp -a /chemin/vers/la/sd/boot .
Maintenant, on veut copier bit à bit la deuxième partition de notre ancienne installation. On avait fait une image disque. Utilisons-là : kpartx -av /chemin/vers/limage.dd puis dd if=/dev/mapper/loop0p2 of=OlinuXino-old-only-rootfs.dd puis kpartx -dv /chemin/vers/limage.dd.
On écrase le rootfs de la SD avec le rootfs récupéré : dd if=OlinuXino-old-only-rootfs.dd of=/dev/mmcblk0p1 bs=1M . On effectue un fsck -f /dev/mmcblk0p1 pour avoir l'esprit tranquille. On monte la SD, sudo rm -rf /chemin/vers/la/sd/boot puis sudo cp -a boot /chemin/vers/la/sd/ . Il faut vider le fichier /etc/modules qui indique les modules qui seront chargés au boot car les modules sw_ahci_platform, lcd, hdmi, ump, disp, 8192cu, gpio-sunxi et sunxi_cedar_mod n'existent plus donc systemd-modules-load sera en erreur et ça aura des répercussions sur les units qui en dépendent. On peut aussi modifier le fstab sur la SD pour remplacer « /dev/root » par « /dev/dev/mmcblk0 » mais ce n'est pas obligatoire. On peut aussi virer /lib/modules/3.4.67+ pour récupérer 390M mais ce n'est pas obligatoire.
On démonte la SD. Sur notre ancienne installation, nous avions deux partitions. Là, il n'y en a plus qu'une. Le secteur à partir duquel la partition commence n'est pas identique. Il faut donc remettre le système de fichiers en accord avec ce qui est écrit dans le MBR : sudo resize2fs /dev/mmcblk0p1 .
À partir de là, on peut booter l'OlinuXino avec notre ancien rootfs mais un nouveau noyau. \o/
Il faut installer les packages u-boot-tools et flash-kernel pour qu'à chaque mise à jour du kernel, il s'occupe de mettre à jour les infos nécessaires à u-boot. Il faut donc à nouveau réaliser les manip' suivantes : echo "Olimex A20-Olinuxino Micro" > /etc/flash-kernel/machine et modifier /etc/default/flash-kernel . Peut-être qu'on peut installer flash-kernel sur l'ancien rootfs en même temps que le noyau. Ça m'a semblé être une mauvaise idée sur le moment donc je ne l'ai pas fait mais maintenant, je m'interroge...
Je me mets ça de côté :
* L'organisation d'une carte SD quand on utilise u-boot & co :
https://linux-sunxi.org/Bootable_SD_card#SD_Card_Layout
* Toutes les méthodes pour installer un Debian GNU/Linux sur une carte OLinuXino :
https://wiki.debian.org/InstallingDebianOn/Allwinner