Je l'ai déjà écrit : nous utilisons Puppet pour configurer des stations de travail. Sur ces machines-là, le CRON qui lance Puppet (pourquoi ?) au démarrage (mot-clé @reboot dans CRON) effectue aussi un dpkg --configure -a afin de réparer les installations cassées (utilisateur qui éteint brutalement la machine en pleine installation / mise à jour…). On a donc dpkg --configure -a && puppet agent --enable && puppet agent -t ; apt -y update && apt -y upgrade. À plusieurs reprises, je constate que puppet n'est pas exécuté et que les mises à jour ne sont pas effectuées.

Pour debug, j'ai fait dans l'habituel : un echo, une commande, un echo, une commande, etc. On ne va pas plus loin que dpkg --configure -a. Rediriger la sortie standard et la sortie d'erreur dans un fichier (1>/tmp/testcron 2>&1) n'apporte pas d'information (si ça avait été le cas, j'aurai reçu un email, car CRON envoie la sortie standard et les erreurs par email). echo $? >/tmp/testcron est plus intéressant : dpkg termine avec le code d'erreur 2. D'après son manuel, il s'agit d'une erreur fatale ou irrécupérable. Rien que ça.

Pour la suite, ça a été un coup de chance. Dans CRON, le PATH n'est pas celui de root, mais « /usr/bin:/bin ». Or, dpkg a besoin de « /usr/sbin:/sbin ». Je ne vois pas trop quels binaires il exécute dedans, mais soit. Ajouter export PATH=$PATH:/sbin:/usr/sbin dans mon script résout mon problème.

Pour les plus attentifs : pourquoi je ne chaîne pas « apt -y upgrade » à « puppet agent -t » avec && ? Lorsqu'il effectue des actions, puppet agent ne termine pas avec le code d'erreur 0 mais 2 (cf son manuel), donc le chaînage en cas de succès (&&) est caduque.

ArubaOS (utilisé dans le produit Aruba Mobility Master v8.6) refuse de démarrer / booter dans une machine virtuelle KVM sur un hyperviseur Proxmox 6 car il manque les instructions CPU SSSE3.

On se dit qu'on va faire un qm set, mais, d'après la doc', les drapeaux activables sont limités, et il n'y a pas SSSE3.

Il y a qu'à choisir un modèle de CPU virtuel qui prend en charge SSSE3. Par défaut, le type de CPU émulé par Proxmox+KVM est kvm64, qui est un Pentium 4 avec des jeux d'instructions retirés.

Dans les propriétés de la VM, onglet « Hardware », « Processors », on peut choisir le modèle de CPU dans la liste déroulante « Type ». SSSE3 étant ancien (2004), n'importe quel modèle de CPU devrait faire l'affaire. Nous avons choisi IvyBridge, fin du problème.