Retour d’expérience d’un dual boot debian W10 en RAID ON ?

Support Debian
#102

Je n’ai aucun argument technique concret allant dans ce sens, seulement des soupçons. Les caractères non ASCII peuvent être encodés de différentes manières selon le jeu de caractères utilisé et j’ignore comment c’est géré par le système d’authentification de Debian mais j’ai déjà eu des problèmes avec d’autres systèmes et applications.

Copie-le aussi dans /boot/grub, c’est l’autre emplacement où GRUB est susceptible d’aller le chercher si la variable $config_directory n’est pas définie. Comme tu as réinstallé, peux-tu revérifier cette variable (“c” puis “set” au menu de GRUB) ? Peux-tu aussi poster le contenu de la section “41_custom” située à la fin du fichier /boot/grub/grub.cfg ?

#103

La copie de custom.cfg dans /boot/grub a marché. W10 est maintenant proposé par grub.
Il faut maintenant régler le problème des GPU. L’autre topic ouvert est en train de bien grossir. Je n’aurais pas cru que cela serait si complexe pour un non connaisseur des systèmes.
Bien cordialement
gerod

#104

Autre problème : en choisissant W10 pour démarrer j’ai eu le message disque (hd0,gpt2) non disponible. Les deux fois précédentes avec ce choix W10 il n’y avait pas eu de problème.
J’ai choisi set up et ai mis Boot manager en premier dans la liste ce qui m’a permis de démarrer W.

Je suppose que ce n’est pas normal.
Bien cordialement
gerod

#105

Tu veux dire que l’entrée de menu a fonctionné les deux premières fois et pas la suivante ? La numérotation des disques a peut-être été intervertie. En mode BIOS (hd0) est toujours le disque de boot mais en mode EFI ce n’est pas forcément le cas, je ne sais pas de quoi dépend la numérotation des disques et si elle peut changer d’un démarrage à l’autre comme dans Linux. C’est pourquoi j’avais recommandé de récupérer l’UUID de la partition EFI du SSD afin de l’utiliser pour identifier la partition au lieu de mettre le numéro de disque en dur. Pour rappel, pour récupérer l’UUID tu peux exécuter cette commande dans le shell de GRUB (touche “c” à l’affichage du menu) :

probe --fs-uuid (hd0,gpt2)

si le SSD est hd0. Si c’est hd1, il faudra exécuter

probe --fs-uuid (hd1,gpt2)

L’UUID recherché est de la forme XXXX-XXXX et est différent de celui de la partition EFI du disque dur que tu peux voir dans Debian avec blkid.

#106

Bonjour,
Le problème est que maintenant grub n’apparaît plus : pour avoir W je vais dans le BIOS et met boot manager en premier et pour avoir debian je met debian en premier et cela démarre sans passer par la case grub. Il ne m’est donc pas possible pour le moment de faire les vérifications requises.

Autre question : j’ai remarqué que le sed sur sources.list ayant pour but de mettre en commentaire la ligne commencant par deb cdrom avait effectivement bien marché mais il y avait encore cette même ligne non commentée (en fait il y a deux lignes commencant avec deb cdrom : une commentée et l’autre pas).

Sous root j’ai donc fait un chmod u+rw /etc/apt/sources.list en pensant pouvoir supprimer cette ligne sous l’éditeur (la seule chose qui marche à peu près dans mon environnement). Cela n’est pas possible car le fichier est toujours en lecture seule. Peut être aurait il fallu faire chmod -R u+rw /etc/apt/sources.list ?

Je sens que je vais expérimenter tous les problèmes possibles et imaginables.
Bien cordialement

#107

Tu veux dire “Windows Boot Manager” ?

C’est étonnant. Je ne vois que quatre explications possibles à cela :

  • GRUB se lance mais est configuré pour ne pas afficher de menu spontanément et démarrer automatiquement l’entrée de menu par défaut (menu caché). Eventuellement un délai est configuré pour attendre une frappe clavier qui affiche le menu avant de démarrer automatiquement (je ne me souviens jamais si c’est Esc, shift, control, espace…). C’est ce que fait Ubuntu par défaut quand il n’y a pas de multiboot.
  • GRUB se lance mais son fichier de configuration a été modifié pour démarrer directement le système, sans menu caché ni délai.
  • Le firmware UEFI lance directement le noyau Linux grâce à une fonctionnalité du noyau appelée “EFI stub” au lieu de lancer GRUB.
  • GRUB a été remplacé par un autre chargeur d’amorçage qui n’affiche pas de menu.

