Sujet : Re: Ordi en rade
De : dyrmak (at) *nospam* quelite.terre.invalid (dyrmak)
Groupes : fr.comp.os.linux.configurationDate : 10. Dec 2022, 00:18:07
Autres entêtes
Organisation : make it mine
Message-ID : <slrntp7d0v.324.dyrmak@quelite.terre>
References : 1 2 3 4 5 6
User-Agent : slrn/1.0.3 (Linux) Los pinos de selva
En 58 lignes Pascal Hambourg a écrit
dans
news:tl8pa0$g5e$1@ns507557.dodin.fr.nf le vendredi, 18 novembre 2022 à 21:18:08 :
Avis personnel : les fichiers de swap, c'est sale...
C'est pourtant bien pratique de faire une installation
sur carte SSD et ne pas avoir de soucis de swap quand on
la déplace. J'admets aussi que je n'ai pas d'avis personnel sur
la question.....
Au démarrage, j'obtiens à nouveau l'invite >grub, mais
>
C'est probablement le GRUB du disque SATA.
>
À première vue il me sembleait évident que c'était le grub du
disque SATA, mais avec la complexité des systèmes EFI il vaut
mieux refléchir à deux fois avant de l'affirmer.
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.
>
J'avais ajouté l'option avant le séparateur mais je n'ai pas
pensé à l'ajouter après et par conséquent je ne sais pas si
l'installateur de Mint ajouterait l'option sur les systèmes installés,
mais à l'occasion je vais le vérifier.
>
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.
>
Je n'ai peut être pas bien compris ce que tu voulais faire comparer
car sur l'invite de grub la commande set me donne accès aux variables
cmdpath root et prefix et la seule comparaison que je puisse faire
c'est bien avec le démarrage du disque SATA à partir de F12, lequel
fini sur invite de grub, dont la commande set affiche des variables
cmdpath root et préfix identiques aux précédentes, alors que si je
démarre sur le disque SSD, proposé dans le menu du F12, je démarre
bel et bien une session de Mint20.....
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.
>
Ce problème de persistance n'a fait que retarder l'intervention à
distance......
Je trouvais que l'utilisation du efibootmgr n'était pas du tout
satisfaisante et qu'à ce stade l'installation à distance pouvait
s'enlisser sur un boot instable.
Du coup, je pris la décision de déplacer la machine simulée vers
une nouvelle version de Virtualbox, et là, tous les problèmes de
persistance ont disparu, la machine EFI s'est mise à suivre les
instructions de l'efibootmgr, à chaud et à froid.....
Par la suite la session à distance s'est bien déroulée et
la machine réelle se porte bien.
Merci !
dyrmak
-- La hora que suena++++ --- ++++Linux operating system++++ --- ++++