ASUS ROGVoici le deuxième article sur la migration d’un client gamer de Windows vers Linux. Dans mon précédent article je me suis intéressé à la mesure des performances d’une carte graphique. Aujourd’hui, nous allons attaquer le plat de résistance, à savoir l’installation d’OpenSUSE Leap 15.1 KDE sur le portable du client, en remplacement de Windows 10. La machine en question arbore fièrement son utilisation ludique, puisque c’est un Asus G553V Republic Of Gamers.

L’installation de Linux sur cette machine n’est pas une tâche triviale et m’a coûté pas mal d’expérimentation et de passages réitérés par la case tentative et échec jusqu’à ce que tout fonctionne bien. Une des raisons de ces tâtonnements, c’est que je n’ai trouvé aucune documentation cohérente, juste des bribes de tutos éparpillés un peu à droite et à gauche, et qui fournissent pas mal d’informations erronées au passage. Bref. Voici donc la synthèse des notes que j’ai prises.

BIOS / UEFI et démarrage

Pour rentrer dans le BIOS de la machine – ou dans l’UEFI pour être exact – il faut éteindre Windows, puis rallumer en spammant la touche F2. Le portable présente un UEFI moderne qui ressemble vaguement au panneau de contrôle d’un Boeing ou d’une centrale nucléaire, et c’est en vain que l’on cherchera une option du genre Legacy Boot. Quoi qu’il en soit, je restaure les options par défaut en appuyant sur la touche F9 (Load Optimized Defaults).

J’insère la clé d’installation d’OpenSUSE, je redémarre en appuyant successivement sur F2 et sur F8, et le menu de démarrage me présente deux options.

  • Windows Boot Manager
  • UEFI: USB DISK 2.0 PMAP

À l’invite de l’installateur, j’opte pour le système de secours (Rescue System) dans un premier temps, histoire de voir ce que la machine a dans le ventre. Cette première tentative se solde par un gel intégral du système, dont je me sors en appuyant sur le bouton On/Off.

Les options de kernel

Je vous fais grâce du détail de mes recherches et de toutes mes tentatives infructueuses. Dans ce cas, le fauteur de troubles est le pilote libre nouveau, qu’il faut impérativement désactiver via l’option de kernel nouveau.modeset=0. Concrètement, lorsque l’entrée de menu Rescue System est en surbrillance, il faut appuyer sur la touche E pour éditer l’entrée (Edit Entry), repérer la ligne correspondant au noyau dans le menu de GRUB et ajouter l’option qui convient.

linuxefi /boot/x86_64/loader/linux splash=silent rescue=1 nouveau.modeset=0

Ensuite, appuyer sur CtrlX pour démarrer.

Remarque importante : un grand nombre de tutos sur Internet conseillent de démarrer avec l’option nomodeset tout court, ce qui est une aberration. Le pilote Intel fonctionne également en mode KMS (Kernel Mode Setting) et ne pourra pas se charger avec cette option.

Réinitialisation initiale des disques

La machine est dotée de deux disques durs.

  • un disque SSD /dev/sda de 250 Go
  • un disque SATA /dev/sdb de 1 To

J’envoie Windows au paradis des octets en supprimant toutes les partitions existantes.

# sgdisk --zap-all /dev/sda
# sgdisk --zap-all /dev/sdb

Démarrage de l’installation

Je redémarre sur la clé, et cette fois-ci, j’opte pour l’entrée de menu Installation. Là aussi, je dois ajouter l’option nouveau.modeset=0 à la ligne concernant le kernel pour éviter le gel du système au démarrage. On notera au passage que l’installateur d’OpenSUSE est plutôt bien fichu, étant donné que cette option sera conservée dans l’installation et que je n’aurai plus à m’en soucier.

Je ne rentre pas dans les détails de l’installation d’OpenSUSE Leap 15.1, puisque j’ai déjà publié un article sur ce sujet. Je relèverai uniquement les particularités, et on va commencer par le partitionnement.

Partitionnement personnalisé

