bonjour,
as-tu essayé de “ballader” la souris sur le périph disk,
comme on faisait “dans le temps” pour le rajout de mémoire
cette action fait prendre en compte la configuration,
tu sors bien en sauvegardant?
A+
JB1
Le BIOS conserve en mémoire le système d’une session à l’autre. Il me semble que la plupart des BIOS laisse l’OS décider de l’initialisation d’un nouveau périphérique, la configuration des périphériques est dans une mémoire type flash je pense. (je me suis aperçu de ça lors de ce pbm
mail-archive.com/linux-usb- … 01507.html puis
mail-archive.com/fboisson@w … 00002.html
j’avais eu un échange avec Alan Cox, il explique un peu cette mémoire (ESCD) et ce qui pourrait se passer pour toi. Peut être dans ce cas aurait-il suffit d’effacer cette mémoire ou de forcer sa mise à jour. Mais cette mémoire ne se sauvegarde pas.
Pour l’UEFI, le BIOS se contente de regarder tous les périphériques contenant une arborescence UEFI capable de bouter. Tu n’as pas besoin de la déclarer (ClefAgreg démarre sur des BIOS UEFI sans problème que ce soit sous MAC ou PC, il n’y a pas besoin de signaler les périphériques susceptibles de bouter au BIOS). En fait ma question:
As tu oui ou non le lancement de grub (tu as parlé d’un message d’erreur de grub, dans ce cas ça n’est pas un problème d’UEFI mais du fait que grub ne met pas correctement le prefix (i.e (hd1,gpt1)/boot/grub par exemple). Il te faudrait faire des manipulations dans le shell grub pour cela.
Pas tout mais seulement ce qui concerne le boot de l’OS, et pas dans le BIOS mais dans les variables UEFI.
[quote=“jpg0j2”]Par exemple, si j’installe Wheezy 7.6, une fois installé, en ouvrant le bios, je vois mon disque sata non seulement dans la partie des disque présents, mais aussi en première ligne pour le boot.
Si je change de disque dur et passe à un disque Windows 8.1, Windows va inscrire son numéro de disque.
Je vois alors le nouveau matériel dans le bios.[/quote]
Je ne vois pas de quoi tu parles. Des captures d’écran dans chaque situation seraient souhaitables. Chaque BIOS/UEFI a sa propre interface utilisateur.
Compare le contenu de la partition système EFI (FAT16 ou FAT32, montée sur /boot/efi) des disques Debian et Ubuntu.
Ça pourrait peut-être aider de recopier le fichier image de grub EFI\debian\grubx64.efi (/boot/efi/efi/debian/grubx64.efi) en EFI\boot\bootx64.efi (/boot/efi/efi/boot/bootx64.efi) qui est l’emplacement du chargeur par défaut.
En lisant ta réponse, je me dis que les choses sont de plus en plus complexes.
En retirant LE disque dur d’un portable, on retire tout ce qui se trouve sur les partitions de ce disque et en particulier la partition EFI.
Le “bios-UEFI” qui reste sur l’ordinateur n’a donc plus d’information, SAUF si il conserve en mémoire des choses.(?)
Il va donc “lire” sur le disque dur qui est réinstallé les informations (firmware).
Mais pour que ce disque soit proposé au boot, il a besoin de quelque chose de plus.
C’est ici que Grub intervient (oui?)
J’en conclus que les “bios-UEFI” manipulent les paramètres de ce que l’on appelait habituellement le “bios”.
Donc c’est une mémoire comme les autres, pas un eeprom. Donc, il doit y avoir moyen de sauvegarder ces données?
Elles le sont normalement sur la partition EFI? (oui?) Donc à chaque fermeture de session, elles sont inscrites sur cette partition. Donc en cas de remplacement par un disque dur AYANT DÉJÀ des informations de boot il ne devrait pas y avoir de problème, non?
Pourquoi GRUB ne conserve pas le “Prefix” correspondant au disque dur?
Me fais-je comprendre?
Merci
JP
Je conserve ton idée de copier les “prefix” Grub de chaque OS (Ubuntu et Debian) ce qui pourrait dépanner en effet.
Mais si c’est le cas, peut-être que les développeurs de Grub pourraient faire quelque chose pour Grub Debian?
la version de Grub qui est sur les dépots Debian est-elle bien:
1.99-27 +deb7u2 ?
Merci pour ton aide
JP
Non, ne pas confondre les paramètres initialisant les périphériques et ceux du boute. Le BIOS UEFI cherche ce qui peut bouter et le propose. Toi tu as ton disque, point. [attention, détails à vérifier mais principe correct] Donc il boute dessus en lançant le programme prévu dans le répertoire /boot/efi/… de la partition EFI. Toi c’est le boute de grub, celui ci se lance et cherche à démarrer le disque. Pour cela il lui est fourni dans la variable «prefix» le disque où se trouve les modules grubs utiles pour continuer le procédé. Dans le shell grub, tu peux voir ça en tapant
«set», tu peux voir les disques vus en tapant «ls» puis tu peux modifier le prefix en tapant par exemple «set prefix=(hd0,1)/grub» et continuer le boute. En tout cas, tu pourras voir le problème. Il te faut rentrer dans la console de grub.
D’accord fran.b
La prochaine fois je procéderai comme tu dis.
À force de réfléchir les choses deviennent un peu plus claires.
Je me demandais si au moment de fermer une session et d’éteindre l’ordinateur, il n’y avait pas une faille dans le script de fermeture. Je veux dire que certains paramètres ne seraient pas enregistrés sur la partition EFI.
À ton avis?
Merci
JP
[quote=“jpg0j2”]En retirant LE disque dur d’un portable, on retire tout ce qui se trouve sur les partitions de ce disque et en particulier la partition EFI.
Le “bios-UEFI” qui reste sur l’ordinateur n’a donc plus d’information, SAUF si il conserve en mémoire des choses.(?)
Il va donc “lire” sur le disque dur qui est réinstallé les informations (firmware).
Mais pour que ce disque soit proposé au boot, il a besoin de quelque chose de plus.
C’est ici que Grub intervient (oui?)
J’en conclus que les “bios-UEFI” manipulent les paramètres de ce que l’on appelait habituellement le “bios”.
Donc c’est une mémoire comme les autres, pas un eeprom. Donc, il doit y avoir moyen de sauvegarder ces données?
Elles le sont normalement sur la partition EFI? (oui?) Donc à chaque fermeture de session, elles sont inscrites sur cette partition.[/quote]
Petite mise au point sur l’amorçage en UEFI.
Quand un système d’exploitation installe son chargeur dans la partition système EFI, il doit aussi le déclarer au gestionnaire d’amorçage EFI (la partie du BIOS/UEFI qui gère le démarrage en mode UEFI), ce qui va créer une entrée de démarrage dans celui-ci avec un nom convivial (par exemple “debian”) et la position du chargeur à exécuter lorsque cette entrée est sélectionnée. Comme déjà dit, on peut manipuler (création, suppression, affichage, modification de l’ordre) les entrées du gestionnaire d’amorçage EFI avec l’outil [mono]efibootmgr[/mono]. Elles font partie des “variables EFI” qui sont stockées dans une mémoire non volatile (NVRAM), à ne pas confondre avec la mémoire flash qui contient le BIOS/UEFI lui-même, et non dans la partition système EFI.
Lors du démarrage, en automatique le gestionnaire d’amorçage va essayer de démarrer la première entrée, puis la seconde, etc. A chaque fois il tente de charger le fichier à l’emplacement défini par l’entrée et l’exécuter. S’il n’y arrive pas, il essaye l’entrée suivante.
Si on retire le disque contenant un chargeur référencé par une entrée du gestionnaire d’amorçage EFI, cette entrée n’est plus fonctionnelle. Cela ne veut pas dire pour autant que l’entrée est supprimée. En tout cas ce n’est pas ce qui se produit avec ma propre carte mère UEFI, que j’ai testée alternativement avec des disques partitionnés au format GPT et MBR.
Tout cela va bien au-delà de la compétence d’un utilisateur moyen.
C’est TRÈS intéressant mais on est vite débordé, et pour tout dire, peu enclin à chercher plus avant.
Béotien nous resterons… 
J’ai quand même appris pas mal de choses en 24 heures, et je dois vous remercier chaleureusement tous.
J’ai lu un fichier qui donne des informations sur grub2 en cas de problème, et ça recoupe ce que j’ai lu ici.
Je conserve donc les solutions possibles en attendant peut-être une mise à niveau de Grub2
Mais vu la liste des bugs répertoriés officiellement, la stabilité n’est pas en vue 
Merci
JP