SafeITExperts

SafeITExperts

Your expert guide to cybersecurity and digital privacy. Security hardening for all platforms : Windows, macOS, Linux, and Android. Solutions aligned standards : NIST and ANSSI for comprehensive digital protection.


openSUSE migration-tool : bugs et limites en 2026

Publié par Marc sur 15 Juin 2026, 19:47pm

Catégories : #migration-tool, #openSUSE, #Bugs, #Leap 15.6

openSUSE migration-tool : bugs et limites en 2026

Cet état des lieux examine les limites documentées de opensuse-migration-tool en 2025-2026 à partir de rapports publics, en distinguant les bugs confirmés, les effets de bord possibles et les questions encore ouvertes.

Écran de contrôle qui explose et bases de données en éclats pendant une migration openSUSE
Illustration : migration tool en échec – visualisation symbolique.

openSUSE migration-tool : faits rapportés, limites documentées et pistes de discussion

Ce document reprend l’analyse validée dans un format publiable, neutre et structuré, sans conclure à une défaillance générale de l’outil.

Période : 2025-2026 Périmètre : rapports publics Position : état des lieux factuel
Objectif : distinguer les bugs observés dans des cas précis, les effets de bord inhérents aux migrations majeures, et les pistes que la communauté pourrait documenter ou améliorer.

Schéma des impacts

opensuse-migration-tool
Bug 1 : base RPM bdb → ndb
Blocage pendant la migration
Échec du scriptlet prein de filesystem
Système non opérationnel dans le cas rapporté
Bug 2 : SELinux après migration
Services en échec au démarrage
Erreurs SELinux ou AVC
Absence de relabeling automatique dans le cas rapporté
Bug 3 : message “Dry run completed”
Message de succès trompeur
Confusion sur l’état réel de la migration

Objectif

📁 Reddit r/openSUSE

Basé sur des rapports publics 2025-2026

🐞 Bugzilla openSUSE

Bugs observés dans des cas précis

💬 forums.openSUSE.org

Effets de bord inhérents aux migrations majeures

📖 wiki openSUSE / SDB

Pistes techniques documentées par la communauté

Pistes techniques discutées

⚠️ Avertissement : les éléments ci-dessous sont issus de retours d’expérience communautaires ou de documentation connexe. Ils ne constituent ni une recommandation officielle SUSE, ni une garantie de succès. Test uniquement en environnement non critique, idéalement avec snapshot ou sauvegarde préalable.
📦 1. Vérification / conversion de la base RPM

Constat
Dans un cas documenté, la migration s’est bloquée pendant la conversion d’une base RPM ancienne encore en bdb, avec échec du scriptlet filesystem et système laissé dans un état dégradé. [source]

Vérification

rpm --showrc | grep db_backend

Piste discutée si le backend est bdb

rpm --define='%_db_backend ndb' --rebuilddb

Objectif
Éviter l’échec de conversion automatique observé pendant la migration.

🔒 2. Relabeling SELinux après migration

Constat
Un fil de 2025 décrit un cas où SELinux était installé avant migration mais inactif, puis où plusieurs services ont échoué au démarrage après passage à Leap 16.0, l’outil ne semblant pas avoir déclenché de relabeling automatique. [source]

Piste discutée

touch /.autorelabel
reboot

Variante (racine en lecture seule)

touch /etc/selinux/.autorelabel
reboot

Objectif
Forcer le réétiquetage complet des fichiers pour restaurer des contextes SELinux cohérents après migration.

📦 3. Préparation des dépôts avant migration

Constat
Des retours communautaires recommandent de simplifier l’environnement logiciel avant migration en limitant temporairement les dépôts actifs. [source]

Piste discutée

  • Mettre le système complètement à jour avant la migration.
  • Désactiver ou supprimer les dépôts tiers non indispensables.
  • Ne conserver, au moment critique, que les dépôts cœur recommandés pour la cible.
⏱️ 4. Exécution prudente en deux temps

Constat
Des utilisateurs décrivent une approche progressive : première exécution pour observer ce que l’outil propose, nettoyage des dépôts ou ajustements éventuels, puis seconde exécution pour mener la transition complète. [source]

Piste discutée

  • Faire une première passe d’observation ou de préparation.
  • Vérifier les dépôts, options et paquets proposés.
  • Relancer ensuite la migration dans un contexte simplifié.
  • Redémarrer seulement une fois le processus réellement terminé.

Contexte : place de l’outil dans l’écosystème

🛠️ openSUSE migration tool

Outil expérimental, focus sur la gestion des dépôts et bascules techniques. Déclaré non destiné à la production sans suite de tests complète.

GitHub →

🐧 Écosystème RHEL / Alma / Rocky

