OpenWRT : Gérer correctement le processus de mise à niveau (sysupgrade)

Article publié, le 14 Septembre 2020 et modifié le 27 Mars 2024
10 minutes de lecture

Cet article contient 2115 mots.
Source brute de l'article :
Commit version : 1529275

Description

OpenWRT a un outil pour faire la mise à niveau d’une version à une autre nommé sysupgrade. Il est possible de l’invoquer depuis l’interface web d’administration LuCI.

Si le procédé vous intéresse plus que le faire par CLI, lisez la note en question : Flash depuis LuCI

Le procédé suivant explique pas-à-pas la mise à niveau tout en mode CLI, tout en préservant la configuration utilisateur…

Procédé

La première chose à laquelle nous veillons est d’installer l’outil curl, car par défaut le binaire wget nativement installé ne supporte pas TLS.

# opkg install curl

opkgscript.sh

Le script opkgscript.sh permet de sauvegarder la liste des paquets installés en sus de la base.

⇒ Récupèrons le depuis opkgscript.sh :

$ curl -O https://raw.githubusercontent.com/richb-hanover/OpenWrtScripts/master/opkgscript.sh

⇒ Donnons les droits d’exécution nécessaire : # chmod 0700 opkgscript.sh

⇒ Sauvegardons la liste des paquets installés - pour pouvoir restaurer après la mise à niveau système :

# ./opkgscript.sh -v write

Le script écrit la liste dans un fichier /etc/config/opkg.installed.

Téléchargement firmware

Depuis le répertoire /tmp, récupèrons la nouvelle version du firmware :

e.g. pour la version actuelle :

# v="23.05.4"

⇒ pour le routeur Ubiquiti EdgeRouter X :

# curl -O https://downloads.openwrt.org/releases/"${v}"/targets/ramips/mt7621/{openwrt-"${v}"-ramips-mt7621-ubnt_edgerouter-x-squashfs-sysupgrade.bin,sha256sums}

⇒ pour le Xiaomi Mi Router AX3000T :

# curl -O https://downloads.openwrt.org/releases/"${v}"/targets/mediatek/filogic/{openwrt-"${v}"-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin,sha256sums}

⇒ pour le Xiaomi Redmi Router AC2100 :

# curl -O https://downloads.openwrt.org/releases/"${v}"/targets/ramips/mt7621/{openwrt-"${v}"-ramips-mt7621-xiaomi_redmi-router-ac2100-squashfs-sysupgrade.bin,sha256sums}

Vérification du téléchargement

Puis, nous vérifions la somme de contrôle afin de nous assurer du firmware :
$ sha256sum -c sha256sums 2> /dev/null | grep OK

⇒ Résultat correct pour le routeur Xiaomi Redmi Router AC2100 :
openwrt-23.05.4-ramips-mt7621-xiaomi_redmi-router-ac2100-squashfs-sysupgrade.bin: OK

Danger

ATTENTION : Si la vérification échoue, allez en discuter sur le forum !

Ne cherchez pas à mettre à jour avec un micro-logiciel corrompu !!!

Sauvegarde configuration

L’étape suivante est de vérifier la configuration de la sauvegarde :

# sysupgrade -l

Si nécessaire, il faut éditer le fichier pour ajouter certains répertoires/fichiers, ainsi dans le cas où un utilisateur a été ajouté correctement au groupe `sudo` , il faudra ajouter ce qui suit dans le fichier /etc/sysupgrade.conf :

/etc/sudoers
/etc/sudoers.d/

Vérifions à nouveau - et sauvegardons la configuration :

# sysupgrade -b /tmp/backup-${HOSTNAME}-$(date +%F).tar.gz

Info

On peut remarquer que dans la sauvegarde en question se trouve le fichier /etc/config/opkg.installed précédemment créé avec le script opkgscript.sh.

Puis, il faut récupèrer cette sauvegarde : $ scp root@openwrt:/tmp/backup*.tar.gz $(pwd) (où ‘openwrt’ est l’adresse IP de votre routeur…)

Info

Si vous avez le message d’erreur suivant : ash: /usr/libexec/sftp-server: not found

Merci de lire la note suivante À-propos de SSH v9.0 et supérieure