Mais à ma connaissance la mise en place de toutes ces configurations avec Debian nécessite une action manuelle de l’utilisateur. Dans Debian, tu peux afficher les entrées de boot EFI pour voir ce qui est enregistré dans l’entrée “debian”, avec la commande suivante :

efibootmgr -v

Une autre hypothèse serait qu’une erreur dans le contenu du fichier custom.cfg empêche GRUB d’afficher le menu. Je n’ai jamais pensé à tester comment GRUB se comporte dans ce cas, s’il affiche le menu jusqu’à l’erreur, n’affiche rien mais lance l’entrée par défaut ou affiche son invite de commande grub>.

#108

Ce n’est pas une bonne idée de changer les droits du fichier pour pouvoir l’éditer.
Tu te connectes en root ou bien tu lances avec sudo, et tu utilises nano pour ton édition rapide en ligne de commande.

Là, c’est surement qu’il est trop rapide pour que tu le voies, mais normalement, en tapotant les flêches pendant le boot, tu devrais tomber sur le menu grub.
Sinon, tu peux aussi rallonger le délai de grub dans /etc/default/grub (je ne sais plus quel paramètre, RTFM), puis sudo update-grub avant de rebooter.

#109

GRUB_TIMEOUT, dont la valeur par défaut doit être de 5 ou 6 secondes.

#110

La commande efibootmgr a donné:

Boot order: 0000,0001,0003,0006,0005
Boot0000 Windows boot manager HD(2,GPT,.......
Boot0001 debian HD(3,GPT,.....
Boot0003 Onboard NIC (IPV4)
Boot0004 Onboard NIC (IPV6)
Boot0005 Network
Boot0006 USB Storage device

Je ne comprend pas ce que fait le disque dur externe en Boot0006 car il n’est pas bootable (sauf qu’il contient Oracle VM pour mon essai de debian 10 en machine virtuelle sou W)

Concernant le chmod -R cela n’a rien changé. Je vais suivre les préconisations de mattotop.

#111

Il aurait fallu montrer la ligne complète de debian pour vérifier l’exécutable EFI associé.
Je suppose que tu n’a pas pu faire de copier-coller ?

J’observe que l’entrée de Windows (Boot0000) s’est mise en premier dans l’ordre de boot (BootOrder), c’est donc lui qui doit se lancer par défaut ?

Il faut être très prudent quand on utilise chmod, surtout avec -R (récursif). De toute façon les permissions en lecture et écriture ne s’appliquent pas à l’UID 0 (root), il n’est donc pas nécessaire de les modifier pour éditer un fichier en tant que root.

#112

Sous tty je ne sais pas faire de copier-coller (est ce possible ?)
Effectivement pour le moment c’est W qui se lance en premier. Pour avoir debian avec grub il faudrait donc 1) que je le mette en premier et 2) que je rallonge GRUB_TIMEOUT ?

Je suppose que l’éditeur nano (un VI ?) est utilisable sous tty ?

#113

Si la souris est gérée et que le curseur apparait, sélectionner avec le clic gauche, et clic central pour coller.
Sinon, les fléches en haut et en bas permettent de reprendre les dernières commandes et de les éditer avant de les lancer.

Oui, je l’ai indiqué spécialement pour ça et parcequ’il est installé par défaut, mais si tu préfères vi, vas y.
Moi, c’est emacs-nox.

#114

Tu parles des consoles virtuelles (ttyX) auxquelles on accède par (Ctrl+)Alt+FX ou bien d’un émulateur de terminal dans l’environnement graphique (xterm, gnome-terminal, lxterminal, konsole…) ?

Dans un émulateur de terminal, le copier-coller à la souris est généralement activé : il suffit de sélectionner le texte avec le bouton gauche pour copier, et de cliquer avec le bouton du milieu ou de la roulette ou sur les deux boutons gauche et droits simultanément pour coller. Ctrl+c et Ctrl+v peuvent également fonctionner.

Dans une console virtuelle, si le paquet gpm est installé on peut utiliser la souris pour copier et coller avec les boutons gauche et milieu comme dans l’émulateur. Mais on ne peut pas forcément copier-coller entre une console virtuelle et l’interface graphique.

Une autre méthode consiste à enregistrer la sortie de la commande dans un fichier texte à un emplacement lisible par l’utilisateur normal et d’ouvrir ce fichier avec un éditeur de texte en mode graphique.

