J'attends toujours d'avoir mon programmateur de flash, pour faire un backup complet de ma flash. Une fois fait, je vais pouvoir update la partition squashfs pour virer ce process deamon qui me kill mon ONU a chaque fois que mon fichier mibs est pas bon.

Le processus deamon surveille le démon OMCI Nokia, qui ne se sert pas des fichiers mibs.
Le backup de la flash peut être fait depuis Linux, c'est sa restauration qui peut nécessiter un programmateur si Linux ne démarre plus (ou si ça bloque avant la configuration du réseau et du démon SSH).

Il faut backup mtd2 (et donc kernel + squashfs), extraire le squashfs, modifier les fichiers, refaire le squashfs et le remettre à la bonne position dans le backup de mtd2 pour le flasher en SSH, ça fonctionne très bien (attention à ne pas trop augmenter la taille par contre)

Tu peux aussi backup tous les mtdX pour les remettre dans ton futur backup complet et avoir l'image d'origine (c'est ce que j'ai fait pour le backup que j'ai publié ici)

Oui, mais quand tu restart le deamon OMCI, il trigger ...

On peut le tuer et le relancer avec un fichier de configuration réduit (sinon le watchdog du kernel fait un reboot quand il expire).
Ce que je ne sais pas en revanche, c'est si en arrêtant les démons Nokia, on se retrouve dans un état qui permet au démon Lantiq de fonctionner correctement, ou s'il faut absolument qu'il soit le seul lancé, directement au boot.

Je suis attentif à vous lire tous, et je saupoudre ce topic de toute ma bienveillance.

Il faudrait parvenir à une modification de la partition squashfs, avec un système à valeur ajoutée, adaptable à différents OLT.

Sans doute y-a-t-il moyen de s'inspirer de l'ONU de  Carlito.

Je suis attentif à vous lire tous, et je saupoudre ce topic de toute ma bienveillance.

Il faudrait parvenir à une modification de la partition squashfs, avec un système à valeur ajoutée, adaptable à différents OLT.

Sans doute y-a-t-il moyen de s'inspirer de l'ONU de  Carlito.

Hum, en effet Carlito a surement du etre confronté a ce genre de pb. Si quelqu'un a un dump de son ONU v1, je suis preneur.

hwti, j'aime bien ton idée de flasher la 2eme image pour booter dessus. Dans la table de partition, il semble y avoir qu'une image

Code: [Sélectionner]

dev:    size   erasesize  name
mtd0: 00040000 00010000 "uboot"
mtd1: 00080000 00010000 "uboot_env"
mtd2: 00600000 00010000 "image0"
mtd3: 00600000 00010000 "linux"
mtd4: 004d8237 00010000 "rootfs"
mtd5: 00050000 00010000 "rootfs_data"
mtd6: 00100000 00010000 "configfs"
mtd7: 00210000 00010000 "logfs"
mtd8: 00010000 00010000 "ri"
mtd9: 00010000 00010000 "sfp"
mtd10: 00010000 00010000 "ribackup"

Est-ce que l'image1 est cachée sous un autre nom ?

En ayant extrait les images, jai des squashfs dans les partitions 2,3 et 4.
2 : c'est image, ok.
3: linux ? Est-ce que c'est l'image1 ?
4: rootfs, c'est surement l'image0 qui est montéepour booter live ?

Quentin.

Regarde https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/msg817189/#msg817189
Dans ton cas, l'image courante est image1.
Donc :
 - mtd2 "image0" est l'image inactive
 - mtd3 "linux" est l'image active (le nom est toujours le même, ce serait mtd2 si l'image0 était active)
 - "rootfs" et "rootfs_data" ne sont pas de vraies mtd (on le voit bien avec la taille de mtd4 qui n'est pas multiple de la taille de bloc), ce sont des sous-parties de "linux" (pour pouvoir les monter, car on peut monter /dev/mtd4, mais pas /dev/mtd3+offset)

/proc/mtd n'indique que les tailles, mais en regardant dans /sys, il me semble qu'on peut voir les offsets, et confirmer qu'ici mtd4 et mtd5 sont dans mtd3.