Le lancement du Raspberry Pi 4 qui a fait le buzz ces jours, mais ce n’était pas le seul nouveau produit à sortir de la Fondation Raspberry Pi.
L’association à but non lucratif a publié une nouvelle version de sa distribution GNU/Linux Raspbian, baptisée Buster
.
Raspbian Buster
est, semble-t-il, la version minimum pour Raspberry Pi 4.
Raspbian Buster
, basé sur Debian 10
, apporte quelques changements majeurs: parmi ceux-ci, le plus important est le passage à un environnement de bureau à accélération matérielle – Attention, l’accélération n’est active, par défaut, que sur le nouveau Raspberry Pi 4 avec son processeur graphique VideoCore VI plus puissant que ce qui est disponible sur les versions précédentes du Raspberry Pi.
Les autres modifications fondamentales concernent principalement les améliorations apportées à la sécurité, en particulier les correctifs apportés aux vulnérabilités matérielles connues dans les cœurs de processeur Arm Cortex-A72
du Raspberry Pi 4.
Une évolution destinée au Raspberry Pi 4 est l’utilisation du pilote UASP
(USB Attached SCSI Protocol) à la place du pilote UMS
(USB Mass Storage) de l’ancien Raspbian Stretch
. Pour ceux qui possèdent des périphériques de stockage externes compatibles UASP
, le nouveau pilote améliore considérablement les vitesses de transfert et réduit l’utilisation du processeur lors de l’accès aux fichiers.
Malheureusement, cette fonctionnalité est exclusivement disponible pour le Raspberry Pi 4: UASP
n’est disponible que sur USB 3.0
ou supérieur.
Installation propre
De loin, le moyen le plus simple et le plus sûr de passer à Raspbian Buster
est de le [télécharger]https://www.raspberrypi.org/downloads/raspbian/
et de le flasher sur une carte microSD. EDIT: Ce lien n’est plus disponible, rendez-vous sur la page de systèmes d’exploitation.
Ces opérations peuvent être réalisées à l’aide de prepare-raspbian-sd.
Migration
Si vous avez une installation Raspbian existante, vous pouvez utiliser Raspbian à la volée cependant vous perdrez certains fichiers. Le risque est vous concerne surtout si vous utiliser la version Desktop (vous perdrez en particulier les applications supplémentaires que vous avez installées et tous les paramètres personnalisés).
Si vous utilisez la version Lite (mode texte uniquement), les risques sont moindres, cependant certain packages ont disparus. C’est, par exemple, le cas de php7-0 par exemple qui n’est plus disponible, il vous faudra migré vers une version plus récente.
Une bonne sauvegarde s’impose !
Vous êtes prévenu !
D’abord identifions les fichiers qui devront être modifiés pour faire la migration :
grep -rl stretch /etc/apt/
Vous devez obtenir :
/etc/apt/sources.list.d/raspi.list
/etc/apt/sources.list
Si le résultat est différent, je vous encourage, à sauvegarder ces fichiers.
Passons à buster
!
La première étape consiste à indiquer à la commande apt
que le système doit utiliser la version buster
au lieu de stretch
. Ici on modifie les fichiers directement sur place.
grep -rl stretch /etc/apt/ | sudo xargs sed -i 's/stretch/buster/g'
Ensuite on va mettre à jour la liste de tous les paquets et demander une mise à jour complète.
sudo apt update && sudo apt dist-upgrade
et avant de redémarrer la machine, la commande suivante permet de s’assurer que toutes les tâches nécessaires ont été faites :
sudo apt full-upgrade
Questions durant la migration
Voici quelques questions que vous êtes susceptible de rencontrer.
Samba et WINS
Il s’agit d’une partie de la configuration réseau, lié à Samba et aux partages pour les machines sous Windows. La réponse qui vous concerne est probablement Yes
. Partant du principe que dans le cas contraire, vous savez pourquoi vous ne souhaitez pas cette fonctionnalité.
Demande de redémarrage des services
Il est raisonnable d’avoir une interruption de service durant un changement de noyau, la réponse est Yes
. Le temps d’interruption est de plus très cours, au point que même un redémarrage de sshd
ne coupe pas la connexion ssh
à travers laquelle vous faite la mise à jour — j’ai essayé, enfin pas volontairement, car ça fait peur quand même 😮.
Demande de modification d’un fichier contenant une configuration non standard
Vous aurez probablement plusieurs questions du type :
ou parfois sous cette forme :
Commencez par répondre D
(show the differences between the versions
) pour avoir une idée de la différence entre votre fichier et celui arrivant avec la nouvelle version. D’une manière ou d’une autre, il est probable que vous ayez à prendre en compte ces changements.
Sur la base de la différence, vous devriez être à même de déterminer si vous devez répondre Y
(install the package maintainer's version
) pour mettre en place le nouveau fichier ou si vous gardez votre configuration à l’aide de N
(keep the local version currently installed
).
A priori, il n’y a pas de bonne réponse, c’est au cas par cas. Vous devez avoir gardé une trace de vos modifications quelque part (dans un bon git
idéalement).
Bon, si vous êtes dépourvu, vous pouvez garder votre configuration, le nouveau fichier sera copié à côté du vôtre et vous pourrez le comparer plus tard. Cela étant par certain que le service associé fonctionne encore après la mise à jour.
Voici quelques cas rencontrés de mise à jour de la configuration.
Il faut avoir une idée des besoins liés aux changements que l’on a réalisé sur les fichiers de configurations pour traiter ces questions. Donc le copier-coller de code les yeux fermés, ça pique un peu lors de ce type de mises à jour…
- '/etc/bind/named.conf.options'
- '/etc/dhcpcd.conf'
- '/etc/mysql/mariadb.conf.d/50-server.cnf'
- '/etc/nginx/nginx.conf'
- '/etc/sysctl.conf'
- '/etc/tomcat8/catalina.properties'
- '/etc/tomcat8/server.xml'
- '/etc/turnserver.conf'
Fichier concerné | Quelques précisions à titre indicatif |
---|---|
/etc/bind/named.conf.options | Lié à bind 9 or il n’y a de changement de version majeur de l’application. Il est raisonnable de parier est que votre fichier est valable. |
/etc/tomcat8/catalina.properties | Lié à Tomcat 8 . |
/etc/tomcat8/server.xml | Lié à Tomcat 8 . |
/etc/nginx/nginx.conf | Lié à nginx . |
Pour ce type d’applications on se réfère rarement à la documentation du système, mais plutôt à celle de l’éditeur. Les fichiers livrés avec l’OS étant là plutôt à titre d’exemple.
Fichier concerné | Cas particuliers, lié au kernel |
---|---|
/etc/dhcpcd.conf | Il s’agit du fichier contenant la configuration du client DHCP (configuration du réseau). La plupart du temps la configuration par défaut est raisonnable, sauf si vous utilisez une adresse IP fixe (par exemple pour un serveur DHCP). |
/etc/sysctl.conf | Il s’agit du fichier contenant la configuration du kernel. Il est à priori assez raisonnable de prendre celui venant avec la version, qui à appliquer des modifications par la suite. Vous pouvez utiliser les commandes man sysctl.conf et man sysctl pour plus de détails. |
Fichier concerné | Applications spécifiques |
---|---|
/etc/turnserver.conf | Lié à coturn , c’est typiquement le type d’application qui ne s’improvise pas, votre configuration est sans doute meilleure que celle du paquet. |
/etc/mysql/mariadb.conf.d/50-server.cnf | Cas particulier, mais lié à mysql , typiquement le genre d’application à poser problème lors de la mise à jour du système. |
😱 Des cauchemars potentiels…
Certaines applications comme php
et mysql
ne vont pas ressortir durant la migration, mais vous pourriez avoir des surprises très rapidement.
Avec stretch
seul le paquet php7-0
était disponible, hors sur buster
il n’existe plus, vous devrez passer sur php7-1
, php7-2
ou php7-3
. Pour ma part, je vous encourage à faire le travail pour migrer sur php7-3
si vous n’avez pas de contre-indication.
De même sur buster
, plus de paquet mysql
, il faut utiliser les paquets préfixés mariadb-
. Pour ma part, avec quelques galères avec la version 10.0, j’ai opté pour mariadb-client-10.3
et mariadb-server-10.3
.
L’installation mariadb
n’a pas été sans problème me concernant, pour commencer le changement de version ne prend pas en charge la migration des données, en gros c’est débrouillez-vous :
Après l’installation, le fichier /etc/systemd/system/mysql.service
lié par un lien symbolique sur /lib/systemd/system/mariadb.service
n’était pas présent. Plus précisément le fichier cible /lib/systemd/system/mariadb.service
manquait. Je pense que c’est la désinstallation du paquet précédent mysql
qui ne s’est pas bien passé. C’est, sans doute, une bonne idée que de le désinstaller, après l’exportation de vos données (avec mysqldump
) et avant le début de la procédure de migration.
J’en tire la conclusion que je devrais refaire assez rapidement les machines ayant php
et mysql
à partir d’une image vierge.
😲 Trucs bizarres !
- Sur une machine j’ai perdue la commande
rsync
lors de la mise à jour, ce problème se corrige facilement avec un :
sudo apt update && sudo apt -y install rsync
Liens
- Buster – the new version of Raspbian,
- Upgrade Your Raspberry Pi to Raspbian Buster, Without Losing Data,
- Chapter 5. Issues to be aware of for bullseye.
ᦿ