Path: ...!news.mixmin.net!aioe.org!BEVFa+6JJ6QbjSdVokIDvA.user.46.165.242.75.POSTED!not-for-mail
From: dyrmak <dyrmak@quelite.terre.invalid>
Newsgroups: fr.comp.os.linux.configuration
Subject: Re: Ordi en rade
Date: Fri, 9 Dec 2022 22:18:07 -0000 (UTC)
Organization: make it mine
Message-ID: <slrntp7d0v.324.dyrmak@quelite.terre>
References: <slrntkvab4.39e.dyrmak@quelite.terre>
 <tiponh$eep$1@ns507557.dodin.fr.nf> <slrntmo5rq.3e9.dyrmak@quelite.terre>
 <tkh72v$noe$1@ns507557.dodin.fr.nf> <tl6kav$117m$1@gioia.aioe.org>
 <tl8pa0$g5e$1@ns507557.dodin.fr.nf>
Reply-To: dyrmak@orange.fr.invalid
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="35817"; posting-host="BEVFa+6JJ6QbjSdVokIDvA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: slrn/1.0.3 (Linux) Los pinos de selva
X-Face: #UKRz(:b-g@wO*dvN'dw1&:E#(n2[pu'>X1x\YT8XBUoycZfzScN4q4SL(2Pp-*j-#y=k
 "ge@p?([^OJ$a$%4Y@&vL^9qx\ha8M$w-VmlqQ+Yo#(x7,g
Cancel-Lock: sha1:DJYYfW7Mtzm8L1L5wiuhKhGHo0Y=
X-Notice: Filtered by postfilter v. 0.9.2
Bytes: 4919
Lines: 88

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
++++ --- ++++