Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.
[^] # Re: À la découverte de Silverblue
Posté par Misc (site web personnel) . En réponse à la dépêche Fedora Linux 40 Beta est disponible pour les tests. Évalué à 7.
Même sans parler des mises à jours de version, je peux donner des exemples (et même des exemples qui n'impliquent pas de dire qu'une femme plus âgée est moins compétente que la moyenne).
Par exemple, à l'époque ou je faisait le support sur le terrain pour des commerciaux, j'avais régulièrement des gens qui venaient avec un laptop sous RHEL incapable de booter. J'ai fini par diagnostiquer ça comme étant le symptôme d'un reboot pendant les mises à jours.
J'ai constaté que mes collègues du département Vente avait la bonne habitude de lancer les mises à jour en tache de fond, puis d'oublier l’existence des dites mises à jour en cours et soit de tomber soit en panne de courant, soit d'éteindre le PC. Avec assez de monde et assez de mises à jours, ça finit par arriver.
Normalement, RPM est assez solide pour survivre à ça dans le sens ou sur une RHEL, ça devrait pas rendre la machine indémarrable. Il faut parfois repasser en root et faire du nettoyage pour finir la transaction, etc, donc passer du temps, mais c'est pas bloquant.
Par contre, il y a un rpm qui a un souci avec ça, c'est le kernel, car le kernel sur RHEL, il a 2 scripts de post installation. Un script en %post et un en %posttrans. Quand tu installes le rpm, il lance le script en %post, qui va modifier la config grub, et rajouter le nouveau kernel et initrd. Quand tu as fini d'installer tout les autres paquets, le script %posttrans (pour post transaction, la transaction étant l'installation de tout les paquets comme dans un SGBD) va lancer la création de l'initrd. C'est fait après l'installation pour être sur d'avoir tout les fichiers à jour après la mise à jour. Par exemple, si il y a une mise à jour de bash et du kernel, tu veux avoir le dernier bash dans l'initrd, pour éviter les bugs ou les soucis de sécu corrigé par une mise à jour de bash.
Sauf que, si tu coupes la mise à jour en cours, tu te retrouves avec la config de grub modifié, mais pas l'initrd correspondant, et donc au reboot, le choix de kernel de grub est non fonctionnel vu qu'il pointe vers un initrd qui n'est pas encore sur le disque, donc ça coince.
Alors il y a plusieurs correctifs possibles. Mettre l'ajout du kernel dans la config grub dans le scipt %posttrans après la création de l'initrd. Faire en sorte que grub soit moins con et vérifie la présence des fichiers et bascule sur un choix par défaut. Faire l'initrd 2 fois, dans le %post et le %posttrans. Ou utiliser ostree.
Car en effet, tout le probléme disparaît avec ce genre de systèmes. Les mises à jours sont téléchargés en entier avant d'être appliquées d'un coup au reboot. Si tu coupes le téléchargement, rien de dramatique se passe et ça peut reprendre plus tard. Si ça ne démarres pas, tu peux automatiquement revenir en arrière (en théorie).
Et ça, c'est sur une RHEL, ou les questions de mises à jours majeurs de rpms ne se posent pas trop, en tout cas pas sur la durée d'usage des portables comparée à la durée de vie de la distro.