J’opte pour le schéma de partitionnement suivant.

  • une partition /boot/efi de 500 Mo
  • une partition /boot de 500 Mo et formatée en ext2
  • une partition principale occupant le maximum d’espace disponible sur le disque et formatée en ext4
  • une partition d’échange dont la taille est égale à la quantité de RAM de la machine, en l’occurrence 8 Go
  • le disque /dev/sdb sera formaté et intégré manuellement après l’installation.

On notera au passage que j’aurais pu réduire la taille des partitions EFI et /boot. J’ai opté pour 500 Mo respectivement pour répondre aux exigences un peu larges de l’installateur OpenSUSE.
Dans le menu de l’installateur, j’opte pour le Partitionnement en mode expert > Démarrer avec les partitions existantes.

Voici une petite vue d’ensemble de toutes les étapes par lesquelles il faut passer pour créer les différentes partitions.

  1. Créer une table de partitions sur le disque /dev/sda en allant dans Table de partitions > Créer une nouvelle table de partitions > GPT.
  2. Partition EFI : Onglet Partitions > Ajouter une partition > Taille personnalisée : 500 MiB > Rôle : Partition de démarrage EFI > Système de fichiers : FAT > Point de montage : /boot/efi.
  3. Partition /boot : Ajouter une partition > Taille personnalisée : 500 MiB > Rôle : Système d’exploitation > Système de fichiers : ext2 > Point de montage : /boot.
  4. Partition principale : Ajouter une partition > Taille personnalisée : passer de 237.49 GiB à 229.49 GiB pour laisser 8 GiB de place à la fin du disque pour la partition d’échange > Rôle : Système d’exploitation > Système de fichiers : ext4 > Point de montage : /.
  5. Partition d’échange : Ajouter une partition > Taille maximale 8 GiB > Rôle : Swap > Système de fichiers : Swap > Point de montage : swap
  6. Créer une table de partitions sur le disque /dev/sdb en allant dans Table de partitions > Créer une nouvelle table de partitions > GPT.
  7. Onglet Partitions > Ajouter une partition > Taille maximale (0.9 TiB) > Données et applications tierces > Système de fichiers : ext4 > Ne pas monter le périphérique.

Voilà à quoi cela ressemble une fois que le système est installé.

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238,5G  0 disk 
├─sda1   8:1    0   500M  0 part /boot/efi
├─sda2   8:2    0   500M  0 part /boot
├─sda3   8:3    0 229,5G  0 part /
└─sda4   8:4    0     8G  0 part [SWAP]
sdb      8:16   0 931,5G  0 disk 
└─sdb1   8:17   0 931,5G  0 part 
sr0     11:0    1  1024M  0 rom

Paramètres de l’installation

Une fois que le partitionnement est terminé, l’installateur m’affiche les paramètres d’installation. Ici, je modifie deux choses.

  • Les CPU Mitigations ont un sens sur un serveur avec une ouverture frontale sur Internet. En contrepartie, sur un portable de gamer, je vais juste avoir une perte de performances. Je passe donc de Auto à Off.
  • J’active le serveur SSH, qui est désactivé dans la configuration par défaut.

Il ne me reste plus qu’à lancer l’installation.

Redémarrage initial

Après le redémarrage initial, je passe à la configuration post-installation de la machine. La procédure est abordée en détail dans cet article.

Configuration de la carte vidéo hybride

La machine est dotée d’une carte vidéo hybride Intel/NVidia.

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04)
# lspci | grep 3D
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)

Dans la configuration par défaut, c’est le pilote Intel qui est utilisé en mode KMS (Kernel Mode Setting). Pour une utilisation au quotidien comme surfer sur le web ou faire de la bureautique, les performances de ce pilote sont largement suffisantes. En revanche, pour des jeux en 3D, on sera vite déçu. Lorsqu’on lance un des benchmark tests d’Unigine, on constate qu’on plafonne à moins de dix FPS, avec un affichage saccadé des séquences. On va donc essayer de profiter de la carte NVidia intégrée.

Pour commencer, il faut installer le pilote propriétaire. J’ai déjà détaillé cette procédure dans un autre article. En résumé, il suffit de configurer le dépôt tiers NVidia et d’installer le pilote qui va bien. En passant, je vous conseille également de configurer et d’activer le dépôt tiers KDE:Extra, qui nous fournira une applet fort pratique.

# zypper install x11-video-nvidiaG05