La note À-propos de la libération de la mémoire peut-être intéressante à lire, mais peu utile dans le contexte des deux routeurs mis en exemple, tel que le Ubiquiti EdgeRouter X ou le Xiaomi Redmi Router AC2100 car dans leur cas, une RAM conséquente est embarquée.

Mise à Niveau Système

Passons à la mise à niveau système, tel que :

# sysupgrade -v openwrt-"${v}"-*-sysupgrade.bin

⇒ Exemple, pour le routeur Ubiquiti EdgeRouter X :

# sysupgrade -v openwrt-"${v}"-ramips-mt7621-ubnt-erx-squashfs-sysupgrade.bin`
(date) upgrade: Saving config files...
etc/config/dhcp
etc/config/dhcp-opkg
etc/config/dropbear
etc/config/firewall
etc/config/https-dns-proxy
etc/config/https-dns-proxy-opkg
etc/config/luci
etc/config/luci-opkg
etc/config/network
etc/config/openssl
etc/config/opkg.installed
etc/config/rpcd
etc/config/system
etc/config/travelmate
etc/config/ubootenv
etc/config/ucitrack
etc/config/ucitrack-opkg
etc/config/uhttpd
etc/config/uhttpd-opkg
etc/config/unbound
etc/config/unbound-opkg
etc/config/wifi_schedule
etc/config/wifi_schedule-opkg
etc/config/wireless
etc/crontabs/root
etc/dropbear/authorized_keys
etc/dropbear/dropbear_ed25519_host_key
etc/dropbear/dropbear_rsa_host_key
etc/fw_env.config
etc/group
etc/hosts
etc/inittab
etc/luci-uploads/.placeholder
etc/nftables.d/10-custom-filter-chains.nft
etc/nftables.d/README
etc/opkg/keys/0b26f36ae0f4106d
etc/opkg/keys/1035ac73cc4e59e3
etc/opkg/keys/2f8b0b98e08306bf
etc/opkg/keys/4d017e6f1ed5d616
etc/opkg/keys/5151f69420c3f508
etc/opkg/keys/72a57f2191b211e0
etc/opkg/keys/792d9d9b39f180dc
etc/opkg/keys/9ef4694208102c43
etc/opkg/keys/b2d571e0880ff617
etc/opkg/keys/b5043e70f9a75cde
etc/opkg/keys/c10b9afab19ee428
etc/opkg/keys/dace9d4df16896bf
etc/opkg/keys/dd6de0d06bbd3d85
etc/opkg/keys/f94b9dd6febac963
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/shinit
etc/sudoers
etc/sysctl.conf
etc/sysupgrade.conf
etc/unbound/unbound.conf
(date) upgrade: Commencing upgrade. Closing all shell sessions.

Normalement votre session SSH va se fermer et le routeur démarrer !

Info

Lors de la reconnexion au routeur depuis votre client SSH, il peut arriver que la connexion soit empêchée avec le message d’erreur suivant :

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED. Si c’est le cas, merci de lire la note adéquate : À-propos de l’identification de l’hôte à distance par SSH

Si jamais vous faites une migration depuis 19.07.x vers 21.02.x ou supérieure, veuillez lire impérativement la note ad hoc : À-propos de la Migration vers ≥ 21.02.0

Après le reboot, il peut arriver que le routeur n’ait plus accès à Internet. Merci de vérifier le fichier /etc/resolv.conf et de le reconfigurer si besoin.

Vérification nouvelle version

À partir du moment où vous pourrez vous connecter à nouveau à votre routeur, vous retrouverez l’information relative à votre nouvelle version :

depuis LuCI, aller vers “Status” > “Overview”, celui-ci sera affiché dans la section “System”, face à l’information “Firmware version”
en SSH, dans la bannière de connexion affichant ce nouveau numéro de version, comme ci-dessous :

