GuiGui's Show

On fait appel à moi pour réparer un système GNU/Linux.

Linux Mint 21.2. Gros affichage (en réalité, 800x600), plus de réseau WiFi, plus d'imprimante USB, et plus de son. A priori, suite à une mise à jour. Étrange car la plus récente version majeure de Mint (22.1) n'est pas installée, donc c'était une màj mineure, donc peu probable qu'elle ait tout cassé.

Puisque màj, je me dis qu'elle a peut-être été interrompue, mais apt install -f me dément.

Je me dis que, puisque tout est cassé, autant mettre à jour en Mint 22.1. Ça ne change rien.

Pour le WiFi, lspci n'affiche aucun pilote en cours d'utilisation. Ha, idem pour le réseau filaire (qui est donc HS). Je passe sur un liveUSB Mint. Là, tout fonctionne (affichage, WiFi et filaire, imprimante, son). J'utilise apt-file pour identifier dans quels paquets sont les pilotes affichés par lspci pour le réseau (WiFi et filaire) : linux-modules-extra-<version_noyau>. Je chroot dans le Mint installé, j'installe le paquet, je redémarre : WiFi et filaire OK.

Origine de ce problème ? Aucune idée. Sur le forum web de Mint, on trouve l'idée que, lors d'une mise à jour, le paquet linux-modules-extra-<version_noyau> correspondant au noyau qui sera installé, est installé, par dépendance, par le paquet linux-image-generic, sauf s'il est manquant. Dans mon cas, il était présent, donc ce n'est pas la bonne explication. Je n'en ai pas d'autre.

Concernant l'affichage, la disponibilité de la seule définition 800x600 indique que c'est le pilote ultra-minimaliste qui est en action. Pourtant, le pilote officiel de Nvidia est installé. La carte graphique, une Geforce GT 545, est prise en charge jusqu'à la version 390 du pilote officiel (pour savoir quelle version du pilote convient à telle carte graphique, il suffit de faire semblant de télécharger le pilote depuis le site de Nvidia). Mint 22.1 livre la version 6.8 de Linux. Or, la version 390 du pilote officiel Nvidia est incompatible avec Linux 6.

