Une mise à jour du noyau SLES peut toujours afficher « Redémarrage requis » même après l'activation du Live Patching. Cela ne signifie pas automatiquement que l'installation a échoué : les correctifs en direct ne couvrent que les corrections que SUSE peut fournir en toute sécurité pour le noyau en cours d'exécution, tandis qu'un noyau de remplacement ou des corrections ne pouvant être appliquées en direct nécessitent toujours un redémarrage. Le guide SUSE sur le Live Patching du noyau SLES 16.0, publié le 8 octobre 2026, propose une nouvelle méthode d'installation : installer le kernel_livepatchingmodèle dans le cadre de l'abonnement SLES standard. SLES 15 SP7 utilise une extension Live Patching distincte et le lp_slesmodèle.
Suivez la procédure correspondant à votre version, appliquez les mises à jour via le flux de travail standard des paquets SUSE et vérifiez le correctif actif klp -v patches. Ces étapes supposent un système SLES enregistré ayant accès à ses dépôts de mises à jour compatibles.
Identifiez la version et le noyau en cours d'exécution. Exécutez :
cat /etc/os-release
uname -r
uname -m
Notez la version de SLES, la version du noyau et l'architecture. Les correctifs en direct correspondent à une révision spécifique du noyau ; par conséquent, un correctif pour un noyau différent ne prouve pas que le noyau actif est à jour. Les commandes ci-dessous utilisent les instructions actuelles de SLES 16.0 et SLES 15 SP7 ; ne copiez pas un modèle ou un chemin d'activation spécifique à une version vers une autre.
Sur SLES 16.0, installez le modèle fourni. Le guide SUSE actuel indique que le correctif en direct du noyau est inclus dans l'abonnement SLES standard. Installez son modèle :
sudo zypper install -t pattern kernel_livepatching
Si vos dépôts contiennent un correctif en direct compatible avec le noyau installé, le gestionnaire de paquets le sélectionne lors de l'installation ; SUSE indique que le noyau est corrigé en direct dans le cadre de ce processus. Cette procédure SLES 16.0 ne nécessite aucun code d'enregistrement supplémentaire pour le correctif en direct.
Sur SLES 15 SP7, activez d'abord l'extension. Cette version nécessite des abonnements SLES et SLES Live Patching actifs. Consultez la liste des extensions disponibles et utilisez la commande d'activation spécifique à l'architecture affichée :
sudo SUSEConnect --list-extensions
sudo SUSEConnect -p sle-module-live-patching/15.7/x86_64 -r LIVE_PATCHING_REGISTRATION_CODE
La deuxième commande est un exemple x86_64. Remplacez-la par le chemin d'accès exact du produit affiché dans votre --list-extensionssortie et fournissez le code d'enregistrement Live Patching valide. Installez ensuite le modèle requis :
sudo zypper install -t pattern lp_sles
L'activation seule n'installe pas les modèles ni les paquets ; effectuez les deux étapes avant de vous attendre à recevoir des correctifs en direct via les canaux de mise à jour.
Appliquez régulièrement les mises à jour système. Les correctifs du noyau sont distribués sous forme de paquets via le mécanisme de mise à jour standard. Pour une application manuelle de correctif, utilisez la même procédure de maintenance approuvée que pour le reste du système hôte, par exemple :
sudo zypper refresh
sudo zypper patch
Examinez attentivement le plan de déploiement avant de le confirmer, notamment sur les systèmes de production. Un correctif en direct peut appliquer les correctifs éligibles au noyau en cours d'exécution sans redémarrer les charges de travail, mais cette même opération de mise à jour peut également proposer un nouveau paquet de noyau de base. L'installation de ce paquet peut toujours nécessiter un redémarrage. Les correctifs en direct sont cumulatifs pour leur révision de noyau cible ; ils ne remplacent pas la maintenance régulière du noyau.
Vérifiez si un correctif est en cours d'application. Une fois la mise à jour terminée, consultez les détails du correctif :
sudo klp -v patches
SUSE documente cette commande pour vérifier l'état des correctifs et consulter les CVE ou les failles corrigées par le correctif actif. Assurez-vous que le correctif affiché correspond au noyau en cours d'exécution indiqué à l'étape 1. Un paquet de correctif initial ou de base peut ne contenir aucun correctif ; il prépare la révision du noyau pour les correctifs futurs. Sa présence seule ne signifie pas qu'un correctif de sécurité spécifique a été appliqué.
Résolvez les problèmes liés à un statut vide ou incohérent. Vérifiez si un paquet de correctifs en direct existe pour le noyau en cours d'exécution et si les données de cycle de vie sont disponibles :
sudo zypper se --details 'kernel-livepatch-*'
sudo zypper lifecycle
Concernant les dates de cycle de vie, SUSE indique que le lifecycle-data-sle-module-live-patchingpaquet doit être installé. Si aucun correctif n'est disponible pour le noyau en cours d'exécution, vérifiez que les dépôts ou canaux de mise à jour en direct appropriés sont activés et que le correctif concerné est éligible à la mise à jour en direct. Ne concluez pas à un échec si la liste des correctifs est vide et qu'aucune mise à jour compatible n'a été publiée.
Planifiez le redémarrage nécessaire à une mise à jour complète du noyau. SUSE ne peut pas convertir tous les correctifs en patch actif ; certaines modifications nécessitent le remplacement de structures de données du noyau ou ne peuvent être appliquées en toute sécurité lors de l'exécution. Intégrez les mises à jour régulières du noyau à votre plan de maintenance et redémarrez lorsque la mise à jour l'exige. Évitez de masquer les notifications de redémarrage en verrouillant indéfiniment les paquets du noyau : cela retarde l'application des correctifs complets au lieu de les appliquer en direct.
Pour une maintenance sans redémarrage, procédez uniquement si la mise à jour contient un correctif compatible avec le noyau en cours d'exécution et si votre politique de gestion des modifications l'autorise. Considérez une mise à jour complète du noyau comme étant en attente jusqu'à ce que le système hôte ait démarré avec le nouveau noyau.
La vérification est réussie lorsque klp -v patchesles informations de correctif actif pour le noyau sont identifiées uname -ret que le correctif attendu apparaît dans les détails du correctif. L'hôte devrait conserver la même version du noyau en cours d'exécution, car aucun redémarrage n'a eu lieu. Si le gestionnaire de mises à jour demande tout de même un redémarrage, vérifiez s'il a installé un nouveau noyau de base ou un correctif hors du champ d'application du Live Patching ; cette demande relève de la maintenance et ne peut être annulée par la commande `live-patch status`.
Configurez le chemin de mise à jour en direct approprié pour SLES 16.0 ou 15 SP7, appliquez les correctifs de noyau éligibles et confirmez ce qui est actif sans le confondre avec une mise à jour de noyau nécessitant un redémarrage.
SLES 15 SP5 peut être migré en ligne vers SP6, mais chaque nœud doit être redémarré. Utilisez une mise à niveau progressive éprouvée ou une bascule bleue-verte pour garantir la disponibilité des charges de travail.
Créer, affiner et vérifier un profil AppArmor à privilèges minimaux sur SLES 15 SP7, avec une note claire sur la valeur par défaut de SELinux de SLES 16.
Utilisez le profil STIG pris en charge par SUSE pour analyser SLES 15, tester la correction, examiner les résultats restants et conserver les preuves d'évaluation.
Tracez une connexion Cockpit défaillante via DNS, port 9090, socket systemd, firewalld, TLS et paramètres de connexion en utilisant les instructions SUSE actuelles.
Créez une connexion Ethernet redondante sur SLES 15 avec YaST et Wicked, configurez l'agrégation active-sauvegarde et vérifiez les deux ports et le basculement.
Transformez un système SLES 15 existant en un profil AutoYaST vérifié, validez-le et utilisez-le pour déployer un serveur de test avec moins d'étapes manuelles.
Installez les outils SLES 15 KVM et libvirt, activez le service hôte approprié et configurez les machines virtuelles sélectionnées pour qu'elles démarrent après un redémarrage.
Utilisez les tâches systemd et le journal de démarrage précédent pour localiser un service, un montage ou une dépendance de stockage lents, puis corrigez-les sans masquer la cause.
Utilisez firewall-cmd pour inspecter la zone active, autoriser HTTP en toute sécurité, préserver l'accès SSH et vérifier que la règle survit à un rechargement sur SLES 15.
