Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Linux Enterprise Server / Guide de mise à niveau / Préparation de la mise à niveau
S'applique à SUSE Linux Enterprise Server 15 SP6

3 Préparation de la mise à niveau

 

Avant de lancer la procédure de mise à niveau, assurez-vous que votre système est prêt. Cette préparation implique notamment la sauvegarde des données et la consultation des notes de version. Le chapitre suivant vous guide tout au long de ces étapes.

3.1 Vérification de l'actualisation du système

 

La mise à niveau du système est prise en charge uniquement à partir du niveau de correctif le plus récent. Assurez-vous que les dernières mises à jour système sont installées, en exécutant zypper patch ou en démarrant le module YaST Online-Update.

Note
Note : nouvelle clé de signature de 4 096 bits pour SUSE Linux Enterprise 15

Au milieu de l'année 2023, la gamme de produits SUSE Linux Enterprise 15 est passée d'une clé de signature RSA de 2 048 bits à une nouvelle clé RSA de 4 096 bits. Cette modification concerne les paquetages RPM, les dépôts de paquetages et les signatures ISO. Les anciens dépôts qui ne sont plus mis à jour et les RPM publiés jusqu'à la date de basculement restent signés avec l'ancienne clé de 2 048 bits.

Si vous mettez à jour votre système, la nouvelle clé est automatiquement importée dans le trousseau de clés RPM à partir du paquetage suse-build-key sous SLE 15 SP4 et SP5, ainsi que dans les versions LTSS de SLE 15 SP1, SP2 et SP3.

Si la clé n'a pas encore été importée, vous pouvez l'importer manuellement avec la commande suivante : 

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

Si vous exécutez une version plus ancienne de SLE ou si vous n'avez pas importé la nouvelle clé, vous serez invité à l'approuver pendant la mise à niveau. Vérifiez que l'empreinte correspond : 

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

En outre, une clé RSA de réserve de 4 096 bits a été importée à des fins de reprise après sinistre : 

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

Cette clé peut être importée manuellement à l'aide de la commande suivante : 

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Les deux clés sont également disponibles sur le support d'installation et sur le site Web de SUSE à l'adresse suivante : https://www.suse.com/support/security/keys/.

3.2 Lisez les notes de version

 

Les notes de version fournissent une liste de toutes les modifications, nouvelles fonctionnalités et problèmes connus. Vous pouvez également trouver les notes de version sur le support d'installation dans le répertoire docu.

Les notes de version contiennent généralement uniquement les changements effectués entre deux versions successives. Si vous omettez d'installer un ou plusieurs Service Packs, consultez néanmoins les notes de version de ces Service Packs ignorés.

Consultez les notes de version pour vérifier si les conditions suivantes s'appliquent :

  • Votre matériel implique certaines considérations spéciales.

  • Des paquetages logiciels utilisés actuellement ont été considérablement modifiés.

  • Votre installation nécessite des précautions particulières.

3.3 Exécution d'une sauvegarde

 

