Si votre partition /boot est trop petite, linux peut manquer de place pour faire les mises à jour de kernel. Et si votre disque est chiffré, ça complique un peu les choses.
Quand il n’est pas possible de l’agrandir, il peut être plus simple de la déplacer (ce qui consiste techniquement à la recréer ailleurs).
Je décrivais dans un article précédent comment forcer un fsck au reboot d’un Olinuxino A20 (sous une version ancienne de Debian). J’ai eu récemment le même besoin sur un A64 sous Debian Buster, et il y a quelques adaptations à apporter
Suite à un article précédent, j’ai mis en place le PRA (plan de reprise d’activité) que j’envisageais pour mon auto-hébergement, avec Ansible. Même si ça a été un peu plus compliqué que prévu.
TLDR : Ca fonctionne pas mal, mais il y a plein de petits pièges. Et c’est bien plus simple sur /e/ que sur LineageOS (en tous cas sans les Google Apps).
J’ai un peu modernisé et fiabilisé mon auto-hébergement, en suivant quelques principes :
Reproductibilité : la configuration de l’OS, l’installation et la configuration des services qui tournent dessus doivent être automatisés
Sauvegardes automatiques : les données de chaque service doivent être sauvegardées automatiquement, périodiquement
Failover en mode actif/passif : chaque service doit être installé sur un serveur actif, et sur un ou plusieurs serveurs passifs. Les données sont synchronisées automatiquement sur les passifs, périodiquement
Indépendance de chaque serveur : chaque machine doit être la plus indépendante possible des autres
Suite à l’upgrade de Debian de Stretch vers Buster sur Olinuxino A20, on perd le support de l’algorithme de chiffrement aes-xts dans le kernel. Il a donc fallu re-chiffrer en aes-cbc les périphériques concernés.
J’ai renouvelé ma certification RHCE en passant la nouvelle version de l’examen RHCE (EX294). Elle change complètement de contenu en portant quasi uniquement sur Ansible. Mais j’ai (à nouveau) eu beaucoup de difficultés d’organisation avec RedHat.
Oui, en 2019 certains utilisaient encore Subversion, et il a fallu que j’adapte un peu les documentations de migration vers git pour qu’elles fonctionnent avec git 2. Et j’ai scripté le processus complet (y compris la configuration de gitlab)