cClaude.rocks ☕ Le blog

[Nouvelles technologies du libre, sciences et coups de gueule…]

Menu
😤 Ce billet a été édité le : 2022-12-14

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.



Raspberry en boite

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 !

Enfin, prenez le temps lire l’intégralité de cet article avant de commencer votre migration.

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
┌───────────────────────────────────┤ Samba server and utilities ├─────────────────────────────────┐ │ If your computer gets IP address information from a DHCP server on the network, the DHCP server │ │ may also provide information about WINS servers ("NetBIOS name servers") present on the network. │ │ This requires a change to your smb.conf file so that DHCP-provided WINS settings will │ │ automatically be read from /var/lib/samba/dhcp.conf. │ │ │ │ The dhcp-client package must be installed to take advantage of this feature. │ │ │ │ Modify smb.conf to use WINS settings from DHCP? │ │ │ │ <Yes> <No> │ └──────────────────────────────────────────────────────────────────────────────────────────────────┘

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
┌─────────────────────────────────────┤ Configuring libc6:armhf ├────────────────────────────────────┐ │ There are services installed on your system which need to be restarted when certain libraries, │ │ such as libpam, libc, and libssl, are upgraded. Since these restarts may cause interruptions of │ │ service for the system, you will normally be prompted on each upgrade for the list of services you │ │ wish to restart. You can choose this option to avoid being prompted; instead, all necessary │ │ restarts will be done for you automatically so you can avoid being asked questions on each library │ │ upgrade. │ │ │ │ Restart services during package upgrades without asking? │ │ │ │ <Yes> <No> │ └────────────────────────────────────────────────────────────────────────────────────────────────────┘

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 :

Configuration file '/etc/sysctl.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer’s version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** sysctl.conf (Y/I/N/O/D/Z) [default=N] ?

ou parfois sous cette forme :

┌───────────────────────────────┤ Samba server and utilities ├──────────────────────────────┐ │ A new version (/run/samba/upgrades/smb.conf) of configuration file /etc/samba/smb.conf is │ │ available, but the version installed currently has been locally modified. │ │ │ │ What do you want to do about modified configuration file smb.conf? │ │ │ │ install the package maintainer’s version │ │ keep the local version currently installed │ │ │ │ show a side-by-side difference between the versions │ │ show a 3-way difference between available versions │ │ do a 3-way merge between available versions │ │ start a new shell to examine the situation │ │ │ │ <Ok> │ └───────────────────────────────────────────────────────────────────────────────────────────┘

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…
Package mysql-server is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: mariadb-server-10.0

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 :

┌─────────────────────────────────┤ Configuring mariadb-server-10.0 ├────────────────────────────────┐ │ The old data directory will be saved at new location │ │ │ │ A file named /var/lib/mysql/debian-*.flag exists on this system. The number indicates a database │ │ binary format version that cannot automatically be upgraded (or downgraded). │ │ │ │ Therefore the previous data directory will be renamed to /var/lib/mysql-* and a new data directory │ │ will be initialized at /var/lib/mysql. │ │ │ │ Please manually export/import your data (e.g. with mysqldump) if needed. │ │ │ │ <Ok> │ └────────────────────────────────────────────────────────────────────────────────────────────────────┘

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

ᦿ


ℹ 2006 - 2024 | 🏠 Accueil du domaine | 🏡 Accueil du blog