J'avais constaté que le liveUSB Mint 22.1 utilise le pilote libre nouveau. J'ai donc désinstallé xserver-xorg-video-nvidia-390, nvidia-driver-390, nvidia-utils-390, nvidia-settings, etc. Mais toujours rien après redémarrage. lspci affiche deux pilotes potentiels (dont aucun en cours d'utilisation) : nvidiafb et nouveau. J'en déduis que nvidiafb entre en conflit. apt-file search le trouve dans aucun paquet donc j'empêche son chargement dans le noyau. Après redémarrage, nouveau a pris la main et l'affichage est impec.

Là encore, aucune idée de l'origine du problème (Linux Mint 21.2 a un noyau 5.15, donc le pilote Nvidia officiel aurait dû fonctionner avant ma mise à jour vers 22.1 avec Linux 6.8).

Le son et l'imprimante fonctionnent sans intervention de ma part.

Je remarque que le gestionnaire Bluetooth, Thunderbird et un autre logiciel s'ouvrent automatiquement à l'ouverture de session. L'utilisatrice me dit qu'elle a jamais voulu ça. Je fais le ménage depuis le Menu, Préférences, Applications au démarrage.

Linux Mint est installé à côté de Windows 10 (dual boot). Tout porte à croire que winwin fonctionnait avant mon intervention puisque, le Mint étant cassé depuis des semaines, l'utilisatrice l'utilisait en secours. Après mon intervention, il ne démarre plus. Quelle que soit l'entrée choisie dans le menu de démarrage de l'EFI, ça démarrage Linux. Je ne vois pas comment j'aurais pu casser quelque chose avec le peu de commandes que j'ai utilisé… Erreur de ma part : ne pas avoir collecté plus d'informations avant de travailler (constater que winwin démarre, avec quelle entrée du menu EFI, etc.).

Chaque système est installé sur un disque dur dédié. Même si je débranche le disque Linux, l'EFI lance GRUB qui se plaint qu'il ne trouve pas le disque avec tel UUID (le disque Linux, donc). L'utilisatrice me dit que winwin démarrait automatiquement et qu'elle utilisait F9 (menu de démarrage) pour démarrer Mint (je l'ai vu faire) en sélectionnant « SATA 0 ». Donc winwin 10 serait en mode legacy / MBR (sinon il faudrait sélectionner Windows Boot Manager dans les sources EFI, mais il n'y figure pas) ? Étrange. Sur le disque dur dédié à winwin, il y a une partition qui a le drapeau boot et qui contient « bootmgr.exe », « bootnxt », « bootsect.bak », l'arborescence « Boot/BCD », etc. Une autre partition contient aussi « bootmgr.exe » et des documents de l'utilisatrice (parce que pourquoi pas ?). La partition système contient « bootnxt » et un dossier « Boot » vide. Le disque winwin a une table des partition au format MBR, celle du disque dur dédié à Linux est au format GPT. Seul le disque Linux a une partition EFI (aka ESP), mais elle ne contient pas l'arborescence « EFI/Microsoft/Boot » (et donc pas « bootmgfw.efi », « BCD », etc.). La commande efibootmgr affiche aucune entrée propre à Windows. J'ai essayé de forcer le prochain démarrage (efibootmgr -n <numéro_entrée>) sur la ligne louche la plus probable (« BBS USB »), sans succès. Bref, c'est le foutoir, et j'hésite entre un winwin MBR ou EFI. Seules certitudes : la commande os-prober ne détecte pas winwin, et le menu GRUB était désactivé (« GRUB_TIMEOUT_STYLE=hidden » dans /etc/default/grub) donc l'utilisateur choisisait son système depuis le menu de démarrage de l'EFI.

Je débranche le disque dur Mint de l'ordinateur, je démarre sur une clé USB d'installation de winwin 10. Je teste l'outil de réparation du démarrage. Évidemment, il ne parvient pas à corriger quoi que ce soit. J'utilise bootrec /fixmbr : l'ordi démarre toujours sur le GRUB présent sur le disque dur alors que je m'attendais à une réécriture du MBR avec le gestionnaire de démarrage de winwin. bootrec /fixboot termine en « Accès refusé ». D'après plusieurs sources sur le web, c'est le cas depuis la version 1709 de winwin 10 donc depuis 2017. Je peine à croire à un dysfonctionnement, je pense que c'est voulu par Microsoft. Reste à comprendre pourquoi, et pourquoi sa documentation n'est pas à jour. Consolation : bootrec /ScanOS détecte winwin sur la bonne partition.

Je tente de chaîner l'amorceur winwin à GRUB en pointant sur le début de chaque partition du disque winwin (directive chainloader +1 de GRUB après avoir défini la racine) : échec (« Invalid EFI file path »). Je tente de pointer sur les binaires bootmgr que j'ai identifié dans plusieurs partitions du disque winwin (directive GRUB : ntldr /bootmgr) : échec (« ntldr: command not found »). C'était voué à l'échec : GRUB ne permet pas de chaîner du non-EFI quand il est lancé en mode EFI, et inversement, et c'est logique (source 1, source 2). Mais sur un malentendu…

Depuis l'invite de commande d'une clé d'installation winwin 10, je me décide à faire ce que je ne voulais pas : reconstruire l'arborscence Microsoft sur la partition EFI (du disque Linux, donc). Je ne le voulais pas car ça signifie que les deux systèmes, Mint et winwin, ne sont plus véritablement indépendants : sans le disque dur Linux, winwin ne peut pas démarrer… Pour ce faire, j'ai adapté ce tuto : cd /d M:\EFI ; mkdir Microsoft\Boot ; cd Microsoft\Boot ; bcdboot C:\Windows /l fr-fr. Au redémarrage, le menu de démarrage de l'EFI présente une nouvelle entrée dans la rubrique « Sources de démarrage EFI » : « Windows Boot Manager ». Winwin démarre.

Depuis le Mint installé, os-prober détecte désormais winwin (et l'ajoute au menu GRUB lors d'un update-grub, sous réserve qu'il soit configuré pour le faire (« GRUB_DISABLE_OS_PROBER=false » dans /etc/default/grub.

Winwin étant une espèce invasive, dès qu'on démarre sur lui, ce n'est plus GRUB qui a la main lors des redémarrages successifs. J'ai désactivé le démarrage rapide de winwin (fast startup), sans succès. J'ai pas creusé plus loin. J'ai même oublié de vérifier l'ordre de démarrage dans l'EFI (en tout cas, dans le menu de démarrage du même EFI, winwin occupe la première place devant Mint). Pas grave, l'utilisatrice a l'habitude de démarrer Mint avec F9 (menu de démarrage EFI), j'ai remis comme c'était, aucun poids sur ma conscience.

Là encore, aucune idée sur l'origine du problème. Lors de la mise à jour vers Mint 22.1, y a-t-il eu un grub-install automatique qui a détruit l'amorceur winwin sur le disque dur dédié winwin ? Un update-grub qui a changé la config du GRUB du disque Linux (vers lequel pointe le MBR du disque winwin) ? Un effacement de l'arborescence Microsoft sur la partition EFI ? Tout cela paraît improbable.

L'utilisatrice me dit qu'il n'y a plus de son sous winwin. Forcément, quand on branche les haut-parleurs sur le port microphone de l'ordi… Mais Linux fait avec. :D J'avais déjà vu ça.