BusyBox v1.36.1 (2024-07-15 22:14:18 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 23.05.4, r24012-d8dd03c46f
 -----------------------------------------------------

resolv.conf

À ce moment de l’étape, il est possible que vous ne puissiez plus communiquer avec l’extérieur, car le fichier /etc/resolv.conf est toujours configuré pour la résolution de noms en interne, tel que :

# cat /etc/resolv.conf
search huc.home
nameserver 127.0.0.1
nameserver ::1

Dans ce cas, éditez le fichier pour ajouter un serveur DNS à interroger, tel que ceux de la FDN : 80.67.169.12 et/ou 80.67.169.40. Par exemple :

# sed -i -e 's/127.0.0.1/80.67.169.12/' /etc/resolv.conf

Mise à Niveau “tiers”

Attention

Sur les routeurs ayant moins de 4 Mo de NVRAM, les mises à jour peuvent ne pas avoir lieu correctement ; il est nécessaire de s’assurer d’avoir au moins 600 Ko de libre.

Essayez de libérer de la mémoire …

Vérifiez les caractéristiques techniques de votre routeur !

⇒ Effectuons la mise à niveau des paquets tiers :

# opkg update && opkg list-upgradable

Normalement suite à la mise à niveau, il ne devrait pas y en avoir.

S’il y en a, exécutez la commande suivante :

# for name in `opkg list-upgradable | awk '{print $1}'`; do opkg upgrade "${name}"; done

Restauration profil utilisateur

Pour restaurer le profil utilisateur, on répète les étapes d’installation de l’outil curl, puis du script opkgscript.sh.

Et une fois installé et les droits d’exécution attribués, on l’exécute pour qu’il complète l’installation du “profil utilisateur” :

# ./opkgscript.sh -v install

Pour finir, mieux vaut redémarrer !

Ultimes Vérifications

Ensuite, vérifier la configuration de votre routeur :

que vos différentes interfaces réseaux soient toujours présentes et opérationnelles.
que votre configuration “firewall” soit correcte ; vérifiez dans les différents onglets votre configuration.
que les différents services, que vous auriez précédement installés, soient toujours opérationnels, tel qu’un tunnel IPv6, OpenVPN, ou tout service accessible depuis le menu “Services”.

Voilà…

Normalement, tout devrait fonctionner correctement en suivant ce processus de mise à niveau.

Notes

Retrouvez ci-dessous différentes notes d’informations utiles, seulement dans certains contextes.

Flash depuis LuCI

Depuis le menu “System” > “Backup / Flash firmware” de l’interface web LuCI :

1/ Il est utile d’aller à l’onglet ‘Configuration’ pour modifier la liste des fichiers personnalisés à sauvegarder aussi… Si les fichiers et autres répertoires relatifs à l’installation de binaires tiers ne sont pas écrits ici, rien ne sera sauvegardé !

2/ Faites une sauvegarde de votre configuration d’OpenWRT depuis l’onglet ‘Actions’, section ‘Backup’.

3/ Lors du processus pour flasher une nouvelle image de mise à niveau :

⇒ Pensez à utiliser les options :

la case à cocher KEEP SETTINGS AND RETAIN THE CURRENT CONFIGURATION, à minima
la case à cocher INCLUDE IN BACKUP A LIST OF CURRENT INSTALLED PACKAGES AT /ETC/BACKUP/INSTALLED_PACKAGES.TXT, qui inclut une liste des paquets supplémentaires installés par vos soins.

Si ces cases ne sont pas cochées, vous perdrez toute votre configuration lié à OpenWRT.

De même les binaires tiers seront dans tous les cas à réinstaller, voire à reconfigurer.

Gardez à l’esprit QUE des changements induits par les mises à niveau vers une version majeure peuvent poser des soucis lors de la migration. Il peut y avoir des changements critiques.

À-propos de SSH v9.0 et supérieure

Si votre client SSH est de version ≥ 9.0 :

À partir de la version 9.0 de SSH, le comportement de scp a changé. Dans l’état, la commande ci-dessus échouera avec le message d’erreur suivant :

scp router:/tmp/backup-***-2022-04-21.tar.gz .
ash: /usr/libexec/sftp-server: not found
scp: Connection closed

Dans les faits, Dropbear ne peut plus discuter avec…

Ajoutez l’option -O à la commande scp, tel que : $ scp -O root@openwrt:/tmp/backup*.tar.gz $(pwd) (cela rétablit l’ancien comportement SFTP de scp)

Une autre astuce est d’installer le serveur OpenSSH en lieu et place de Dropbear .

Libération mémoire

Cette section est surtout utile si le système de fichier /tmp n’est pas assez grand pour enregistrer l’image d’OpenWRT. Les actions ci-dessous vont permettre de libérer temporairement de l’espace dans la RAM.

Par acquis de conscience, assurons-nous de l’espace mémoire et disque avec les commandes free et df, voire cat /proc/meminfo ; le but est de vérifier que la taille de RAM libre est plus importante que la taille de l’image téléchargée. Si c’est le cas, nous pouvons continuer le processus, sinon, nous avons un sérieux problème et il faut en discuter sur le forum d’OpenWRT.

Prenons un exemple pour mieux comprendre :

⇒ la taille du binaire d’upgrade de la version ci-dessus :

$ ll -h
(…)
-rw-rw-r-- 1 root root 6.7M Sep  10 13:53 openwrt-22.03.0-ramips-mt7621-xiaomi_redmi-router-ac2100-squashfs-sysupgrade.bin
(…)

elle est donc de 6.7 Mo.

⇒ L’espace disponible dans /tmp :

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.8M      3.8M         0 100% /rom
tmpfs                    59.7M    540.0K     59.1M   1% /tmp
/dev/ubi0_1              97.2M      7.8M     84.7M   8% /overlay
overlayfs:/overlay       97.2M      7.8M     84.7M   8% /
tmpfs                   512.0K         0    512.0K   0% /dev

Dans le contexte du Xiaomi Redmi AC2100, à ce jour, l’espace disponible est de 59.1 Mo, ce qui est largement suffisant pour récupèrer l’image de mise à niveau et la gérer.

⇒ De même, l’espace libérée de mémoire :

# free -m
              total        used        free      shared  buff/cache   available
Mem:         122220       40532       61400         540       20288       46700
Swap:             0           0           0

Dans ce contexte, l’espace libre en mémoire est de d’environ 60 Mo. Là, encore, il y a assez d’espace pour gérer l’image de mise à niveau.

Si ainsi, dans votre contexte, l’espace totale disponible, soit celle de la mémoire plus celle en /tmp n’est pas assez grande, il est possible d’essayer ce qui suit - supprimer ce qui devient désormais inutile :

les fichiers de listes des paquets : # rm -r /tmp/opkg-lists/
les caches suivants : # sync && echo 3 > /proc/sys/vm/drop_caches
Et si nécessaire, suppression des pilotes wifi suivants : # rm /etc/modules.d/*{80211,ath9k,b43}*
Pour finir, vérifiez qu’il n’y ait aucun lien symbolique dans le répertoire /etc/modules.d, si c’est le cas, détruisez-les, ce qui libérera de la RAM au prochain démarrage, puis redémarrez absolument OpenWRT avant de faire la mise à niveau.

À-propos de l’identification de l’hôte à distance par SSH

Lors de la nouvelle connexion par SSH, il est normalement possible que vous ayez le droit au message d’erreur suivant :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:0atP7BnQQ98EVJciOCBDYAUD245lKm2tbau8BgWMpQ0.
Please contact your system administrator.
Add correct host key in /home/you/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/you/.ssh/known_hosts:93
  remove with:
  ssh-keygen -f "/home/you/.ssh/known_hosts" -R "192.168.xyz.1"
ED25519 host key for 192.168.xyz.1 has changed and you have requested strict checking.
Host key verification failed.

Ne paniquez pas, c’est normal ! Ayant changé de version de système d’exploitation, l’identification de l’hôte a changé aussi. Appliquez la commande ssh-keygen, telle que donnée, dans votre cas, pour supprimer l’ancienne identification d’hôte. Puis retentez votre connexion.

Attention

Après la mise à niveau, il est très probable que les machines derrière le routeur n’aient plus accès correctement à Internet. C’est une phase normale ; ne pas paniquer !

En effet, ne pas oublier que sysupgrade supprime toute configuration utilisateur. L’étape suivante va d’être de restaurer le “profil utilisateur”.

À-propos de la Migration vers ≥ 21.02.0

Attention

Prérequis matériel minimum : À partir de la version 21.02.0, le minimum requis est de 8 Mo de flash, et 64 Mo de RAM.

Vous avez choisi de migrer vers la version 21.02.0-*** depuis 19.07.***, c’est bien !

Mais avant de faire toute autre action, connectez-vous à l’interface web, puis sur le menu “Interfaces” ; il va vous être proposé de faire une migration de la configuration, faites-la !

Puis, redémarrez !

Documentations

Comme vous pourrez le lire dans la documentation du wiki OpenWRT, il y a d’autres méthodes ; celle que je vous propose me semble la plus pertinente…