Avant la mise à niveau, sauvegardez vos données en copiant les fichiers de configuration existants sur un support distinct (tel qu'un périphérique à bande, un disque dur amovible, etc). Cela concerne principalement les fichiers stockés dans /etc, ainsi que certains répertoires et fichiers sous /var et /opt. Vous pouvez également écrire les données de l'utilisateur de /home (les répertoires HOME) sur un support de sauvegarde.

Sauvegardez ces données en tant qu'utilisateur root. Seul l'utilisateur root a des droits suffisants pour tous les fichiers locaux.

Si vous avez sélectionné Mettre à jour un système existant comme mode d'installation dans YaST, vous pouvez choisir d'effectuer une sauvegarde (système) ultérieurement. Vous pouvez inclure tous les fichiers modifiés, ainsi que ceux issus du répertoire /etc/sysconfig. Il ne s'agit toutefois pas d'une sauvegarde complète, dans la mesure où il manque tous les autres répertoires importants mentionnés ci-dessus. Recherchez la sauvegarde dans le répertoire /var/adm/backup.

3.4 Vérification de l'espace disque disponible

 

La taille des logiciels tend à augmenter de versions en versions. Il convient donc de vérifier l'espace disponible sur la partition avant d'effectuer la mise à jour. Si vous pensez que vous allez manquer d'espace disque, sauvegardez vos données avant d'augmenter l'espace disponible en redimensionnant des partitions, par exemple. Il n'existe pas de règle précise concernant l'espace de chaque partition. L'espace requis dépend de votre profil particulier de partitionnement et du logiciel sélectionné.

Note
Note : vérification automatique de l'espace dans YaST

Au cours de la procédure de mise à jour, YaST vérifie la quantité d'espace disque disponible et affiche un avertissement si la taille de l'installation risque de dépasser la quantité d'espace disponible. Dans ce cas, la mise à jour risque de rendre le système inutilisable ! Si vous savez exactement ce que vous faites (en ayant effectué des tests au préalable), vous pouvez ignorer l'avertissement et poursuivre la mise à jour.

3.4.1 Vérification de l'espace disque sur des systèmes de fichiers non-Btrfs

 

Utilisez la commande df pour obtenir une liste de l'espace disque disponible. Dans l'Exemple 3.1, « Listage avec df -h », la partition root est /dev/sda3 (montée en tant que /).

Exemple 3.1 : Listage avec df -h
 
Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       44G    4G   40G   9% /data

3.4.2 Vérification de l'espace disque sur des systèmes de fichiers racines Btrfs

 

Sur un système de fichiers Btrfs, la sortie de df peut être trompeuse, étant donné que, en plus de l'espace alloué par les données brutes, un système de fichiers Btrfs alloue et utilise également de l'espace pour les métadonnées.

Par conséquent, un système de fichiers Btrfs peut signaler un manque d'espace, même s'il semble qu'il reste une grande quantité d'espace disponible. Dans ce cas, tout l'espace alloué aux métadonnées est utilisé. Pour plus de détails sur la vérification de l'espace utilisé et disponible sur un système de fichiers Btrfs, reportez-vous au Section 1.2.2.3, “Checking for free space”. Pour plus d'informations, consultez la commande man 8 btrfs-filesystem et la page https://btrfs.wiki.kernel.org/index.php/FAQ.

Si vous utilisez Btrfs en tant que système de fichiers racines sur votre machine, assurez-vous qu'il dispose de suffisamment d'espace libre. Vérifiez l'espace disponible sur toutes les partitions montées. Dans le pire des cas, une mise à niveau a besoin d'autant d'espace disque que le système de fichiers racine actuel (sans le répertoire /.snapshot) pour un nouvel instantané.

Les recommandations suivantes ont fait leurs preuves :

  • Pour tous les systèmes de fichiers, y compris Btrfs, vous avez besoin de suffisamment d'espace disque disponible pour télécharger et installer des RPM volumineux. L'espace occupé par les anciens RPM n'est libéré qu'après l'installation des nouveaux RPM.

  • Pour Btrfs avec des instantanés, vous avez au minimum besoin d'une quantité d'espace libre égale à celle occupée par votre installation actuelle. Il est recommandé de disposer de deux fois plus d'espace libre que celui occupé par l'installation actuelle.

    Si vous ne disposez pas de suffisamment d'espace, vous pouvez tenter de supprimer les anciens instantanés à l'aide de snapper : 

    # snapper list
      # snapper delete NUMBER

    Toutefois, cela ne fonctionne pas toujours. Avant la migration, la plupart des instantanés n'occupent pas tellement d'espace.

3.5 Liste des paquetages et dépôts installés

 

Vous pouvez enregistrer une liste des paquetages installés ; par exemple pour effectuer une nouvelle installation d'une nouvelle version majeure de SLE ou pour revenir à l'ancienne version.

Note
Note

N'oubliez pas que les paquetages installés ou dépôts utilisés ne sont pas tous disponibles dans les versions plus récentes de SUSE Linux Enterprise. Certains ont parfois été renommés et d'autres remplacés. Il se peut aussi que certains paquetages restent disponibles pour des raisons d'héritage, mais qu'un autre paquetage soit utilisé par défaut. Par conséquent, une modification manuelle des fichiers peut s'avérer nécessaire. Elle peut être réalisée avec n'importe quel éditeur de texte.

  1. Créez un fichier nommé repositories.bak.repo contenant une liste de tous les dépôts utilisés : 

    # zypper lr -e repositories.bak

  2. Créez un fichier nommé installed-software.bak contenant une liste de tous les paquetages utilisés : 

    # rpm -qa --queryformat '%{NAME}\n' >
     installed-software.bak

  3. Sauvegardez les fichiers. Les dépôts et paquetages installés peuvent être restaurés à l'aide des commandes suivantes : 

    # zypper ar repositories.bak.repo
# zypper install $(cat installed-software.bak)
    Note
    Note : augmentation du nombre de paquetages en cas de mise à jour vers une nouvelle version majeure

    Un système mis à niveau vers une nouvelle version majeure (SLE X+1) peut contenir plus de paquetages que le système initial (SLE X). Il en contient aussi davantage qu'une nouvelle installation de SLE X+1 avec la même sélection de modèle. Il existe plusieurs raisons à cela :

    • Les paquetages ont été divisés pour permettre de les sélectionner de manière plus précise. Par exemple, 37 paquetages texlive sous SLE 11 ont été répartis en plus de 3 000 paquetages sous SLE 15.

    • Lorsqu'un paquetage a été divisé, tous les nouveaux paquetages sont installés de manière à conserver les mêmes fonctionnalités que la version précédente en cas de mise à niveau. Toutefois, la nouvelle configuration par défaut pour une nouvelle installation de SLE X+1 ne consiste pas forcément à installer tous les paquetages.

    • Les paquetages hérités de SLE X peuvent être conservés pour des raisons de compatibilité.

    • Les dépendances de paquetages et l'étendue des modèles peuvent avoir changé.

3.6 Désactivation de l'extension LTSS

 

Si vous mettez à niveau un système SUSE Linux Enterprise Server avec l'extension LTSS (Long Term Service Pack Support) vers une version bénéficiant encore d'un support général, la mise à niveau échoue avec l'erreur No migration available (Aucune migration disponible). Cela se produit car zypper migration tente de migrer tous les dépôts, mais il n'existe pas encore de dépôt LTSS pour la nouvelle version.

Pour résoudre ce problème, désactivez l'extension LTSS avant la mise à niveau.

  1. Vérifiez si l'extension LTSS est activée : 

    > sudo SUSEConnect --list-extensions | grep LTSS
SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

  2. Désactivez l'extension LTSS avec la commande de la sortie SUSEConnect ci-dessus : 

    > sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
To server: https://scc.suse.com/

  3. Vérifiez que le dépôt LTSS n'est plus présent avec zypper lr.

3.7 Migration de votre base de données PostgreSQL

 

SUSE Linux Enterprise Server 15 SP6 est livré avec les versions 14 et 15 de la base de données PostgreSQL. Bien que la version 15 soit la version par défaut, la version 14 est toujours fournie via le module Legacy pour les mises à niveau à partir de versions antérieures de SUSE Linux Enterprise Server.

En raison du travail de migration requis pour la base de données, le processus de mise à niveau n'est pas automatique. De ce fait, le passage d'une version à l'autre doit être effectué manuellement.

La migration est exécutée à l'aide de la commande pg_upgrade. Elle constitue une méthode qui diffère du vidage et du rechargement classique. Par rapport à la méthode de « vidage et rechargement », la migration effectuée par le biais de la commande pg_upgrade est plus rapide.

Les fichiers programmes de chaque version PostgreSQL sont stockés dans des répertoires différents selon la version, Par exemple, dans /usr/lib/postgresql96/ pour la version 9.6, dans /usr/lib/postgresql10/ pour la version 10 et dans /usr/lib/postgres13/ pour la version 13. Notez que la stratégie de contrôle des versions de PostgreSQL a changé entre les versions majeures 9.6 et 10. Pour plus de détails, reportez-vous à la page https://www.postgresql.org/support/versioning/.

Important
Important : mise à niveau à partir de SLE 11

Lors de la mise à niveau à partir de SLE 11, postgresql94 sera désinstallé et ne pourra plus être utilisé pour la migration de la base de données vers une version ultérieure de PostgreSQL. Par conséquent, veillez à migrer la base de données PostgreSQL avant de mettre à niveau votre système.

La procédure ci-dessous décrit la migration de la base de données de la version 12 vers la version 13. Lorsque vous utilisez une version différente comme source ou comme cible, remplacez les numéros de version en conséquence.

Pour effectuer la migration de la base de données, procédez comme suit :

  1. Assurez-vous que les conditions préalables suivantes sont remplies :

    • Si ce n'est déjà fait, mettez à niveau les paquetages de l'ancienne version de PostgreSQL vers la version la plus récente par le biais d'une mise à jour de maintenance.

    • Créez une sauvegarde de votre base de données existante.

    • Installez les paquetages de la nouvelle version majeure de PostgreSQL. Pour SLE 15 SP6, cela implique d'installer postgresql13-server et tous les paquetages dont il dépend.

    • Installez le paquetage postgresql13-contrib qui contient la commande pg_upgrade.

    • Assurez-vous que vous disposez de suffisamment d'espace disponible dans la zone de stockage des données PostgreSQL, par défaut /var/lib/pgsql/data. Si l'espace risque d'être insuffisant, essayez de réduire la taille à l'aide de la commande SQL suivante sur chaque base de données (cette opération peut prendre un certain temps) : 

      VACUUM FULL

  2. Arrêtez le serveur PostgreSQL avec une des commandes suivantes : 

    # /usr/sbin/rcpostgresql stop

    ou 

    # systemctl stop postgresql.service

    (Selon la version SLE que vous utilisez comme version de départ pour la mise à niveau)

  3. Renommez votre ancien répertoire de données : 

    # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

  4. Initialisez votre nouvelle instance de base de données, soit manuellement avec initdb, soit en démarrant et arrêtant PostgreSQL, qui le fera automatiquement : 

    # /usr/sbin/rcpostgresql start
# /usr/sbin/rcpostgresql stop

    ou 

    # systemctl start postgresql.service
# systemctl stop postgresql.service

    (Selon la version SLE que vous utilisez comme version de départ pour la mise à niveau)

  5. Si vous avez modifié les fichiers de configuration dans l'ancienne version, pensez à transférer ces modifications vers les nouveaux fichiers de configuration. Cela peut concerner les fichiers postgresql.auto.conf, postgresql.conf, pg_hba.conf et pg_ident.conf. Les anciennes versions de ces fichiers se trouvent dans /var/lib/pgsql/data.old/ ; les nouvelles versions sont disponibles dans /var/lib/pgsql/data.

    Notez qu'il est déconseillé de copier les anciens fichiers de configuration, car cela peut écraser de nouvelles options, de nouvelles valeurs par défaut et des commentaires modifiés.

  6. Démarrez le processus de migration en tant qu'utilisateur postgres : 

    # su - postgres
postgres > pg_upgrade \
 --old-datadir "/var/lib/pgsql/data.old" \
 --new-datadir "/var/lib/pgsql/data" \
 --old-bindir "/usr/lib/postgresql12/bin/" \
 --new-bindir "/usr/lib/postgresql13/bin/"

  7. Démarrez votre nouvelle instance de base de données avec l'une des commandes suivantes : 

    # /usr/sbin/rcpostgresql start

    ou 

    # systemctl start postgresql.service

    (Selon la version SLE que vous utilisez comme version de départ pour la mise à niveau)

  8. Vérifiez si la migration a réussi. L'étendue du test dépend de votre utilisation ; il n'existe aucun outil général permettant d'automatiser cette étape.

  9. Supprimez les anciens paquetages PostgreSQL et votre ancien répertoire de données : 

    # zypper search -s postgresql12| xargs zypper rm -u
# rm -rf /var/lib/pgsql/data.old

Pour plus d'informations sur la mise à niveau des bases de données ou l'utilisation de méthodes alternatives telles que la réplication logique, reportez-vous à la documentation officielle de PostgreSQL à l'adresse https://www.postgresql.org/docs/13/upgrading.html.

3.8 Migration de votre base de données MySQL ou MariaDB

 

À partir de la version 12 de SUSE Linux Enterprise, SUSE est passé de MySQL à MariaDB. Avant de lancer une mise à niveau, il est vivement recommandé de sauvegarder votre base de données.

Pour effectuer la migration de la base de données, procédez comme suit :

  1. Créez un fichier de vidage : 

    # mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql

    Par défaut, mysqldump ne vide pas la base de données INFORMATION_SCHEMA ni performance_schema. Pour plus d'informations, reportez-vous à la page https://mariadb.com/kb/en/mariadb-dumpmysqldump/.

  2. Enregistrez votre fichier de vidage, le fichier de configuration /etc/my.cnf ainsi que le répertoire /etc/mysql/ pour consultation ultérieure (pas le répertoire d'installation) dans un endroit sûr.

  3. Effectuez la mise à niveau de SUSE Linux Enterprise Server. Après la mise à niveau, votre ancien fichier de configuration /etc/my.cnf sera inchangé. La nouvelle configuration est disponible dans le fichier /etc/my.cnf.rpmnew.

  4. Configurez votre base de données MariaDB selon vos besoins. N'utilisez pas les anciens répertoire et fichier de configuration. Vous pouvez toutefois les adapter et vous en servir ultérieurement comme références.

  5. Assurez-vous que vous démarrez le serveur MariaDB : 

    # systemctl start mariadb

    Si vous voulez lancer le serveur MariaDB à chaque démarrage, activez ce service : 

    # systemctl enable mariadb

  6. Vérifiez que MariaDB s'exécute correctement en vous connectant à la base de données : 

    # mariadb -u root -p

3.9 Création de certificats de serveur non-MD5 pour les applications Java

 

Par mesure de sécurité, les certificats MD5 ne sont plus pris en charge dans Java. Si vous disposez de certificats créés à l'aide de l'algorithme MD5, recréez vos certificats en procédant comme suit :

  1. Ouvrez un terminal et connectez-vous en tant qu'utilisateur root.

  2. Créez une clé privée : 

    # openssl genrsa -out server.key 1024

    Si vous souhaitez une clé renforcée, remplacez 1024 par un nombre plus élevé, par exemple 4096.

  3. Créez une requête de signature de certificat (CSR) : 

    # openssl req -new -key server.key -out server.csr

  4. Auto-signez le certificat : 

    # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

  5. Créez le fichier PEM : 

    # cat server.key server.crt > server.pem

  6. Placez les fichiers server.crt, server.csr, server.key et server.pem dans les répertoires respectifs contenant les clés. Pour Tomcat, il s'agit par exemple du répertoire /etc/tomcat/ssl/.

3.10 Arrêt des invités de machine virtuelle

 

Si votre machine fait office de serveur hôte de machine virtuelle pour KVM ou Xen, veillez à arrêter correctement tous les invités de machine virtuelle actifs avant de procéder à la mise à jour. Dans le cas contraire, l'accès aux invités peut s'avérer impossible après la mise à jour.

3.11 Ajustement de la configuration du client SMT

 

Si la machine que vous souhaitez mettre à niveau est enregistrée comme client auprès d'un serveur SMT, procédez comme suit :

Vérifiez si la version du script clientSetup4SMT.sh sur votre hôte est à jour. Le fichier clientSetup4SMT.sh des anciennes versions de SMT ne peut pas gérer les clients SMT 12. Si vous appliquez régulièrement des correctifs logiciels sur votre serveur SMT, vous pouvez toujours trouver la dernière version de clientSetup4SMT.sh dans <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

En cas d'échec de la mise à niveau de votre machine vers une version ultérieure de SUSE Linux Enterprise Server, annulez l'enregistrement de la machine auprès du serveur SMT, comme décrit à la Procédure 3.1. Ensuite, redémarrez le processus de mise à niveau.

Procédure 3.1 : annulation de l'enregistrement d'un client SUSE Linux Enterprise auprès d'un serveur SMT
 

  1. Connectez-vous à la machine client.

  2. L'étape suivante dépend du système d'exploitation actuel du client :

    • Pour SUSE Linux Enterprise 11, exécutez les commandes suivantes : 

      > sudo suse_register -E
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*
> sudo rm -f /var/cache/SuseRegister/*
> sudo rm -f /etc/suseRegister*
> sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
> sudo rm -f /etc/zmd/deviceid
> sudo rm -f /etc/zmd/secret

    • Pour SUSE Linux Enterprise 12, exécutez les commandes suivantes : 

      > sudo SUSEConnect --de-register
> sudo SUSEConnect --cleanup
> sudo rm -f /etc/SUSEConnect
> sudo rm -rf /etc/zypp/credentials.d/*
> sudo rm -rf /etc/zypp/repos.d/*
> sudo rm -f /etc/zypp/services.d/*

  3. Connectez-vous au serveur SMT.

  4. Vérifiez si l'enregistrement du client a été annulé avec succès en répertoriant tous les enregistrements de clients : 

    > sudo smt-list-registrations

  5. Si le nom d'hôte du client est toujours répertorié dans la sortie de cette commande, obtenez l'Unique ID du client à partir de la première colonne. (Le client peut être répertorié avec plusieurs ID.)

  6. Supprimez l'enregistrement pour ce client : 

    > sudo smt-delete-registration -g UNIQUE_ID

  7. Si le client est répertorié avec plusieurs ID, répétez l'étape ci-dessus pour chacun de ses ID uniques.

  8. Vérifiez si l'enregistrement du client a maintenant été annulé avec succès en réexécutant : 

    > sudo smt-list-registrations

3.12 Modifications des profils AutoYaST de SLE 12 vers SLE 15

 

Pour savoir comment migrer vos profils AutoYaST, reportez-vous au Appendix D, Differences between AutoYaST profiles in SLE 12 and 15.

3.13 Mise à niveau d'un serveur SMT (Subscription Management Tool)

 

Un serveur qui exécute SMT requiert une procédure de mise à niveau spéciale. Reportez-vous au Chapter 3, Migrate from SMT to RMT du Repository Mirroring Tool Guide (Guide de RMT).

3.14 Désactivation temporaire de la prise en charge de plusieurs versions du kernel

 

SUSE Linux Enterprise Server (SLES) permet d'installer plusieurs versions de kernel en activant les paramètres correspondants sous /etc/zypp/zypp.conf. La prise en charge de cette fonctionnalité doit pourtant être désactivée temporairement pour effectuer une mise à niveau vers un Service Pack. Une fois la mise à jour terminée, la prise en charge de plusieurs versions peut être réactivée. Pour désactiver la prise en charge de plusieurs versions, commentez les lignes correspondantes dans /etc/zypp/zypp.conf. Le résultat doit ressembler à ceci : 

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Pour réactiver cette fonction après une mise à jour réussie, supprimez les signes de commentaire. Pour plus d'informations sur la prise en charge de plusieurs versions, reportez-vous à la Section 27.1, “Enabling and configuring multiversion support”.

3.15 Ajustage du paramètre de démarrage resume

 

Sur les systèmes qui ont été installés avec SUSE Linux Enterprise Server 12 ou version antérieure, la ligne de commande du kernel par défaut dans /etc/default/grub peut contenir un paramètre resume utilisant un nom de noeud de périphérique, par exemple /dev/sda1, pour faire référence au périphérique d'hibernation (sauvegarde du contenu de la mémoire vive sur le disque dur). Étant donné que les noms de noeud de périphérique ne sont pas persistants et peuvent changer entre les redémarrages, il est vivement recommandé de corriger ce problème. Sinon, le système mis à niveau risque de se bloquer au redémarrage.

  1. Recherchez le périphérique d'hibernation : 

    > sudo grep resume /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"

    Le périphérique d'hibernation est /dev/sda1. Si la commande ne renvoie rien, l'hibernation n'est pas configurée.

  2. Obtenez l'UUID pour /dev/sda1 : 

    > sudo blkid /dev/vda1
/dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"

    L'UUID pour /dev/sda1 est a1d1f2e0-b0ee-4be2-83d5-78a98c585827.

  3. Modifiez le fichier /etc/default/grub et ajustez le paramètre resume. Remplacez /dev/sda1 par UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827. Le résultat ressemblera à ceci : 

    GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"

  4. Mettez à jour la configuration du gestionnaire d'amorçage GRUB : 

    > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Si le système n'utilise pas l'hibernation, vous pouvez simplement supprimer le paramètre resume et mettre à jour la configuration de démarrage.

3.16 Mise à niveau sur IBM Z

 

La mise à niveau d'une installation SUSE Linux Enterprise sur IBM Z nécessite Upgrade=1 comme paramètre de kernel, par exemple via le fichier parmfile. Reportez-vous à la Section 5.5, « Fichier parmfile - Automatisation de la configuration du système ».

3.17 IBM POWER : démarrage d'un serveur X

 

Sous SLES 12 pour IBM POWER, le gestionnaire d'affichage est configuré pour ne pas démarrer un serveur X local par défaut. Ce paramètre a été annulé sous SLES 12 SP1. Le gestionnaire d'affichage démarre désormais un serveur X.

Pour éviter des problèmes au cours de la mise à niveau, le paramètre SUSE Linux Enterprise Server n'est pas modifié automatiquement. Si vous souhaitez que le gestionnaire d'affichage démarre un serveur X après la mise à niveau, modifiez le paramètre DISPLAYMANAGER_STARTS_XSERVER dans /etc/sysconfig/displaymanager comme suit : 

DISPLAYMANAGER_STARTS_XSERVER="yes"