L’outil leapp est documenté comme solution supportée pour les migrations majeures, avec une forte insistance sur les prérequis et le dépannage.

Comparaison de maturité, pas de jugement de valeur.

📢 Statut expérimental

Le projet se déclare lui-même comme expérimental. L’équipe indique explicitement que l’outil n’est pas destiné à une utilisation en production tant qu’une suite de tests satisfaisante n’est pas en place.

Annonce Leap 16 Beta →

Bugs et comportements observés

1. Conversion bdb → ndb (mars 2026)
Symptômes : blocage, échec scriptlet filesystem
Contexte : base RPM très ancienne (bdb)
Certitude : conversion automatique échouée → système non opérationnel
2. Hang après reboot (janv. 2026)
Symptôme : migration effectuée, système ne démarre plus
Hypothèse : initramfs ou GPU NVIDIA
Certitude : boot anormal dans ce cas précis
3. Erreurs SELinux (oct. 2025)
Services en échec, erreurs AVC
SELinux inactif avant migration
Pas de relabeling automatique
4. “Dry run completed” (fév. 2026)
Message trompeur même après “abort”
Un bug a été ouvert pour cette ambiguïté

Questions ouvertes pour la communauté

📀 Base RPM héritée

Existe-t-il une procédure officielle recommandée pour vérifier ou convertir la base RPM avant migration ?

🔐 SELinux

L’outil a-t-il vocation à déclencher automatiquement un relabeling ? Documentation publique ?

🧪 Dry run

Un changement de wording ou de logique de sortie est-il prévu pour lever l’ambiguïté constatée ?

📦 Paquets tiers

L’outil détecte-t-il les paquets tiers ou dépôts non officiels ?

🗺️ Feuille de route

Existe-t-il une feuille de route publique pour la sortie du statut “expérimental” ?

Références principales

📄 GitHub

openSUSE migration tool
Dépôt officiel du projet, code source et documentation expérimentale.

github.com/openSUSE/opensuse-migration-tool →

🐞 Forum

bdb → ndb (mars 2026)
Blocage lors de la conversion de base RPM.

forums.opensuse.org/t/192610 →

🐞 Forum

Hang après reboot (janv. 2026)
Système ne redémarre plus après migration.

forums.opensuse.org/t/191395 →

🐞 Forum

SELinux problématique (oct. 2025)
Erreurs SELinux après migration, relabeling manquant.

forums.opensuse.org/t/188528 →

🐞 Forum

Message “Dry run completed” (fév. 2026)
Affichage trompeur du message de succès.

forums.opensuse.org/t/191811 →

📢 Annonce

Leap 16 entre en Beta (avril 2025)
Statut expérimental de l’outil de migration confirmé.

news.opensuse.org →

📖 Article

Préparation des dépôts (Linux-FRA)
Recommandations pour simplifier l’environnement avant migration.

linux-fra.com →

🐞 Forum

Migration progressive (mars 2026)
Exécution en deux temps pour réduire les risques.

forums.opensuse.org/t/193043 →

Lectures recommandées sur SafeITExperts

Pour approfondir la migration et la sécurité côté Linux / openSUSE.

📁 Guide

Systèmes de fichiers Linux 2026
Audit, sécurité et migration — utile face aux bases RPM et aux scriptlets bloquants évoqués ici.

Systèmes de fichiers Linux 2026 : audit, sécurité, migration →

⚙️ Guide

systemd 2025
Architecture et sécurité — pour les services qui échouent au démarrage après migration.

systemd 2025 : architecture et sécurité Linux →

🛡️ Guide

Linux sécurisé par défaut 2026
Durcissement et SELinux — en complément du relabeling post-migration.

Linux sécurisé par défaut en 2026 →

🔭 Panorama

Panorama sécurité OS 2026
Vue d’ensemble de la sécurité des systèmes d’exploitation.

Panorama de la sécurité des OS en 2026 →

À propos de l’auteur

Marc — Spécialiste indépendant en cybersécurité et protection de la vie privée, avec 35 ans d’expérience terrain en informatique. Spécialisé dans le durcissement des systèmes Linux, les architectures réseau axées sur la confidentialité et l’analyse concrète du niveau de sécurité des distributions Linux en conditions réelles. Toutes les configurations publiées sont éprouvées en production réelle. Approche inspirée des principes du GIAC GDSA : architectures sécurisées et résilientes, segmentation réseau, reverse proxies et modèle Zero Trust.

Publié sur SafeITExperts · Mis à jour le · Contact : safeitexperts@safeitexperts.com

Pour être informé des derniers articles, inscrivez vous :
Commenter cet article

Archives

Nous sommes sociaux !

Facebook X Bluesky Mastodon GitHub Reddit RSS

Articles récents