1
Installation et boot / Quelques aventures avec l'installation de Leap16 : SELinux
Episode 1
Après avoir lu des récits d'installation de Leap16 qui se sont terminés par une absence de login graphique et par une simple console texte, j'ai voulu tester avec des précautions.
J'ai donc installé Leap16 sur ma machine, mais sur un disque additionnel, un hdd en sata qui était disponible, afin de ne pas écraser la Leap 15 opérationnelle sur mon SSD-NVMe.
Je ne l'ai pas regretté car voici le résultat.
Tout d'abord, un serveur X s'est bien installé, avec le login KDE. Sauf que, j'ai une carte graphique RTX4080 avec deux écrans, en mode étendu. A première vue, tout semblait bon puisque je pouvais passer ma souris d'un écran à l'autre.
Et c'est alors que j'ai lancé la "Configuration du système". Apparaît alors la fenêtre du paramètrage rapide, avec le menu à gauche.
Et là, surprise : le pointeur de souris est sans effet sur les icônes du menu.
Et maintenant le gag : j'avais la fenêtre du paramètrage sur un écran, et le curseur de souris sur l'autre écran. Et je parvenais à cliquer sur le menu de l'écran à gauche en déplaçant le pointeur de souris sur l'écran à droite !
Pas pratique du tout !!
Mais ça m'a permis d'aller dans "affichage et écran" et de supprimer l'extension d'affichage d'un écran sur l'autre. L'écran droit est devenu duplication du gauche et le pointeur de souris est revenu pointer sur les fenêtres comme au bon vieux temps.
J'ai voulu alors utiliser cockpit pour configurer le chargeur d'amorçage. O surprise, le cockpit installé par l'install de Leap16 ne possède pas le chargeur d'amorçage !
Il faut le rajouter à la main. Voir pour ça :
archives
Ceci fait bien apparaître le chargeur d'amorçage dans le menu de cockpit.
Pour les imprimantes, au bon vieux temps (désolé je suis un vieux !), yast servait à les configurer.
J'ai cherché dans cockpit et j'ai pas trouvé.
Pas trouvé non plus d'extension cockpit.
J'ai ressorti la vieille méthode //localhost:631/ qui fait apparaître OpenPrinting CUPS 2.4.11
Dans mon cas, ça a marché, pour installer une imprimante locale USB et une en réseau Wifi.
Y-aurait-il une autre méthode dans Leap 16 ?
Restent les pilotes Nvidia.
L'install Leap16 avait installé le pilote "Nouveau", mais j'ai voulu quand même des pilotes nvidia, surtout après mon expérience de souris.
Après une semaine de galère, ça a fini par marcher ! J'ai les pilotes Nvidia et le panneau de contrôle Nvidia.
Mais je ne peux pas vous décrire la solution car j'ai fait tellement d'essais, qui ont chargé plusieurs versions de pilotes, versions qui se sont mélangées, qui ont bloqué le serveur X, qui ont généré des modules de noyaux de versions concurrentes, que c'est impossible à décrire. Je suppose que c'est la dernière manip qui a marché, mais je ne sais si elle se suffit à elle-même ou si d'autres précédentes sont nécessaires.
Episode 2
Voici quelques nouvelles.
J'ai refait une installation avec une Leap16 réseau online-installer au lieu de offline-installer comme la première fois.
Je n'ai pas eu de problèmes de séparation de souris et d'écran. Comme quoi, avec des pilotes à jour, ça va mieux.
Nota : le dépôt pour le gestionnaire d'amorçage de cockpit est : (Précédemment, je vous avais donné un lien Tumbleweed)
cockpit
Je précise que j'ai fait une install avec le /home déclaré sous-volume de la partition du / en btrfs.
Il se trouve que j'ai l'habitude d'avoir les données du /home sur une partition séparée, une vraie partition en xfs.
Comme à chaque nouvelle version de Leap, et depuis des années avec les openSUSE, je procède ainsi :
- install avec le /home dans la partition / en btrfs
- démontage du /home
- remontage du /home sur la partition xfs
Et ça marchait : les données des utilisateurs et leurs profils étaient opérationnels
Ici, avec la Leap16, je créé l'utilisateur lambda (user 1000) avec le /home en sous-volume : ça donne /home/lambda
Je copie le contenu de /home/lambda dans le /home en xfs.
Je monte le /home en xfs.
Je reboote.
Le login graphique arrive, et je me connecte avec le user lambda.
Et là : refus de connexion !
Je passe en console pour tenter la connexion. résultat :
Code: [Sélectionner]
-- lambda : /home/lambda: change directory failed : Permission denied
Code: [Sélectionner]
Logging in with home = « / ».
Et pourtant cd /home/lambda fonctionne.
Et même startx fait démarrer KDE !
La vérification des droits des dossiers (drwxrwxrwx dans tous les sens) ne donne rien : toujours pas de connexion !
Jusqu'à ce que je trouve : SELinux
Un bon tuto est à :
selinux
C'est bien ce qui coince, car si je tape pour désactiver SELinux :
Code: [Sélectionner]
# setenforce 0Le login graphique de lambda fonctionne !
Vu que SELinux est une surcouche de sécurité, et vus les déboires actuels de la cyber-sécurité, il est préférable de ne pas désactiver SELinux.
Je teste donc le contexte de /home---
La commande :
Code: [Sélectionner]
# ls -dZ /homedonne :
Code: [Sélectionner]
? /homeCe qui signifie que /home n'a pas de contexte.
Comment trouver une valeur qui marche ?
Il faut pour cela remettre le /home comme sous-volume de la partition du / en btrfs, puisque ça fonctionnait bien.
Et là, la commande
Code: [Sélectionner]
# ls -dZ /homedonne :
Code: [Sélectionner]
system_u:object_r:home_root_t:s0 /home
Le contexte à attribuer au /home monté en xfs est donc home_root_t
On se remet en home sur xfs
Et la commande pour créer le contexte est :
Code: [Sélectionner]
# semanage fcontext -a -t home_root_t "/home(/.*)?"
Et pour l'appliquer de manière permanente :
Code: [Sélectionner]
# restorecon -Rv /home
Vérification :
Code: [Sélectionner]
# ls -dZ /homequi donne :
Code: [Sélectionner]
system_u:object_r:home_root_t:s0 /home
Réactiver SELinux :
Code: [Sélectionner]
# setenforce 1
Et ça marche, même après un reboot.
Il semble que Leap16 a fait entrer SELinux dans Leap. Va falloir s'y habituer. Pour ma part, je viens de faire sa connaissance.
Va falloir y penser quand il y aura des messages "Permission denied" alors que les droits classiques (ceux de notre jeunesse) semblent bons.
A+
wallace