Re: Ordi en rade

Le 18/11/2022 à 01:41, dyrmak a écrit :

      L'installation simulée du nouveau Linux sur ce disque simulé SSD
   n'a posé le moindre problème, cette fois sans partition swap,
   juste un fichier swap.

Avis personnel : les fichiers de swap, c'est sale...

   Au démarrage, j'obtiens à nouveau l'invite >grub, mais

C'est probablement le GRUB du disque SATA.

   L'installateur de Mint n'ajoute pas l'option au démarrage,
   il faut le faire manuellement et faire le grub-update
   soi-même.

Pour information, l'installateur Debian classique (plus précisément grub-installer, son composant responsable de l'installation de GRUB) importe les paramètres ajoutés après le séparateur "--" ou "---" dans le système installé, ceux placés avant étant censés destinés à l'installateur lui-même.
Mais tu as fait l'installation depuis un système Mint live, et j'ignore ce que fait l'installateur Calamares lancé depuis un système Debian live, que je n'ai jamais utilisé.

   On peut toutefois démarrer sur le disque SSD avec la touche
   F12 en choisissant le péripherique dans le menu grub.
      Je rappelle ici que si au lieu de vouloir booter directement
   sur le disque SSD on voulait booter sur l'iso d'installation,
   le processus va à son terme et ne s'arrête pas
   sur >grub .... Pourquoi ? ... J'en sais rien.....

Comme je l'ai écrit, l'invite grub> est probablement celle du GRUB du disque SATA. Tu peux vérifier en comparant la sortie des commandes "set" (en particulier les valeurs de "cmdpath", "root" et "prefix") et "ls" à l'invite du GRUB qui est lancé par défaut et de celui du SSD lancé par F12.

   Pourtant, dans efibootmgr je choisis bien le péripherique SSD
   sur lequel je veux démarrer et cela fonctionne si je fais un
   reboot à chaud, mais si j'arrête la machine EFI, elle
   ne démarre plus et s'arrête sur >grub .....

Problème de persistance des variables de boot EFI ?

   Tout se passe comme si la machine EFI n'était pas capable
   de lire automatiquement les partitions ESP des
   autres disques ? ...
      C'est peut-être un bogue de VB, c'est la version

La gestion des variables de boot EFI par la plupart des firmwares UEFI est buggée (création/modification/suppression, persistance, prise en compte...), il n'y a pas de raison que celles des émulateurs fasse exception.