Il existe toute une série de techniques pour tirer profit d’une carte vidéo hybride. Je ne vais pas rentrer dans les détails fastidieux. Au lieu de cela, je vais me contenter de décrire la procédure qui fonctionne le mieux, c’est SUSE Prime.

Dans un premier temps, je veux savoir quelle est la carte vidéo actuellement utilisée. Voici ce que je peux faire.

# xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x44; cap: 0xf (Source Output, Sink Output, Source Offload, Sink Offload); 
crtcs: 3; outputs: 2; associated providers: 0; name: modesetting
    output eDP-1
    output HDMI-1
# glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 630 (Kaby Lake GT2)

Si vous ne trouvez pas la commande glxinfo, elle est fournie par le paquet Mesa-demo-x.

La commande prime-select fournie par le paquet suse-prime me permet de basculer vers le pilote NVidia.

# prime-select nvidia
Driver configured: nvidia

Je me reconnecte à ma session, et voici ce que j’obtiens.

# xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x23e; cap: 0x1 (Source Output); crtcs: 0; outputs: 0; 
associated providers: 1; name: NVIDIA-0
Provider 1: id: 0x44; cap: 0xf (Source Output, Sink Output, Source Offload, Sink Offload); 
crtcs: 3; outputs: 2; associated providers: 1; name: modesetting
    output eDP-1-1
    output HDMI-1-1
# glxinfo | grep "OpenGL renderer string"
OpenGL renderer string: GeForce GTX 1050/PCIe/SSE2

SUSE Prime Selector

Je pourrais très bien revenir au pilote Intel en invoquant prime-select intel, mais il existe une solution plus confortable que la ligne de commande. Vérifiez si l’applet plasma5-applet-suse-prime est installée.

# rpm -qa | grep prime
suse-prime-0.5-lp151.3.3.1.noarch
plasma5-applet-suse-prime-1.1-lp151.3.1.noarch

Ajoutez l’applet SUSE Prime Selector au tableau de bord.

SUSE Prime

L’applet indique le pilote actuellement utilisé et permet de basculer vers l’autre pilote.

SUSE Prime

Cette fonctionnalité mérite deux remarques.

  • Elle requiert les droits de l’administrateur.
  • Ce n’est pas strictement nécessaire de redémarrer la machine. Il suffit de se reconnecter à sa session.

Tester les performances de la carte vidéo

J’active le pilote NVidia et je lance une première série de tests de performances avec GL Mark 2.

GL Mark 2

À l’issue des tests, GL Mark 2 attribue un score de 9509 à ma machine, ce qui est plus que satisfaisant. En comparaison, ma station de travail dotée d’une modeste carte NVidia GeForce GT710 se situe aux alentours des 1500, et mon MacBook Pro tournant sous OpenSUSE plafonne à moins de 500.

Pour finir en beauté, je télécharge les benchmarks Unigine, et comme il faut s’y attendre, l’affichage des animations 3D est d’une fluidité parfaite. On est donc bien partis pour installer des jeux sophistiqués sur cette machine grâce au moteur Steam. Ce qui fera l’objet de notre prochain article.

Unigine Benchmark Valley


La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.

 


9 commentaires

Sleipnir · 29 octobre 2019 à 10 h 25 min