efibootmgr -v > /tmp/efibootmgr.txt

#115

Voici le fichier complet efibootmgr efibootmgr.txt (1,1 Ko)

#116

Tu aurais pu insérer le contenu du fichier directement dans ton message, il n’est pas bien gros.
On peut y voir que la variable de boot EFI intitulée “debian” pointe bien vers \EFI\debian\shimx64.efi. Cet exécutable n’est pas directement GRUB mais une couche de compatibilité (“shim” en anglais) avec le secure boot de l’UEFI.

Donc ce n’est pas un autre chargeur ni le noyau Linux qui se charge directement, ce qui était peu probable. L’absence de menu est à chercher ailleurs.

Tu peux modifier l’ordre de boot pour remettre Debian en premier avec :

efibootmgr -o 0001,0000,0003,0004,0006,0005

Mais je ne vois pas pourquoi ça ferait revenir le menu de GRUB, A moins que l’appui sur la touche entrée pour valider “debian” dans le menu de démarrage UEFI reste dans le tampon clavier et lu par GRUB qui lance immédiatement l’entrée sélectionnée par défaut.

#117

Je n’ai pas mis ces quelques lignes dans le message car il aurait fallu que je sois sur Internet sous debian. Or ceci n’est pas possible car la frappe sous firefox est inopérante (caractères dupliqués et mouvants sur la ligne). J’ai donc copié la sortie de la commande dans un fichier et ai ensuite copié ce fichier sur un support externe lisible sous W, ce qui n’est vraiment pas optimisé mais pour le moment je ne sais quoi faire d’autre.
Je vais quand même essayer la manipulation que tu proposes.

Je reprends car la manipulation proposée a fait revenir grub. J’ai donc lancé les commandes
probe --fs-uuid (hd0,gpt2) -> disques non disponibles
probe --fs-uuid (hd1,gpt2) -> banco l’UUID est 7065-4EAB

Je suppose qu’il faudra entrer cette valeur quelque part et que si c’est dans grub il sera encore là

#118

Le fait de remettre Debian en premier dans l’ordre de boot EFI avec efibootmgr ? Curieux. En le laissant démarrer tout seul ou aussi en le sélectionnant explicitement dans le menu de boot UEFI ?

Oui, il faut modifier custom.cfg pour identifier la partition EFI du SSD par son UUID :

menuentry "Windows 10 sur le SSD" {
insmod part_gpt
insmod fat
set root=hd1,gpt2
search --no-floppy --fs-uuid --set=root 7065-4EAB
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Vérifie quand même que cet UUID n’est pas celui de la partition EFI de Debian sur le disque dur, dans la sortie de la commande blkid.

#119

Je pense l’avoir laissé faire tout seul mais je n’en suis plus très sûr à force de devoir changer l’ordre de boot. Quoi qu’il en soit le nouveau fichier custom.cfg est bien dans /boot/efi/EFI/debian et si debian est bien numéro 1 dans l’ordre de boot il y a apparition de grub avec le double choix debian en premier et W10 en second.

Le problème est que ce choix n’est pas vraiment double. On retrouve le problème initial : choisir W se traduit à nouveau par le message “disque (hd0,gpt2) non disponible”. Pour avoir W je suis obligé de passer par le setup et la mise de W en numéro 1 : lors de ce démarrage grub ne se manifeste évidemment plus.

La commande blkid ne fait apparaître nulle part l’UUID 7065-4EAB.
On se retrouve donc à la case départ !

#120

Dans la mesure où il n’y a aucune mention de (hd0,gpt2) dans le nouveau fichier custom.cfg que j’ai indiqué, il n’y a aucun raison que qu’un tel message soit affiché.

Envoie la sortie de blkid et fdisk -l, et dans GRUB, la sortie de ls.

#121

Pour démarrer en debian je suis obligé de mettre debian en premier dans l’ordre de boot et il y a alors démarrage direct sans grub.

Sous debian, dans une console tty, j’ai bien créé blkid.txt et fdisk.txt mais contrairement à tout à l’heure je n’ai plus accès à mon disque externe (qui n’a pas été déconnecté et qui apparaissait dans media). Toute transmission devient très compliquée et il faudrait donc que soit d’abord réglé ce problème du DE complètement défaillant, ce qui permettrait une communication directe via le navigateur.

En tout cas merci pour votre patience et réactivité.