Migrer un système d'exploitation Linux WorkSpace vers un autre système d'exploitation

Vous pouvez migrer un système Linux existant WorkSpace vers un autre ensemble de systèmes d'exploitation Linux tout en préservant le répertoire personnel, les fichiers et les données de l'utilisateur. La migration remplace le volume racine (système d'exploitation) par un nouveau bundle tout en préservant le volume utilisateur (/home). Cela est différent d'une reconstruction, qui actualise le volume racine avec le même bundle de système d'exploitation.

La WorkSpace fonction Migrate gère automatiquement l'ensemble du processus, y compris la correction de la propriété des fichiers et le nettoyage de l'environnement de bureau en cas de besoin.

Chemins de migration pris en charge

Le tableau suivant indique les systèmes d'exploitation source et cible pris en charge pour la WorkSpace migration vers Linux.

Système d'exploitation source	Ubuntu 22.04	Graphiques Ubuntu 22.04	Ubuntu 24.04	RHEL 8	RHEL 9	Rocky 8	Rocky 9
Amazon Linux 2 (PCoIP)	✓	✓	✓	✓	✓	✓	✓
Amazon Linux 2 (WSP)	✓	✓	✓	✓	✓	✓	✓
Ubuntu 22.04	—	✓	✓	✓	✓	✓	✓
Graphiques Ubuntu 22.04	✓	—	✓	✓	✓	✓	✓
Ubuntu 24.04	✓	✓	—	✓	✓	✓	✓
RHEL 8	✓	✓	✓	—	✓	✓	✓
RHEL 9	✓	✓	✓	✓	—	✓	✓
Rocky 8	✓	✓	✓	✓	✓	—	✓
Rocky 9	✓	✓	✓	✓	✓	✓	—

Amazon Linux 2 est une source de migration valide mais n'est pas une cible de migration valide. Amazon Linux 2 est arrivé à sa fin de vie et il est WorkSpaces impossible d'en créer de nouveaux avec les bundles AL2.

Tous les chemins de migration entre Ubuntu, RHEL et Rocky Linux sont pris en charge dans les deux sens. Vous pouvez effectuer une mise à niveau (par exemple, RHEL 8 → RHEL 9) ou une rétrogradation (par exemple, Ubuntu 24.04 → Ubuntu 22.04). Vous pouvez également effectuer une migration entre familles de distribution (par exemple, Rocky 9 → Ubuntu 24.04 ou RHEL 9 → Rocky 8). La seule restriction est que vous ne pouvez pas migrer un bundle WorkSpace vers le même bundle qu'il utilise déjà.

Les migrations depuis Amazon Linux 2 nécessitent une correction automatique de la propriété de l'identifiant utilisateur et un nettoyage de l'environnement de bureau. Les migrations entre toutes les autres distributions (Ubuntu, RHEL, Rocky) ne nécessitent pas de correction de propriété car ces distributions utilisent toutes le protocole SSSD pour l'intégration d'Active Directory, qui attribue des identifiants utilisateur stables.

Conditions préalables

Avant de migrer un système Linux WorkSpace, vérifiez les points suivants :

• WorkSpace état — Le WorkSpace doit être dans l'AVAILABLEétat. Vous ne pouvez pas migrer un WorkSpace fichier en cours de démarrage, d'arrêt ou en état d'erreur.

• Aucune relation Forest Trust d'Active Directory : aucune relation Forest Trust ne doit être configurée dans le répertoire. WorkSpace SSSD, qui est utilisé par toutes les distributions Linux modernes pour l'intégration d'Active Directory, ne prend pas en charge Forest Trust. Si Forest Trust est configuré, la migration échouera lors du provisionnement.

• Stockage EBS suffisant : le stockage EBS WorkSpace doit être suffisant pour l'opération de migration.

Comment faire migrer un WorkSpace

Utilisation de AWS Console de gestion

1. Ouvrez la WorkSpaces console Amazon à l'adresse https://console.aws.amazon.com/workspaces/.

2. Dans le panneau de navigation, sélectionnez WorkSpaces.

3. Sélectionnez celui WorkSpace que vous souhaitez migrer.

4. Choisissez Actions, puis choisissez Migrer WorkSpace.

5. Sélectionnez le bundle de systèmes d'exploitation cible.

6. Choisissez Migrate (Migrer).

Utilisation de AWS CLI

Utilisez la migrate-workspace commande pour migrer un bundle WorkSpace vers un autre bundle :

aws workspaces migrate-workspace \
    --source-workspace-id ws-1234567890abcdef0 \
    --bundle-id wsb-jttwgmx20 \
    --region us-east-1

Pour trouver les identifiants de bundle cibles disponibles :

aws workspaces describe-workspace-bundles \
    --query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
    --output table

Surveillance de l'état de migration

La migration prend généralement de 20 à 30 minutes. Surveillez l' WorkSpaceétat :

aws workspaces describe-workspaces \
    --workspace-ids ws-1234567890abcdef0 \
    --query 'Workspaces[0].State' \
    --output text

Les WorkSpace transitions passent par les états suivants : AVAILABLE → PENDING → AVAILABLE (en cas de succès) ou ERROR (en cas d'échec). Si la migration échoue pendant le provisionnement, le plan de contrôle restaure automatiquement l'original WorkSpace.

Post-migration vérification

Une fois la migration terminée, vérifiez les points suivants :

Vérifier le WorkSpace statut

Vérifiez que l'AVAILABLEétat WorkSpace est activé dans la AWS console ou via la CLI.

Vérifier la connexion de l'utilisateur

Demandez à l'utilisateur de se connecter au WorkSpace et de confirmer que le bureau se charge correctement.

Consultez le journal de migration

Pour les migrations AL2, consultez le journal de migration pour plus de détails sur ce qui a été modifié :

cat ~/workspace-migration-log-*/user-id-migration.txt

Ce journal indique l'ancien et le nouveau nom d'utilisateur, le nombre de fichiers modifiés au cours de chaque phase et les horodatages.

Vérifier l'état de la phase 2

Pour vérifier si la migration en arrière-plan est terminée :

# Check if the Phase 2 service is still running
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# "inactive" or "not found" means Phase 2 has completed
# "activating" means Phase 2 is still running (Type=simple service)

Déroulement de la migration

Lorsque vous lancez une migration, les étapes suivantes se produisent :

1. Le volume utilisateur (/home) est détaché du volume existant WorkSpace.

2. L'existant WorkSpace est éliminé.

3. Un nouveau bundle WorkSpace est créé à partir du bundle du système d'exploitation cible.

4. Le volume utilisateur est reconnecté à la nouvelle WorkSpace adresse/home.

5. Le nouveau WorkSpace est provisionné : le réseau est configuré, l'instance rejoint Active Directory et le répertoire personnel de l'utilisateur est configuré.

6. En cas de migration depuis Amazon Linux 2, la propriété du fichier est corrigée et la configuration de bureau existante est nettoyée (voirMigration depuis Amazon Linux 2).

7. Le WorkSpace redémarre et devient disponible pour que l'utilisateur puisse se connecter.

Le répertoire personnel de l'utilisateur est stocké sur un volume EBS distinct qui est conservé tout au long de la migration. Tous les fichiers présents /home/username survivent à la transition, y compris les documents, les clés SSH, la configuration du shell et les données d'application.

Migration depuis Amazon Linux 2

Les migrations depuis Amazon Linux 2 impliquent des étapes supplémentaires qui sont gérées automatiquement. Cette section explique ce qui se passe et pourquoi.

Pourquoi les migrations AL2 sont différentes

Amazon Linux 2 utilise Winbind pour l'intégration d'Active Directory, tandis que toutes les nouvelles distributions Linux (Ubuntu, RHEL, Rocky) utilisent SSSD. Ces deux systèmes attribuent des ID utilisateur POSIX différents au même utilisateur Active Directory :

• Winbind (AL2) : attribue des identifiants utilisateur à l'aide d'un schéma algorithmique imprévisible (par exemple, UID 1000).

• SSSD (distributions modernes) : attribue des identifiants utilisateur stables dérivés du SID Active Directory (par exemple, UID 1285401133).

Après la migration, tous les fichiers du répertoire personnel de l'utilisateur sont détenus par l'ancien UID Winbind. L'utilisateur ne peut pas accéder à ses propres fichiers tant que la propriété n'est pas corrigée pour correspondre au nouvel UID SSSD.

En outre, Amazon Linux 2 utilise l'environnement de bureau MATE (GNOME 2), tandis que les nouvelles distributions utilisent GNOME 3.x. Les fichiers de configuration MATE sont en conflit avec GNOME 3.x et doivent être nettoyés pour garantir le bon fonctionnement du bureau.

Two-phase correction de propriété

Pour éviter les délais d'approvisionnement, la correction de propriété est divisée en deux phases.

Phase 1 (pendant le provisionnement)

Corrige la propriété des fichiers critiques pour le bureau nécessaires à une connexion immédiate :

• Répertoire personnel lui-même

• Clés SSH () ~/.ssh/

• Configuration du bureau (~/.config/)

• Profilés de coque (.bashrc,.bash_profile,.profile)

• Tous les fichiers ou répertoires de haut niveau sans autorisation de lecture universelle

La phase 1 s'achève rapidement, quelle que soit la taille totale du répertoire de base, ce qui garantit que le provisionnement n'échoue jamais en raison de répertoires de base volumineux.

Phase 2 (arrière-plan, après le redémarrage)

Corrige la propriété de tous les fichiers restants :

• S'exécute en tant que service systemd (ws-migrate-phase2.service) au démarrage

• Réessaie la résolution utilisateur pendant 10 minutes au maximum si le SSSD n'est pas encore prêt au démarrage. Si la résolution expire, le service reste activé et réessaie au prochain démarrage

• Utilise la I/O priorité d'inactivité et la priorité la plus faible du processeur, sans impact sur l'expérience utilisateur

• L'utilisateur peut se connecter et travailler normalement pendant l'exécution de la phase 2

• Les corrections de propriété pour les grands répertoires (plus de 10 millions de fichiers) continueront d'être effectuées en arrière-plan

• Self-removes le fichier de service systemd une fois terminé avec succès

Nettoyage de l'environnement de bureau

Lors de la migration depuis AL2, les fichiers de configuration de bureau MATE suivants sont déplacés vers un répertoire de sauvegarde dans le journal de migration (~/workspace-migration-log-YYYYMMDD/removed-configuration/) :

• ~/.config/dconf/user— base MATE-specific de données dconf

• ~/.gconf/— Répertoire GConf Legacy

• ~/.config/mate-session/— Configuration de session MATE

• ~/.config/mate-panel/— Configuration du panneau MATE

• ~/.local/share/mate-panel/— Données d'application du panneau MATE

• ~/.config/pluma/— Paramètres de l'éditeur de texte MATE

• ~/.config/caja/— Configuration du gestionnaire de fichiers MATE

• ~/.config/marco/— Paramètres du gestionnaire de fenêtres MATE

• ~/.config/gtk-2.0/, ~/.config/gtk-3.0/ — Configurations du thème GTK

• ~/.local/share/recently-used.xbel— Liste des fichiers récents

Ces fichiers ne sont pas supprimés ; ils sont déplacés vers le répertoire de sauvegarde et peuvent être récupérés si nécessaire. Après le nettoyage, le bureau se charge avec l'apparence par défaut de GNOME 3.x.

Restauration du contexte SELinux

Lorsque la cible de migration est RHEL ou Rocky Linux, les contextes de sécurité SELinux sont toujours restaurés sur l'intégralité du répertoire personnel de l'utilisateur (/home/username), quel que soit le système d'exploitation source. Cela s'applique à tous les chemins de migration qui ciblent une SELinux-enabled distribution, notamment :

• Migrations à partir de sources autres que SELinux (Ubuntu, AL2), où les fichiers sont totalement dépourvus d'étiquettes SELinux.

• Migrations entre SELinux-enabled distributions (par exemple, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9 ou RHEL 9 → Rocky 9). Les versions de la politique SELinux et les définitions du contexte des fichiers peuvent changer entre les versions majeures.

Dans tous les cas, la restauration du contexte garantit que les fichiers possèdent les étiquettes de sécurité appropriées à la politique SELinux de la distribution cible.

La restauration du contexte s'exécute en deux phases, en fonction de la correction de propriété :

• Phase 1 : Restaure les contextes sur les chemins critiques (~/.ssh/,~/.config/) lors du provisionnement.

• Phase 2 : restaure les contextes sur l'ensemble du répertoire personnel en arrière-plan après le redémarrage.

Correction automatique du répertoire de base de la RFC 2307

Active Directory prend en charge les attributs RFC 2307 (également appelés « attributs Unix »), qui permettent aux administrateurs de spécifier les propriétés utilisateur POSIX, y compris le chemin du répertoire de base (). unixHomeDirectory SSSD respecte cet attribut, tandis que Winbind sur AL2 l'a ignoré et l'a toujours utilisé. /home/username

Lors de la migration d'AL2 vers une SSSD-based distribution, l'objet utilisateur AD peut avoir été unixHomeDirectory défini sur un chemin différent (par exemple,/home/CORP/jsmith). Dans ce cas, SSSD résout le répertoire personnel de l'utilisateur sur ce AD-specified chemin. Comme les données réelles de l'utilisateur datent /home/username de l'ère AL2, le AD-specified chemin n'existe pas sur le volume.

Le système de migration détecte automatiquement cette situation :

1. Après le provisionnement, SSSD résout le répertoire personnel de l'utilisateur vers le AD-specified chemin.

2. Le système de migration vérifie si ce chemin existe sur le volume utilisateur.

3. Si le AD-specified chemin n'existe /home/username pas mais qu'il existe, le système le reconnaît comme une incompatibilité de chemin selon la RFC 2307.

4. Le système s'installe override_homedir=/home/%u directement /etc/sssd/sssd.conf (sur toutes les sections du domaine) et redémarre SSSD.

5. Après le redémarrage de SSSD, le répertoire personnel de l'utilisateur est résolu vers /home/username l'endroit où se trouvent réellement les données.

6. La migration s'effectue normalement sur la base des données existantes.

Cette correction est permanente : le override_homedir paramètre est conservé lors des redémarrages et des futurs redémarrages du SSSD. sssd.conf

Activation des chemins du répertoire de base RFC 2307 après la migration

Si la migration a automatiquement corrigé le chemin du répertoire de base de la RFC 2307 et que vous souhaitez que SSSD respecte l'unixHomeDirectoryattribut AD à l'avenir, vous pouvez annuler le remplacement. Il s'agit d'une modification de configuration avancée qui ne doit être effectuée que si vous en comprenez les implications.

Avertissement

Après avoir supprimé la dérogation, SSSD utilisera le chemin du AD-specified répertoire de base. Vous devez déplacer les données de l'utilisateur vers ce chemin avant de supprimer la dérogation, sinon l'utilisateur obtiendra un répertoire personnel vide.

Pour restaurer les chemins du répertoire de base de la RFC 2307 :

Étape 1 : Déterminer le chemin du AD-specified répertoire de base

# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
    "(sAMAccountName=jsmith)" unixHomeDirectory

Étape 2 : déplacer les données de l'utilisateur vers le AD-specified chemin

sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith

Étape 3 : Supprimer le paramètre override_homedir de /sssd.conf etc/sssd

sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf

Étape 4 : Redémarrer SSSD

sudo systemctl restart sssd

Étape 5 : Vérifiez que le répertoire de base est correctement résolu

getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory

Important

Une fois la dérogation supprimée, les futures WorkSpace reconstructions et migrations utiliseront le AD-specified chemin. Assurez-vous que les données se trouvent au bon emplacement avant la prochaine reconstruction ou migration.

Notifications utilisateur

Le système de migration utilise deux mécanismes de notification pour tenir l'utilisateur informé :

1. Notifications de service Systemd de phase 2 — Si l'utilisateur est connecté au poste de travail lorsque la phase 2 démarre ou se termine, il reçoit des notifications directement depuis le service :

   • Au début de la phase 2 : « Terminer la migration des fichiers en arrière-plan. Vous pouvez continuer à travailler normalement. Certains fichiers peuvent rester inaccessibles jusqu'à la fin de la migration. »

   • À la fin de la phase 2 : « La migration des fichiers s'est terminée avec succès. Tous les fichiers devraient désormais avoir la propriété correcte. Consultez ~/workspace-migration-log-* pour plus de détails. »

2. Notification de connexion au démarrage automatique de XDG — Une entrée de démarrage automatique (~/.config/autostart/ws-migration-notify.desktop) s'exécute /usr/lib/skylight/check-migration-status lors de la première connexion après la migration. Cela permet de gérer le cas où l'utilisateur se connecte alors que la phase 2 est toujours en cours ou une fois celle-ci terminée :

   • Si la phase 2 est toujours en cours : « La migration des fichiers s'exécute en arrière-plan. Vous pouvez continuer à travailler normalement. Certains fichiers peuvent rester inaccessibles jusqu'à la fin de la migration. »

   • Si la phase 2 est terminée : « La migration des fichiers s'est terminée avec succès. Tous les fichiers devraient désormais avoir la propriété correcte. Consultez ~/workspace-migration-log-* pour plus de détails. »

   L'entrée de démarrage automatique est supprimée après l'affichage de la notification d'achèvement afin qu'elle ne soit pas exécutée lors des connexions suivantes.

Si l'utilisateur n'est pas connecté (par exemple, un arrêt automatique WorkSpace auquel il n'a pas accédé), la phase 2 s'exécute silencieusement sans erreur.

Migration entre les distributions modernes

Les migrations entre les distributions Ubuntu, RHEL et Rocky Linux ne nécessitent pas de correction de propriété de l'identifiant utilisateur. Toutes ces distributions utilisent SSSD pour l'intégration d'Active Directory, qui attribue des identifiants utilisateur stables dérivés du SID AD. Les fichiers de l'utilisateur restent correctement propriétaires tout au long de la migration.

Les voies de migration les plus courantes dans cette catégorie sont les suivantes :

• Cross-family: Ubuntu 22.04 ↔ RHEL 8/9, Ubuntu 22.04 ↔ Rocky 8/9, RHEL ↔ Rocky

• Mises à niveau de version : Ubuntu 22.04 → Ubuntu 24.04, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9

• Bundles graphiques : N'importe quelle source → Ubuntu 22.04 Graphics. Ubuntu Graphics WorkSpaces peut également migrer vers n'importe quelle cible non graphique.

Pour les migrations vers des cibles RHEL ou Rocky Linux, la restauration du contexte SELinux est toujours exécutée pour garantir que les fichiers possèdent les étiquettes de sécurité appropriées à la politique SELinux de la distribution cible. Cela s'applique quelle que soit la distribution de la source. Pour les fichiers dont les étiquettes sont déjà correctes, la restauration est interdite.

Ce que les utilisateurs conservent et ce qui change

Ce qui est préservé

• Tous les fichiers du répertoire de base (Documents, Téléchargements, Bureau, etc.)

• Clés SSH et configuration () ~/.ssh/

• Configuration du shell (.bashrc,.profile,.bash_profile)

• Favoris et profils du navigateur (Firefox, Chrome)

• Application-specific données et configuration (sauf les composants de bureau MATE pour les migrations AL2)

Quels sont les changements

• L'environnement de bureau reprend l'apparence par défaut de GNOME 3.x sur la distribution cible.

• Les anciennes préférences de bureau MATE sont supprimées et sauvegardées (migrations AL2 uniquement).

• Les icônes du bureau et les personnalisations des panneaux sont rétablies par défaut.

• Les applications installées sur le volume racine sont remplacées par les applications par défaut du bundle cible. Les applications installées par l'utilisateur dans son répertoire personnel sont conservées.

Auto-stop et toujours actif WorkSpaces

Auto-stop WorkSpaces

Pour les WorkSpaces configurations avec arrêt automatique (hibernation après expiration du délai d'inactivité) :

1. La migration est terminée et le WorkSpace redémarrage est effectué.

2. Le service d'arrière-plan de phase 2 démarre au démarrage. Si le SSSD n'est pas encore prêt, le service tente à nouveau de résoudre le problème par l'utilisateur pendant 10 minutes au maximum avant de poursuivre.

3. Si l'utilisateur ne se connecte pas pendant le délai d'inactivité (généralement 1 heure), la phase 2 s'exécute silencieusement en arrière-plan.

4. Pour les charges de travail classiques (moins de 100 000 fichiers), la phase 2 se termine dans le délai d'inactivité.

5. Il WorkSpace hiberne une fois la phase 2 terminée.

6. Lorsque l'utilisateur se connecte ensuite, la migration est déjà terminée et aucune notification n'est affichée.

Always-on WorkSpaces

Pour une utilisation permanente : WorkSpaces

1. La migration est terminée et le WorkSpace redémarrage est effectué.

2. Le service d'arrière-plan de la phase 2 démarre au démarrage et s'exécute jusqu'à la fin.

3. L'utilisateur peut se connecter à tout moment et travailler normalement. La phase 2 s'exécute en priorité d'inactivité et n'a aucune incidence sur les performances.

Limitations connues

• Active Directory Forest Trust : SSSD ne prend pas en charge les relations Forest Trust. WorkSpaces dans les annuaires où Forest Trust est configuré ne peuvent pas être migrés.

• Amazon Linux 2 comme cible : AL2 a atteint la fin de vie et n'est pas une cible de migration valide. Vous ne pouvez migrer que depuis AL2, pas vers AL2.

• Aucune annulation : les migrations terminées ne peuvent pas être restaurées vers le système d'exploitation précédent. Si vous devez revenir au système d'exploitation précédent, vous devez lancer une nouvelle migration (sauf pour AL2, qui n'est pas une cible valide).

• Personnalisations de bureau MATE : lors de la migration depuis AL2, les préférences de bureau MATE sont supprimées. Ils sont sauvegardés ~/workspace-migration-log-YYYYMMDD/removed-configuration/ mais ne peuvent pas être automatiquement appliqués au bureau GNOME 3.x.

• Répertoires personnels volumineux : pour les répertoires personnels contenant des millions de fichiers, la correction de propriété en arrière-plan de la phase 2 peut prendre plusieurs heures. L'utilisateur peut travailler normalement pendant cette période, mais le propriétaire de certains fichiers peut être incorrect jusqu'à la fin de la phase 2.

• Partage de fichiers : si l'utilisateur a configuré le partage de fichiers (par exemple, les partages Samba) sur son répertoire personnel, le changement de propriétaire lors de la migration AL2 peut affecter les autorisations de partage. Les configurations de partage de fichiers devront peut-être être rétablies après la migration.

• Dérogation de la RFC 2307 : si la migration a automatiquement corrigé une incompatibilité du chemin du répertoire de base de la RFC 2307, l'attribut AD est remplacé via in. unixHomeDirectory override_homedir sssd.conf Voyez Activation des chemins du répertoire de base RFC 2307 après la migration si vous voulez que SSSD respecte le AD-specified chemin.

Résolution des problèmes

Échec de la migration lors du provisionnement

Si la migration échoue et qu'elle WorkSpace revient à ERROR l'état initial, le plan de contrôle tente automatiquement de restaurer l'état d'origine WorkSpace. Consultez les journaux de provisionnement :

# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log

Causes courantes :

• Configuration de Forest Trust : SSSD ne peut pas joindre un domaine à Forest Trust. Supprimez Forest Trust avant de migrer.

• Problèmes de connectivité AD : WorkSpace Impossible d'atteindre le contrôleur de domaine. Vérifiez les règles du réseau VPC et des groupes de sécurité.

• Échec de résolution DNS : WorkSpace Impossible de résoudre le domaine AD. Vérifiez la configuration DNS.

L'utilisateur ne peut pas se connecter après la migration

• Vérifiez WorkSpace qu'il est en AVAILABLE état.

• Vérifiez que la jointure de domaine s'est correctement terminée : sudo cat /var/lib/skylight/domain-join-status doit contenirtrue.

• Vérifiez que l'utilisateur peut être résolu : id username doit renvoyer l'UID et les groupes de l'utilisateur.

• Vérifiez l'état du SSSD : sudo sssctl domain-status domain devrait s'afficherOnline status: Online.

Le bureau semble cassé ou a un mauvais thème

Cela se produit généralement lors de la migration depuis AL2 et certains fichiers de configuration MATE n'ont pas été nettoyés. Pour rétablir les paramètres par défaut du bureau :

# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf

# Log out and log back in

Les fichiers sont mal propriétaires après la migration

Si les fichiers du répertoire de base sont inaccessibles après une migration AL2, la phase 2 est peut-être toujours en cours d'exécution :

# Check Phase 2 status
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# Check the migration log for progress
cat ~/workspace-migration-log-*/user-id-migration.txt

Si la phase 2 est terminée mais que le propriétaire de certains fichiers est toujours incorrect, vous pouvez les corriger manuellement :

# Find files with the old UID and change ownership
sudo find /home/username -uid old-uid -exec chown username {} +
sudo find /home/username -gid old-gid -exec chgrp username {} +

Emplacement des fichiers journaux

Journal	Location	Table des matières
Journal des connexions au domaine	/var/log/skylight/domain-join.log	Flux de travail de provisionnement complet, y compris la phase 1 de migration
Résumé de la migration	~/workspace-migration-log-YYYYMMDD/user-id-migration.txt	Old/new UID, nombre de fichiers, horodatages pour les phases 1 et 2
Backed-up Configurations MATE	~/workspace-migration-log-YYYYMMDD/removed-configuration/	Fichiers de bureau MATE supprimés lors de la migration vers AL2
Liste des fichiers de la phase 1	~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt	Fichiers traités pendant la phase 1 (utilisés par la phase 2 pour éviter les doublons)