Cela fait plus d'un an que les développeurs de balenaEtcher retravaillent le code de l'outil de transfert d'image en profondeur : mise à jour des composants, réécriture, améliorations de l'interface, etc. Alors que la 1.5.103 est disponible, faisons le point sur le projet.
Il existe une multitude d'outils de transfert d'images système et autres ISO sur un périphérique de stockage. Rares sont les solutions pratiques, complètes et multiplateformes. Ces dernières années, il y en a un qui s'est démarqué en la matière : balenaEtcher. Ce, bien qu'il soit basé sur Electron et donc assez « lourd » (115 Mo environ).
Ainsi, certains lui préfèrent dd ou Rufus, ce dernier étant particulièrement adapté aux ISO Windows. Mais lorsque vous devez traiter différents types d'images de manière régulière, avoir balenaEtcher sous la main se révèle bien souvent obligatoire. La fondation Raspberry Pi l'a même utilisé comme base de son Imager.
Ce succès ne l'empêche de continuer à évoluer régulièrement. Open source, son code est diffusé sous licence Apache 2.0 via Git Hub. Il vient d'être mis à jour en version 1.5.103, qui introduit notamment l'utilisation de sudo-prompt pour l'élévation de privilège sous Windows (c'était déjà le cas sous Linux/macOS).
Un logiciel qui envoie du lourd (surtout sous Windows)
La branche 1.5.x n'est pas nouvelle, ayant été mise en ligne en février 2019. Il s'agissait alors d'utiliser Electron v3, de retirer l'interface en ligne de commandes (CLI) et de revoir la méthode de transfert des images. La taille de l'outil était alors déjà assez conséquente, mais limitée à un peu moins de 80 Mo dans le pire des cas.
En 18 mois, qu'est-ce qui a changé ? Au début pas grand-chose. Au fil des versions de 2019 on note des corrections de bugs, mises à jour de modules et autres retouches. C'est avec la 1.5.40 qu'intervient un changement... de poids. Si certains paquets Linux étaient allégés (moins de 60 Mo), ceux sous Windows grimpaient à 120/140 Mo.
Pourquoi ? Parce que les éditions 32/64 bits de l'outils ont été fusionnées.
Support des URL et des images VHD
Les mois suivants, le travail de mise à jour et de réécriture d'une partie du code a continué. Il faudra attendre avril 2020 et la version 1.5.82 pour voir une première grande nouveauté : la possibilité d'utiliser une URL pour fournir l'image. Il n'est ainsi plus nécessaire de la télécharger au préalable. Un historique est proposé :
Une fonctionnalité sans doute rendue nécessaire par le mode de fonctionnement de l'Imager de la fondation Raspberry Pi, qui l'a proposé nativement dès sa mise en ligne début mars. La refonte a ensuite continué, avec un travail d'allègement via de petits éléments (5 Mo récupérés sur la version portable entre la 1.5.82 et la 1.5.103).
En juin, l'interface a été modifiée ici ou là (barre de progression, vitesse de transfert, police, etc.). Puis la version 1.5.100 a introduit le support des disques virtuels (VHD), utilisé par certains hyperviseurs.
Périphériques de stockage : un sélecteur plus flexible
Cette mouture introduisait un autre changement : par défaut les disques durs et autres SSD internes à la machine sont accessibles, mais « cachés ». Pour les voir, il faut cliquer sur une flèche. Une situation préférable à l'activation d'un mode « unsafe » avec une alerte comme c'était le cas dans de précédentes version.
Au passage, d'autres informations sont ajoutées : le type de périphérique (système, de grande taille, etc.). Une exception toutefois, celui où la partition principale de l'OS est installée, bien entendu.
Commentaires (12)
#1
C’est cool de voir qu’ils font évoluer leurs fonctionnalités, mais ils feraient bien de déjà régler les bugs existants, le nombre de fois que balenaEtcher a mal écrit une image ISO sur une clé USB et que j’ai passer par Rufus pour la réécrire…
#1.1
Avec quelles images ? Parce que j’utilise fréquemment et j’ai pas trop de souci (sauf pour W10 où je passe plutôt par rufus effectivement). Pour le reste, 103 mises à jour en un an et demi, dont pas mal pour corriger des bugs, mettre à jour des composants, retoucher, ça me parait déjà pas mal non ? ;)
#1.2
Comme les devs ne sont pas voyants sur leurs heures perdues, il ne faut pas hésiter à remonter les fameux bugs, sinon ils ne vont pas se corriger par magie.
#2
Question un peu bête parce que j’ai toujours pas testé cette feature : quand on flashe par URL, ça se fait en deux fois (dl puis flash) ou les octets sont écrits sur le support au fur et à mesure qu’ils sont téléchargés ?
Souvent il m’arrive de flasher une clé/carte depuis une image dont je n’aurai besoin qu’une fois et il est vrai que dans ces cas l’écriture intermédiaire « sur disque » n’est rien d’autre qu’une perte de temps.
#2.1
Disons que ça va dépendre de la fréquence de la mise à jour de l’ISO et de sa taile. Parce que si c’est une image de 4 Go qui sera mise à jour dans 6 mois et que tu la flashes régulièrement… mais c’est parfait pour une “last daily” par exemple.
Pour l’écriture ça se fait en même temps que le téléchargement.
#3
Ce qui veut dire qu’il n’est pas possible de faire une vérification du téléchargement via un hash, directement dans l’application.
Ca aurait été bien de pouvoir mettre le lien et le hash de vérification.
#3.1
https://github.com/balena-io/etcher/issues
#4
Membre d’une assoc’ de bidouille informatique qui fait beaucoup de clés bootables, on passait pas mal par Etcher. Sous Debian Gnome on lui préfère maintenant gnome-disk qui est hyper simple, fonctionnel et plus convivial que DD…
#5
Quelles sont les applications pratiques par rapport à la gestion du VHD ?
#5.1
Sans doute de migrer une image vers une machine réelle. Pas mal d’outils tiers le proposent déjà, de mémoire le VHD est aussi utilisé comme image hors des cas de machine virtuelles (mais à vérifier). Après tout ça reste une image système, la question c’est : pourquoi pas ?
#5.2
Merci pour ces précisions, à voir comment ça passe du VM > machine réelle.
#5.3
Je ne pense pas que ça pose le moindre souci, surtout avec Windows 10 qui est assez transparent là dessus.