Donc pareil qu’avec les deux disques. Je pensais qu’il y avait un message d’erreur.
J’ai continué mes essais, tous aussi infructueux.
Tout a été démonté et vérifié comme fonctionnant bien (côté matériel)
Bios remis à “défaut” et configuré avec SDD en 1, puisque seul présent.
Le seul SDD en place qui ne comporte qu’une seule Jessie, à jour.
Je rappelle le résultat :
—Allumage machine
– Page de la CM
– Soit attente de suite automatique, soit passage par le choix (F12) :
– extinction totale de l’écran, avec un clignotement de la diode pendant env. 10 secondes puis plus rien pendant … 1 heure.
– Au bout de cette heure, apparition de Grub2, simple, avec les deux seules lignes de la Jessie.
– Puis boot normal et apparition du bureau KDE.
Par la suite, aucun problème, tout fonctionne parfaitement, comme s’il n’y avait eu aucun problème de chargement.
Je viens de graver un CD de super grub2, importé du site officiel :
http://www.supergrubdisk.org/super-grub2-disk/
super_grub2_disk_hybrid_2.02s3.iso
MD5sum vérifiée.
J’ai tenté l’affaire et j’ai réussi à booter avec.
Mais j’aimerais quand même comprendre ce qui ne va pas sur cette machine.
J’aimerais aussi savoir si je vais être obligé de booter avec ce super grub disk à chaque fois, ce qui est quand même fastidieux.
En attendant, il n’y a pas le feu car j’ai réinstallé complètement ma seconde machine qui est presque aussi performante.
Je me retrouve avec deux écrans et deux claviers sur mon bureau.
Je ne serai pas présent pendant 3 ou 4 jours, mais je lirai vos suggestions avec plaisir.
À bientôt.
Présent de nouveau.
Pas de nouvelle piste à exploiter, alors je continue de fouiller partout.
Je réussi à me connecter en passant par Super-grub2-disk, comme déjà dit plus haut, et ça, avec le SSD et avec le second DD (sata classique).
J’en déduis que la qualité des disques et des connexion, ainsi que du reste matériel, n’est pas la cause de mon problème.
Il semble ne rester comme piste que l’installation de Grub2 sur le MBR et/ou de la table des partitions.
Pour cette dernière, je n’ai aucune connaissance : apprentissage bienvenu.
Une première question sur les appellations données par Suergrub2disk :
J’ai ouvert le choix [mono]“core.img - (GRUB2 installation (even if mbr is overwritten)”[/mono]
Je suis étonné de trouver des lignes comme celle-ci :
1/ pourquoi ‘gpt’ au lieu de ‘sda’ ou ‘sdb’ 
2/ que fait ce i386, alors que je suis sous amd64
-
C’est le nommage des partitions dans GRUB. “hd1” désigne le second disque (“hd0” serait le premier), “gpt1” désigne la première partition dans la table de partition GPT. “sda1” ou “sdb1” est le nommage par Linux.
-
L’architecture de GRUB est indépendante de l’architecture du système Linux. [mono]grub-pc[/mono] installe un chargeur 32 bits “i386-pc” compatible BIOS même avec l’architecture amd64.
Juste une idée. J’ai vu parfois des problèmes avec GRUB en mode graphique. Tu pourrais tester de forcer le mode texte pour l’affichage du menu en décommentant la ligne
dans /etc/default/grub puis en exécutant [mono]update-grub[/mono].
[quote=“PascalHambourg”]Juste une idée. J’ai vu parfois des problèmes avec GRUB en mode graphique. Tu pourrais tester de forcer le mode texte pour l’affichage du menu en décommentant la ligne
dans /etc/default/grub puis en exécutant [mono]update-grub[/mono].[/quote]
C’est une idée, en effet. Je tente l’affaire demain.
Merci pour les précisions.
hd0 ; hd1, etc. je savais mais je n’avais pas fait le rapprochement pour GPT et la table de partition.
Je viens de voir un site que je parcourrai demain : http://lecrabeinfo.net/disque-dur-les-tables-de-partitions-mbr-et-gpt.html
Je suis rassuré pour le côté i386, pour lequel, il n’y a rien d’anormal.
À demain.
Une autre question sur la découverte par SuperGrubDisk des systèmes disponibles :
Le SSD et le second DD étant en place, il me donne bien tous les choix (1 seul sur SSD & 5 sur 2dDD)
MAIS
il les nomme, respectivement, ‘hd1’ et 'hd2’
pourquoi pas hd0 et hd1
Est-ce qu’il considérerait SuperGrub2Disk comme hd0
EDIT :
Autre interrogation :
À chaque connexion (via SuperGrub2Disk), il vérifie, pendant 1mn30 la Swap.
Y aurait-il un problème de ce côté ?
Lorsque GRUB est amorcé en mode BIOS/legacy, le premier disque hd0 désigne toujours le périphérique d’amorçage. Si on a amorcé depuis une clé USB, c’est la clé.
En UEFI, c’est moins clair.
OK !
Après avoir modifié /etc/default/grub, j’en suis donc au update-grub.
Là encore, j’ai une interrogation : le temps extrêmement long qu’il met pour trouver certains systèmes.
SSD :
Jessie seul = trouvé aussitôt
2dDD :
sdb1 (jessie) = trouvé rapidement
sdb10 (Kubuntu = très long, env. 10 mn
sdb4 (sauvegarde) trouvé rapidement
sdb6 (une autre Jessie) trouvé rapidement
sdb9 (sauvegarde d’un serveur) très très long
suite de l’update = msg suivant …
… dernières ligne de ‘update-grub’ :
[mono]Adding boot menu entry for EFI firmware configuration
done
Retour invite.[/mono]
Oui, il arrive que [mono]os-prober[/mono], exécuté par [mono]update-grub[/mono] pour détecter les autres systèmes, soit très long. Je n’en connais pas la cause. Je peux juste dire que désactiver os-prober supprime ce délai, mais les autres systèmes ne sont plus détectés automatiquement, si on les veut dans le menu de démarrage il faut ajouter les entrées manuellement.
[quote=“ricardo”]ernières ligne de ‘update-grub’ :
Adding boot menu entry for EFI firmware configuration[/quote]
Tu es sûr d’avoir démarré en mode BIOS/legacy et non en mode EFI ? Via le GRUB installé sur le disque ou supergrubdisk ?
Si /sys/firmware/efi existe, alors le système a été amorcé en mode EFI.
Merde ! je découvre seulement maintenant ta réponse, pas vu la 3ème page 
[quote]
Tu es sûr d’avoir démarré en mode BIOS/legacy et non en mode EFI ? Via le GRUB installé sur le disque ou supergrubdisk ?
Si /sys/firmware/efi existe, alors le système a été amorcé en mode EFI.[/quote]
Comment vérifier ça, dans le Bios
EDIT :
Comment j’ai pratiqué :
Démarrage avec SSD et 2dDD en place, via SuparGrub2Disk (impossible via le SSD ou autre DD)
Arrivée sur Jessie sda1 donc SSD.
À partir de cette Jessie, modification du fichier /etc/default/grub = décommenté la ligne mode texte.
Toujours à partir de cette Jessie, ‘update-grub’
Pour vérifier si les services EFI sont présents
Ou alternativement, si [mono]efibootmgr[/mono] n’affiche pas d’erreur.
Et à part ça, le redémarrage sur le disque après la mise à jour de la config de GRUB n’a rien changé ?
Non, aucun changement mais je viens de reprendre le Bios et de m’apercevoir qu’il y avait deux choix de boot pour le lecteur DVD : UEFi ET SATA PS.
Il me semble que je l’avais placé comme SATA PS mais je le retrouve en UEFi.
Je refais donc l’opération en prenant bien soin de le replacer en SATA ps.
L’upadte-grub mouline mais c’est long, il faut donc que je patiente env. 15/20 mn au total.
Sitôt fait et contrôlé si cette fameuse dernière ligne est la même ou différente, je tente le reboot sans SuperGrub2Disk.
à suivre.
Pour accélérer update-grub tu peux ajouter la ligne suivante dans /etc/default/grub pour désactiver os-prober :
Une fois le système redémarré, vérifie si l’UEFI est actif.
Plus de ligne qui fait référence à UEFI, dans le update-grub mais pas pour ça que ça boute sans SuperGrub2Disk.
Ce soir, ou plutôt vers 1H du mat, je donnerai le détail complet de la page “Bios Features” pour voir s’il n’y a pas une erreur de ma part dans les choix.
Bon app.
EDIT : réponse croisée
[quote]Pour accélérer update-grub tu peux ajouter la ligne suivante dans /etc/default/grub pour désactiver os-prober :
Code:
GRUB_DISABLE_OS_PROBER=true
Une fois le système redémarré, vérifie si l’UEFI est actif.[/quote]
Je fais et je vérifie ça ce soir.
Merci encore de ton aide.
Enfin un résultat concret mais amenant une question subsidiaire (fin de ce message).
Chargé le système avec SuperGrub2Disk
Ajouté ligne [mono]GRUB_DISABLE_OS_PROBER=true[/mono] dans /etc/default/grub
update-grub
Éteint la machine ; enlevé le CD SuperGrub2Disk ; redémarré la machine.
Apparition instantanée de Grub en mode texte, comme configuré MAIS, comme tu m’en avais prévenu plus haut :
Questions :
1/ Je suppose que c’est à ajouter dans /etc/grub.d. Si oui, dans quelle section, 30_os-prober ; 40_custom 
2/ Une fois ajouté ces entrées, je suppose que je dois [mono]‘update-grub’[/mono] mais va-t-il les laisser en place ?
3/ Dans /etc/grub.d, en plus des classiques 00… 05… 10…, etc. j’ai un script [mono]30_uefi-firmware[/mono], on le laisse en place ?
Dans /sys/firmware, aucune trace de UEFI
Si [mono]efibootmgr[/mono] est à passer comme une commande, elle est ‘not found’
Heureux hasard ou pas, je n’aurais pas pensé que désactiver [mono]os-prober[/mono] aurait supprimé le délai au démarrage de GRUB. J’avoue que je ne vois pas le rapport entre les deux, car à ma connaissance GRUB n’exécute les commandes des entrées de menu ajoutées grâce à [mono]os-prober[/mono] que si on les sélectionne.
Réponses :
- Dans /etc/grub.d/40_custom ou dans un fichier /boot/grub/custom.cfg qui est inclus dynamiquement lors de l’exécution de GRUB au démarrage (voir /etc/grub.d/41_custom).
Il y a plusieurs méthodes pour booter un autre système depuis GRUB.
- Pour Linux, ajouter les entrées complètes comme le ferait [mono]update-grub[/mono] avec [mono]os-prober[/mono]. L’ennui c’est que c’est un peu compliqué (il faut mettre les UUID et compagnie) et qu’il faut les mettre à jour en cas de changement comme l’installation d’un nouveau noyau.
- Pour un système Linux utilisant aussi GRUB, créer une entrée de menu qui ne fait que charger son fichier de configuration grub.cfg avec la commande [mono]configfile[/mono]. Mais il faut que les deux versions de GRUB soient compatibles. Par exemple il existe de petites différences de syntaxe entre la version de GRUB de Jessie (2.02) et les versions antérieures (1.9x) qui peuvent faire qu’un fichier grub.cfg généré pour l’une ne fonctionne pas bien avec l’autre.
- Chaîner le chargeur d’amorçage de l’autre système. Si c’est GRUB, tu peux utiliser la commande [mono]multiboot[/mono] avec le fichier correspondant à /boot/grub/core.img ou /boot/grub/i386-pc/core.img selon la version. Si c’est n’importe quel chargeur dont l’amorce est installée dans le secteur de boot d’un autre disque ou d’une partition, tu peux utiliser la commande [mono]chainload[/mono]. Cette méthode ne marche que si le secteur de boot n’a pas été écrasé par l’installation du chargeur d’un autre système, donc n’est pas dans le MBR du disque de boot.
Dans tous les cas je recommande d’utiliser la commande [mono]search[/mono] pour identifier la partition contenant le chargeur ou noyau, comme c’est fait dans /etc/boot/grub.cfg, plutôt que directement les numéros du disque et de la partition qui sont susceptibles de changer.
Ceci n’étant pas un tutoriel et en l’absence de cas concret, je ne détaille pas les commandes à ajouter. Cf. la documentation de GRUB pour les détails des commandes.
-
Oui, le but de modifier ces fichiers au lieu de /boot/grub/grub.cfg directement est de rendre les modifications pérennes, ce dernier étant recréé à chaque exécution d’[mono]update-grub[/mono].
-
Oui, il fait partie du paquet grub-common donc il vaut mieux ne pas y toucher sans raison. L’entrée ajoutée ne fonctionne qu’en mode EFI. Si tu exécutes à nouveau [mono]update-grub[/mono] après avoir démarré depuis le disque, je soupçonne que cette entrée sera supprimée
Donc le système a démarré en mode BIOS/legacy.
[quote=“ricardo”]Si efibootmgr est à passer comme une commande, elle est ‘not found’[/quote].
[mono]efibootmgr[/mono] serait présent si grub-efi-amd64 avait été installé par le passé. Visiblement ce n’est pas le cas, ou bien il a été désinstallé.
Merci pour cette explication que je vais essayer de déchiffrer après-déjeuner.
Est-ce que je laisse présente la partition Bios-Grub de 1 Mo que tu m’avais fait ajouter, il y a déjà quelques mois ?
Oui, bien sûr. Elle est souhaitable pour l’installation du chargeur d’amorçage en mode BIOS/legacy de grub-pc sur un disque au format GPT. S’il y a aussi une partition système EFI tu peux la garder aussi même si elle ne sert qu’en mode EFI, ça peut toujours servir plus tard.