La question des mises à jour de ChromeOS revient fréquemment chez les utilisateurs, souvent surpris de ne pas recevoir immédiatement la dernière version. Or un tel étonnement montre que les utilisateurs ne connaissent pas la politique mise en place par Google pour la diffusion des mises à jour. Celle-ci se base sur la sécurité et sur une volonté de proposer une version qui soit pleinement opérationnelle. Et non truffée de bugs. Je vous propose à travers cet article de comprendre la diffusion de la version stable de ChromeOS et vous allez voir que cela n’est pas un long fleuve tranquille.
Afin de vous apporter le maximum d’informations, vous trouverez tout au long de cet article, des renvois de bas de page. Cela doit vous permettre de bien comprendre tout le processus engagé par Google, pour la distribution des versions Stables de ChromeOS. Et vous allez voir que cela n’est pas de tout repos.
Qu’est-ce que le Rollout Progressif ou Staged Rollout ?
Dans cet article nous partons du principe que la version Dev, Beta de ChromeOS a été validée. Une validation qui peut s’effectuer en quelques semaines, ou quelques années. Nous sommes donc au moment où elle va être distribuée. A partir de là, les développeurs et tous les techniciens qui opèrent la diffusion sont dans la période de rollout progressif ou Staged Rollout.
Le rollout progressif consiste à diffuser la mise à jour par étapes, sur une période de plusieurs jours, voire plusieurs semaines. Le processus commence par la mise à disposition de la mise à jour à un faible pourcentage d’utilisateurs. Il est ensuite augmenté graduellement au fil du temps jusqu’à atteindre 100% du parc éligible. Bien que les seuils exacts pour ChromeOS ne soient pas publiquement détaillés, le processus pour le navigateur Chrome mentionne des paliers (ex: 10%, 50% ), suggérant une approche similaire par paliers successifs.
HP DeskJet 4120e Imprimante tout en un
- Le choix idéal pour la famille : Imprimez rapidement les documents du quotidien comme les devoirs, factures, billets etc
- Travaillez les mains libres et l’esprit tranquille : le chargeur automatique de 35 pages vous aide à terminer rapidement vos travaux de numérisation et de copie
- Imprimante éligible HP+ : Choisissez HP + lors de la configuration et profitez de 6 mois de forfait Instant Ink inclus. *Pour en bénéficier inscrivez-vous dans les 7 jours suivant l’installation de l’imprimante
- Eligible Instant Ink : Le forfait d’impression qui vous fait économiser sur l’encre; Vos cartouches HP livrées chez vous sans avoir à y penser, avant de tomber à court d’encre; En plus, Instant Ink est modulable et sans engagement
- Pour activer HP +, créez un compte HP, maintenez votre imprimante connectée à Internet et n’utilisez que de l’encre HP authentique pendant toute la durée de vie de l’imprimante
- Facilitez vous la vie avec HP Smart App : Impression mobile simplifiée, suivi de consommation d’encre, numérisation facile, accès privilégié à des jeux, des coloriages, des idées déco sur HP Print & Play
- + 1 an de garantie commerciale HP supplémentaire : Choisissez HP + lors de la configuration et profitez ainsi de 2 ans de garantie commerciale HP
Les raisons du rollout progressif
L’approche par étapes adoptée pour le déploiement des mises à jour de ChromeOS répond à plusieurs objectifs stratégiques essentiels. La raison principale est la minimisation des risques. En exposant initialement la nouvelle version à un nombre restreint d’utilisateurs, Google peut observer son comportement en conditions réelles, surveillant ainsi les performances, la stabilité et la compatibilité matérielle. Si des problèmes majeurs et imprévus surviennent, comme ce fut le cas avec Chrome OS 75 qui a nécessité une pause dans son déploiement, la distribution peut être interrompue ou ralentie avant d’affecter une large base d’utilisateurs. Cette méthode transforme le début du déploiement Stable en une phase active de gestion des risques et de validation finale à grande échelle.
Parallèlement, cette stratégie facilite la collecte de données et de feedback. Le groupe initial d’utilisateurs fournit des données télémétriques précieuses et des retours d’expérience qui aident à identifier des problèmes subtils ou spécifiques à certaines configurations, lesquels auraient pu échapper aux phases de test précédentes. De plus, la gestion de la charge serveur est optimisée ; répartir les téléchargements sur plusieurs jours évite de surcharger les serveurs de mise à jour, ce qui garantit une meilleure disponibilité et une vitesse de téléchargement accrue pour tous. Enfin, cette approche progressive offre la possibilité d’intégrer des correctifs rapides, appelés « hotfixes » ou « refreshes » pour le navigateur Chrome1. Si des problèmes mineurs mais significatifs sont détectés tôt, Google dispose du temps nécessaire pour préparer et intégrer ces correctifs avant que la majorité des utilisateurs ne reçoive la version initiale.
Les critères du rollout progressif
Plusieurs facteurs influencent l’ordre et le ciblage des appareils lors d’un déploiement progressif. Souvent, au sein de chaque palier de déploiement, les appareils sont choisis de manière aléatoire pour assurer une représentativité statistique. Le modèle d’appareil et la plateforme matérielle jouent également un rôle ; les annonces de déploiement indiquent fréquemment que la mise à jour concerne « la plupart des appareils ChromeOS », suggérant une possible variation.
La validation de la mise à jour pour des plateformes matérielles spécifiques (combinaisons de CPU, Wi-Fi, etc.) est une étape cruciale, et des modèles spécifiques peuvent être ciblés plus tôt ou plus tard en fonction de l’achèvement de ces tests ou d’une répartition délibérée, la complexité liée à la diversité matérielle étant un facteur clé de la variabilité potentielle du calendrier.
Un autre mécanisme probable, bien que explicitement documenté pour ChromeOS Flex, est le Filtrage Intelligent des Mises à Jour (Smart Update Filtering). Ce système permettrait au serveur de mise à jour de vérifier si un appareil demandant la mise à jour possède des composants matériels connus pour causer des problèmes critiques (comme des problèmes de démarrage ou graphiques sévères) avec la version cible. Si tel est le cas, le serveur peut proposer une version antérieure ou différer la mise à jour pour cet appareil jusqu’à résolution, permettant ainsi de poursuivre le déploiement pour la majorité tout en protégeant les appareils potentiellement affectés.
Finalement, dans les environnements gérés, les administrateurs utilisant la Google Admin Console disposent d’outils pour personnaliser le déploiement. Ils peuvent définir leurs propres calendriers progressifs, choisir des canaux spécifiques (Stable, Beta, LTS), ou « épingler » leurs appareils à une version spécifique de ChromeOS, reflétant le besoin des organisations d’un contrôle plus fin pour s’aligner sur leurs propres cycles de test et déploiement.
Mécanisme technique des MàJ de ChromeOS
La durée complète d’un déploiement Stable varie, les annonces officielles mentionnant généralement qu’il s’étalera sur « les prochains jours » ou « les jours/semaines à venir ». Des sources que j’ai consultées indiquent qu’un déploiement complet peut prendre une à deux semaines pour atteindre tous les utilisateurs, une variabilité confirmée par les expériences utilisateurs rapportées, allant d’une disponibilité quasi immédiate à plusieurs jours d’attente.
Concernant les mécanismes techniques, le processus de mise à jour de ChromeOS s’appuie sur des systèmes sophistiqués visant la fiabilité, la sécurité et la transparence. Les composants clés sont le daemon update_engine2 et le système de partitions A/B.
Le service daemon update_engine est le moteur principal orchestrant la mise à jour sur chaque appareil. Ce processus d’arrière-plan fonctionne avec une faible priorité système pour minimiser l’impact sur les performances perçues. Ses responsabilités incluent des vérifications périodiques auprès du serveur de mise à jour de Google (« Omaha ») pour détecter les nouvelles versions. Avant de contacter le serveur, il consulte les politiques de mise à jour locales (souvent gérées via la Google Admin Console), qui peuvent dicter les horaires de vérification ou la version/canal à cibler.
Un contenu de qualité, sans publicité.
Vous aimez notre travail ? Soutenez notre indépendance en devenant membre sur Patreon.
Soutenir MyChromebook.frLa communication avec le serveur Omaha3 se fait via HTTPS, envoyant des informations d’identification de l’appareil pour recevoir en retour l’URL de la charge utile (payload) de mise à jour appropriée, sa taille, ses hashs de vérification et ses signatures. update_engine gère ensuite le téléchargement et l’application de cette payload sur la partition système inactive. Ce daemon est conçu pour être résilient : il peut redémarrer automatiquement en cas de crash, reprendre un téléchargement ou une application interrompue grâce à des points de contrôle, réessayer les communications réseau échouées et basculer d’une mise à jour delta à une complète si nécessaire.
Une architecture de partitionnement
ChromeOS utilise une architecture de partitionnement A/B, souvent appelée « Seamless Update » (mise à jour transparente), fondamentale pour sa fiabilité. Au lieu d’une seule copie des partitions système critiques, ChromeOS en maintient deux jeux quasi identiques, « Slot A » et « Slot B ». L’appareil fonctionne à partir du slot désigné comme « actif ». Lorsqu’une mise à jour est disponible, update_engine l’applique sur les partitions du slot « inactif » pendant que l’utilisateur continue d’utiliser l’appareil normalement. Après installation et vérification sur le slot inactif, l’utilisateur est invité à redémarrer. Au redémarrage, le bootloader bascule simplement sur le slot mis à jour, le marquant comme nouveau slot actif.
L’ancien slot actif devient inactif, conservant la version précédente comme sauvegarde. Cette architecture offre des avantages significatifs. Le temps d’arrêt pour l’utilisateur est minimal, réduit à la durée d’un redémarrage normal, car l’installation se fait en arrière-plan. La fiabilité est accrue grâce à la capacité de « rollback » : si la mise à jour échoue ou si le nouveau système ne démarre pas correctement, le système peut automatiquement revenir au slot précédent fonctionnel, évitant de bloquer l’utilisateur. De plus, ce système élimine le besoin d’un grand espace cache temporaire, car les mises à jour peuvent être appliquées au fur et à mesure de leur téléchargement sur le slot inactif, l’espace nécessaire étant intrinsèquement fourni par la duplication des partitions.
Vous le saviez que @Google propose des mises à jours séquentielles de ChromeOS ?
Types de charges utiles (Playloads) et vérification
Les mises à jour sont distribuées sous forme de « payloads4« , dont il existe deux types principaux. Les payloads Delta contiennent uniquement les différences binaires entre la version actuelle et la version cible ; étant beaucoup plus petits, ils sont préférés pour économiser la bande passante et le temps. update_engine essaiera d’obtenir un delta en premier. Les payloads Complets contiennent l’intégralité de l’image système cible et sont utilisés si un delta n’est pas disponible ou si son application échoue. La vérification de l’intégrité et de l’authenticité de la payload est une étape critique multi-niveaux. Elle commence par la vérification des signatures cryptographiques des métadonnées de la mise à jour.
Pendant le téléchargement, update_engine calcule les hashs des blocs de données5 et les compare aux hashs attendus. Une fois le téléchargement terminé, une signature globale de la payload est vérifiée. Après l’écriture sur le slot inactif, une vérification post-installation est effectuée en relisant la partition modifiée et en comparant son hash à une valeur attendue. À chaque démarrage, la Vérification au Démarrage (Verified Boot) du firmware contrôle l’intégrité du système d’exploitation, tentant une auto-réparation si nécessaire. Enfin, après le redémarrage sur le nouveau slot, une vérification post-redémarrage utilise dm-verity pour confirmer à nouveau l’intégrité avant de marquer définitivement le nouveau slot comme réussi. Cette chaîne de vérifications garantit l’authenticité et l’intégrité de la mise à jour.
Des MàJ automatique
Par défaut, ChromeOS est conçu pour se maintenir à jour automatiquement. update_engine effectue des vérifications périodiques en arrière-plan. Si une mise à jour est disponible et autorisée par les politiques mises en place, le téléchargement démarre automatiquement. Une fois l’application sur le slot inactif terminée, une notification invite l’utilisateur à redémarrer.
Bien que le processus soit automatique, les utilisateurs peuvent aussi initier manuellement une vérification en allant dans Paramètres > À propos de ChromeOS > Vérifier les mises à jour. Si une mise à jour est trouvée ainsi, le téléchargement démarre immédiatement. Il est à noter que le bouton peut être temporairement indisponible si une vérification automatique a eu lieu récemment, et dans les environnements gérés, les administrateurs peuvent désactiver cette option manuelle.
ChromeBook Plus Asus CX5601FBA-MC0129
Comprendre la diffusion de la version stable de ChromeOS
Le déploiement des mises à jour de ChromeOS, bien que semblant simple en surface, est un processus complexe et méticuleusement orchestré. Derrière l’apparente simplicité des mises à jour automatiques se cachent des mécanismes sophistiqués tels que le daemon `update_engine`, les partitions A/B pour une mise à jour transparente, et des vérifications d’intégrité à chaque étape pour garantir une expérience utilisateur stable et sécurisée.
Le déploiement progressif, loin d’être un simple retard, est une stratégie essentielle pour minimiser les risques, recueillir des données cruciales et assurer une distribution fluide et maîtrisée à travers une diversité de configurations matérielles.Comprendre ce processus permet de relativiser l’attente lors du déploiement d’une nouvelle version et de reconnaître l’importance de ces étapes pour la fiabilité globale du système.
Maintenant, c’est à vous de parler ! Avez-vous déjà rencontré des problèmes lors de mises à jour de ChromeOS ? Combien de temps avez-vous dû attendre pour recevoir une version spécifique ? N’hésitez pas à partager votre expérience et vos réflexions dans les commentaires ci-dessous. Votre feedback est précieux pour enrichir notre compréhension collective de ce processus essentiel.
Notes de bas de page
- Lors du déploiement de mises à jour, les « correctifs rapides, » aussi appelés « hotfixes » ou « refreshes » pour le navigateur Chrome, sont des mises à jour mineures et ciblées qui sont déployées rapidement pour résoudre des problèmes spécifiques ou des vulnérabilités de sécurité qui ont été découvertes après la publication d’une version principale.
Voici une explication plus détaillée :
– Que sont les « hotfixes » ou « refreshes » ?Correctifs ciblés : Contrairement aux mises à jour majeures qui introduisent de nouvelles fonctionnalités, les hotfixes sont généralement conçus pour corriger des bugs, résoudre des problèmes de stabilité ou de performance, ou colmater des failles de sécurité.
– Déploiement rapide : Ils sont déployés rapidement, souvent entre les versions majeures, pour minimiser l’impact des problèmes sur les utilisateurs.
– Spécifiques au problème : Ils s’attaquent à des problèmes spécifiques qui ont été identifiés et nécessitent une attention immédiate.
Pourquoi sont-ils nécessaires ? Pourvoir réponde à des problèmes imprévus : Même après des tests approfondis, des problèmes peuvent survenir une fois qu’une version est déployée à grande échelle. Les hotfixes permettent de réagir rapidement à ces problèmes.
– Sécurité : Des vulnérabilités de sécurité peuvent être découvertes après la publication d’une version. Les hotfixes permettent de corriger ces vulnérabilités rapidement pour protéger les utilisateurs.
– Amélioration continue : Ils permettent d’apporter des améliorations ou des corrections mineures sans avoir à attendre la prochaine version majeure.
Dans le contexte du navigateur Chrome apporter des mises à jour discrètes : Les hotfixes pour Chrome sont souvent déployés de manière discrète, en arrière-plan, et les utilisateurs peuvent ne même pas se rendre compte qu’une mise à jour a été appliquée.
– Importance pour la sécurité : Étant donné que Chrome est un navigateur web, il est essentiel de corriger rapidement les vulnérabilités de sécurité pour protéger les utilisateurs contre les attaques potentielles.
En résumé, les « hotfixes » ou « refreshes » sont des correctifs rapides et ciblés qui permettent aux développeurs de Chrome de résoudre rapidement des problèmes et des vulnérabilités de sécurité, assurant ainsi une expérience de navigation plus stable et sécurisée pour les utilisateurs. ↩︎ - Le « daemon update_engine » est le service principal responsable de l’orchestration du processus de mise à jour sur chaque appareil. Voici ses fonctions principales :
– Vérifications périodiques : Il effectue des vérifications régulières auprès du serveur de mise à jour de Google (« Omaha ») pour détecter la disponibilité de nouvelles versions de ChromeOS.
Gestion des politiques de mise à jour : Il consulte les politiques de mise à jour locales, qui peuvent être configurées par les administrateurs (notamment dans les environnements gérés), pour déterminer les horaires de vérification et les versions ou canaux à cibler.
– Communication avec le serveur Omaha : Il communique via HTTPS avec le serveur de mise à jour pour obtenir les informations nécessaires sur les nouvelles versions, telles que l’URL de la charge utile de mise à jour, sa taille, ses hachages de vérification et ses signatures.
– Téléchargement et application des mises à jour : Il gère le téléchargement de la charge utile de mise à jour et l’applique sur la partition système inactive.
– Résilience et fiabilité : Il est conçu pour être résilient, avec des capacités de redémarrage automatique en cas de crash, de reprise des téléchargements ou applications interrompues, de nouvelles tentatives de communication réseau et de basculement entre les mises à jour delta et complètes.
En résumé, le daemon update_engine est le moteur qui gère et automatise tout le processus de mise à jour de ChromeOS sur un appareil, de la vérification de la disponibilité des mises à jour à leur téléchargement et installation. ↩︎ - « Omaha » est le nom de code interne utilisé par Google pour désigner son système de serveur de mise à jour. C’est ce serveur que le composant update_engine sur votre Chromebook contacte périodiquement via HTTPS pour vérifier si de nouvelles versions de ChromeOS sont disponibles et pour recevoir les informations nécessaires (comme l’URL de la mise à jour, sa taille et ses informations de vérification) afin de la télécharger. ↩︎
- Dans le contexte des mises à jour de ChromeOS, on appelle « payloads » les fichiers contenant les données nécessaires pour mettre à jour le système d’exploitation. Plus précisément :
– Payloads de mise à jour : Ce sont les paquets de données qui sont téléchargés et appliqués pour mettre à niveau ChromeOS vers une version plus récente.
Il existe deux types principaux de payloads :
– Payloads Delta : Ils contiennent uniquement les différences binaires entre la version actuelle et la version cible du système d’exploitation. Ces payloads sont beaucoup plus petits, ce qui permet d’économiser de la bande passante et du temps de téléchargement.
– Payloads Complets : Ils contiennent l’intégralité de l’image du système d’exploitation cible. Ils sont utilisés lorsque un payload delta n’est pas disponible ou si l’application du delta échoue.
En résumé, les « payloads » sont les fichiers qui transportent les modifications nécessaires pour mettre à jour ChromeOS, et ils peuvent être soit des mises à jour partielles (delta) soit des images complètes du système. ↩︎ - Dans le contexte des mises à jour de ChromeOS, les « hashs des blocs de données » font référence à des empreintes numériques uniques générées à partir des blocs de données qui composent la charge utile (payload) de la mise à jour. Voici une explication plus détaillée :
Qu’est-ce qu’un hash ?
Un hash est le résultat d’une fonction mathématique (appelée fonction de hachage) qui prend une entrée de données (dans ce cas, un bloc de données) et produit une chaîne de caractères de longueur fixe. Cette chaîne de caractères est l’empreinte numérique ou le « hash » de ces données.
Les fonctions de hachage utilisées pour la vérification de l’intégrité des données ont des propriétés importantes :
– Déterministes : La même entrée produira toujours le même hash.
– Unidirectionnelles : Il est pratiquement impossible de reconstruire les données originales à partir du hash seul.
– Résistantes aux collisions : Il est extrêmement improbable que deux ensembles de données différents produisent le même hash.
Pourquoi utiliser des hashs pour les mises à jour ?
Dans le processus de mise à jour de ChromeOS, les hashs des blocs de données servent à garantir l’intégrité des fichiers téléchargés :
– Génération des hashs : Avant de distribuer la mise à jour, Google calcule les hashs de chaque bloc de données qui compose le payload de la mise à jour. Ces hashs sont inclus dans les métadonnées de la mise à jour.
– Téléchargement et calcul des hashs : Lorsque votre Chromebook télécharge les blocs de données, il calcule également les hashs de ces blocs au fur et à mesure du téléchargement.
– Comparaison des hashs : Après avoir téléchargé un bloc de données, votre Chromebook compare le hash qu’il a calculé avec le hash fourni par Google dans les métadonnées.
– Vérification de l’intégrité : Si les hashs correspondent, cela signifie que le bloc de données n’a pas été altéré pendant le téléchargement. S’ils ne correspondent pas, cela indique qu’il y a eu une erreur ou une modification non autorisée, et le bloc doit être retéléchargé.
Les hashs des blocs de données sont une technique essentielle pour s’assurer que les fichiers de mise à jour de ChromeOS n’ont pas été corrompus ou modifiés lors de leur transfert. Ils permettent de détecter toute altération accidentelle (due à des erreurs de réseau par exemple) ou malveillante (tentatives de manipulation). C’est un élément important du processus de vérification de l’intégrité et de l’authenticité des mises à jour. ↩︎