J’essaye de faire la même chose en dual-boot sur un pc identique avec CentOS 8. Cet article va me faire avancer.

    kikinovak · 29 octobre 2019 à 10 h 54 min

    À mon humble avis (pas si humble que cela), CentOS n’est pas fait pour les postes de travail. C’est fait pour tourner en multi-user.target sur les serveurs, et puis c’est tout. Je connais CentOS depuis les versions 4.x, j’ai publié deux ouvrages détaillés sur cette distrib chez Eyrolles, là je rédige le troisième, mais pour les postes de travail, de grâce, utilisez OpenSUSE. CentOS tourne sur les postes de travail dans la mesure où une poule est capable de voler et un cheval de nager. :o)

      Sleipnir · 29 octobre 2019 à 11 h 37 min

      Ok mais pour le moment je souhaite juste découvrir Centos et je n’ai que ce pc gamer de disponible. OpenSUSE n’a pas une durée de vie assez longue pour un poste utilisateur.

        kikinovak · 29 octobre 2019 à 11 h 44 min

        Le principe de Leap (« saut ») c’est d’offrir une base stable (basée sur SLES) et une couche applicative récente. Une fois par an, on effectue un saut de version mineur, ce qui est une opération triviale. On a donc l’avantage de la stabilité entreprise avec les fonctionnalités d’une rolling release. Dans notre lycée local, ça tourne sur près de vingt-cinq machines, sans le moindre pépin. Avant, on utilisait CentOS partout, maintenant ça ne tourne plus que sur les serveurs. (Conseil pour découvrir une distrib: Vagrant)

        david · 29 octobre 2019 à 11 h 58 min

        je suis d’accord OpenSuSE leap à une durée de vie un peu courte,1.5 ans pour entre la sortie d’une version et sa fin de vie.
        Il est possible de migrer d’une version à la suivante, mais c’est un peu compliqué. Il manque à zypper une commande pour le faire simplement. (il me semble avoir lu, que c’est en préparation 😉 )
        enfin, il y a openSuSE Tumbleweed, que j’utilise. elle n’a pas vraiment de monté en version comme sur leap, mais en une commande zypper dup, elle fait tout les mis à jours. (et elle fonctionne bien)

david · 29 octobre 2019 à 11 h 36 min

cool, l’article, plutôt bien fait.

quelle petit remarque :
1) nouveau.modeset=0 tu le supprime ou pas des options de boot? (perso j’utilise nomodeset que je supprime à l’installation, mais je reconnais que ta méthode est meilleur)
2) tu ajoute les options acpi_osi=! acpi_osi= »Windows 2009″, il existe plusieurs version, je ne sais pas si sa sert vraiment.
3) pour installer le drivers nvidia, tu n’a pas besoin de spécifier « zypper install x11-video-nvidiaG05 » tu peu lancer « zypper inr » (équivalemment à zypper install-new-recommends)
Zypper inr dectete tout les drivers et les paquets que zypper pense qui manque. il m’a recommandé par example l’applet suse-prime. quand il était disponible.

David

    kikinovak · 29 octobre 2019 à 11 h 49 min

    L’option nouveau.modeset=0 fournie est persistante, c’est expliqué dans l’article. Je pense que dans les tutos les gens ajoutent des options de boot de façon voodoo, sans trop savoir ce que ça signifie. Ici, je n’ai ajouté qu’une seule option pour désactiver le chargement d’un module qui provoque un gel du système. À part ça, je préfère faire les choses à la main. C’est probablement parce que j’ai bossé quinze ans sous Slackware, et y’avait pas d’assistants automatiques. :o)

Boudaud Benoît · 31 octobre 2019 à 9 h 00 min

Bonjour,

Ils sont intéressants ces deux articles. Moi-même, je ne joue pas mais j’ai bien envie de m’y mettre un peu, plutôt que de me fatiguer à écrire des articles.

J’aurais deux questions: Tu formates la partition /boot en ext2 et dans l’article ci-dessous, un commentateur m’avait fait la remarque que le format ext2 était déprécié. On pouvait formater en ext4, ce que j’ai fait d’ailleurs (par souci de simplicité). Quel est ton avis sur ce point?
https://miamondo.org/2019/07/23/la-planete-archlinux-partie-3/

2ème question : J’ai essayé le Benchmark valley. Ça fonctionne. Par contre, superposition, c’est trop pour ma carte graphique. Elle a tout vomi. Du coup, j’aurais aimé savoir si la carte NVIDIA GEFORCE GT710 me permettrait d’étalonner (benchmarker) superposition ou bien si celle-ci est encore trop modeste.
Merci et bonne journée,
Benoît

    kikinovak · 31 octobre 2019 à 10 h 44 min

    En gros, l’ext4 c’est l’ext2 avec la journalisation. Je n’utilise pas la journalisation sur la partition /boot, c’est tout. Après, rien n’empêche d’utiliser ext4 ou même de ne pas séparer la partition /boot.

    J’ai moi-même une NVidia GT710 sur ma station de travail. Les performances sont plutôt modestes, mais ça permet par exemple d’installer un jeu comme War Thunder sans avoir un affichage trop saccadé.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.