Ordi en rade

[dyrmak]

Bonjour bonsoir,

Un ordinateur plante au démarrage, l'origine du problème
semble être un disque usb seagate qui avait déjà planté deux
autres ordinateurs et n'aurait pas manqué de planter le troisième:
Un Mac sous Linux, .... Depuis il fait:

----------------------------------------------------------------
1.088195] Initramfs unpacking failed: Decoding failed
5.320919] ata1.00: exception Emask 0x0 SAct 0xa500 SErr 0x0 action 0x0
5.320933] ata1.00: irq_stat 0x40000008
5.320943] ata1.00: failed command: READ FPDMA QUEUED
5.320956] ata1.00: cmd 60/08:68:00:b8:cf/00:00:17:00:00/40 tag 13 ncq dma 4096 in
5.320956] res 41/40:00:00:b8:cf/00:00:17:00:00/40 Emask 0x409 (media error) <F>
5.320973] ata1.00: status: { DRDY ERR }
5.320980] ata1.00: error: { UNC }
5.322850] blk_update_request: I/O error, dev sda, sector 399489024 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
7.956925] ata1.00: exception Emask 0x0 SAct 0x20c04 SErr 0x0 action 0x0
7.956937] ata1.00: irq_stat 0x40000008
7.956947] ata1.00: failed command: READ FPDMA QUEUED
7.956960] ata1.00: cmd 60/08:68:00:b8:cf/00:00:17:00:00/40 tag 17 ncq dma 4096 in
7.956960] res 41/40:00:00:b8:cf/00:00:17:00:00/40 Emask 0x409 (media error) <F>
7.958977] ata1.00: status: { DRDY ERR }
7.956984] ata1.00: error: { UNC }
7.958938] blk_update_request: I/O error, dev sda, sector 399489024 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
7.958953] Buffer I/O error on dev sda4, logical block 0, async page read


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _

(initramfs) help
Built-in commands:
------------------
. : [alias break cd chdir command continue eho eval exec exit
export false getopts hash help history let local printf pwd read
readonly return set shift test times trap true type ulimit umask
unalias unset wait [ [[ acpid arch ash awk basename blockdev
busyboxcat chmod chroot chvt clear cmp cp cut date deallocvt
deluser devmem df du dumpkmap echo egrep env expr false fbset
fgrep find fold fstrim grep gunzip gzip hostname hwclock ifconfig
ip kill in loadfont loadkmap ls lzop mkdir mkfifo mknod mkswap
mktemp modinfo more mount mv nuke openvt pidof printf ps pwd
readlink reboot reset rm rmdir run-init sed seq setkeycodes sh
sleep sort stat static-sh stty switch_root sync tail tee test
touch tr true tty umount uname uniq wc wget which yes

(initramfs) _
---------------------------------------------------------------------

Qu'en déduire exactement pour essayer de le démarrer ?

Si une clé USB contenant le linux d'installation pouvait
être utilisé je pourrais intervenir à distance, cet ordinateur
est à des dizaines de kms de Paris ( et de sa banlieue ).


Merci pour votre aide.

dyrmak
--
Contempla tu dicha maroma de azar
++++ --- ++++
Linux operating system
++++ --- ++++

[Jo Engo]

Le Wed, 19 Oct 2022 07:38:12 -0000 (UTC), dyrmak a écrit :

> Un ordinateur plante au démarrage,

Si ça peut aider, avec les messges d'erreurs ton /initramfs/ est corrompu.
C'est le «disque» de démarrage. Tu peux essayer, mais de toute façon, il y
a de fortes chance que ce soit ton disque dur qui est corrompu de modifier
la ligne de démarrage de grub, de façon à demarrer sur / au lieu
d'initramfs. À ce moment là après avoir remonté tous les volumes de lancer
(en root) update-initramfs (je ne suis pas sûr de l'orthographe de la
commande et de sa syntaxe) ce qui te permettra d'avoir un initramfs tout
neuf



--
Tout nombre provient de l'Unité, et lui à son tour du Zéro. En cela
réside un grand mystère sacré.
-+- Platon -+-

[Jo Engo]

Le Wed, 19 Oct 2022 17:49:30 -0000 (UTC), Jo Engo a écrit :

> modifier la ligne de démarrage de grub, de façon à demarrer sur / au
> lieu d'initramfs

Il doit y avoir moyen de faire ça depuis BusyBox aussi.



--
TRANCHE DE VIE

M : J'aime bien lire aux chiottes, mais ce que je préfère... c'est chier
chez le marchand de journaux...

[Pascal Hambourg]

Le 19/10/2022 à 09:38, dyrmak a écrit :
>
> Un ordinateur plante au démarrage, l'origine du problème
> semble être un disque usb seagate

Peu probable, vu les messages d'erreur.

> 5.320919] ata1.00: exception Emask 0x0 SAct 0xa500 SErr 0x0 action 0x0
> 5.320933] ata1.00: irq_stat 0x40000008
> 5.320943] ata1.00: failed command: READ FPDMA QUEUED
> 5.320956] ata1.00: cmd 60/08:68:00:b8:cf/00:00:17:00:00/40 tag 13 ncq dma 4096 in
> 5.320956] res 41/40:00:00:b8:cf/00:00:17:00:00/40 Emask 0x409 (media error) <F>
> 5.320973] ata1.00: status: { DRDY ERR }
> 5.320980] ata1.00: error: { UNC }

Secteur(s) défectueux sur un disque ou SSD PATA ou SATA.

[Pascal Hambourg]

Le 19/10/2022 à 19:52, Jo Engo a écrit :
> Le Wed, 19 Oct 2022 17:49:30 -0000 (UTC), Jo Engo a écrit :
>
>> modifier la ligne de démarrage de grub, de façon à demarrer sur / au
>> lieu d'initramfs

Ça ne marche plus, ça. Le noyau n'a plus les pilotes en dur pour accéder
à la racine, ils sont en modules dans l'initramfs.

> Il doit y avoir moyen de faire ça depuis BusyBox aussi.

busybox est dans l'initramfs.

[Jo Engo]

Le Wed, 19 Oct 2022 23:05:52 +0200, Pascal Hambourg a écrit :

> busybox est dans l'initramfs.

Il n'y a pas des stages dans l'initramfs ? D'après le message de l'OP, il
accède à busybox.


--
Barre ? c'est mon compagnon de chambre :
il dort à coté de moi à l'Assemblée.
-+- André Santini -+-

[Pascal Hambourg]

Le 20/10/2022 à 07:44, Jo Engo a écrit :
> Le Wed, 19 Oct 2022 23:05:52 +0200, Pascal Hambourg a écrit :
>
>> busybox est dans l'initramfs.
>
> Il n'y a pas des stages dans l'initramfs ? D'après le message de l'OP, il
> accède à busybox.

L'initramfs est une concaténation d'archives cpio éventuellement
compressées. Le noyau extrait son contenu dans un ramfs ou un tmpfs
monté sur / et exécute le programme /init qui se charge de la suite des
opérations consistant notamment à monter la racine finale et exécuter le
programme /sbin/init qui s'y trouve (éventuellement après avoir vérifié
l'absence d'une image d'hibernation dans le swap).

Apparemment l'erreur "unpacking failed" n'empêche pas l'initramfs de
démarrer. Mais des erreurs disque semblent l'empêcher de réaliser ses
opérations normales et il lance le shell de busybox en réaction.

[Jo Engo]

Le Fri, 21 Oct 2022 00:19:29 +0200, Pascal Hambourg a écrit :

(snip le pourquoi du comment)

> il lance le shell de busybox en réaction.

Et c'est là qu'il peut tenter
# fsck /dev/sda1 # si / est monté en sda1 (1)
# # suspense ##
# mount / # vérifier le volume avant de le monter
# update-initramfs # Ce qui a un sens si (1) s'est déroulé sans problème
catastrophique

Si tout se déroule sans erreur, l'OP pourra démarrer sa machine
normalement. NB il doit faire ça en remote, la personne qui opère est
probablement encore plus débutante que lui. NB2 tout peut échouer parce
que l'initramfs est trop ou mal corrompu



--
Les gens couverts de croix me font irrésistiblement penser à un
cimetière.
-+- Paul Leautaud (1872-1956) -+-

[Pascal Hambourg]

Le 22/10/2022 à 12:48, Jo Engo a écrit :
> Le Fri, 21 Oct 2022 00:19:29 +0200, Pascal Hambourg a écrit :
>
>> il lance le shell de busybox en réaction.
>
> Et c'est là qu'il peut tenter
> # fsck /dev/sda1 # si / est monté en sda1 (1)

fsck sur un disque avec des secteurs défectueux est un peu hasardeux.

> # mount / # vérifier le volume avant de le monter

Marchera pas. /etc/fstab de l'initramfs ne contient pas de ligne pour
monter /. L'initramfs utilise le paramètre root= de la ligne de commande
du noyau.

> # update-initramfs # Ce qui a un sens si (1) s'est déroulé sans problème
> catastrophique

Marchera pas. On est dans l'initramfs, pas dans la racine du système.

[Jo Engo]

Le Sun, 23 Oct 2022 13:43:51 +0200, Pascal Hambourg a écrit :

>> # fsck /dev/sda1 # si / est monté en sda1 (1)
>
> fsck sur un disque avec des secteurs défectueux est un peu hasardeux.

Autre chose ?

>
>> # mount / # vérifier le volume avant de le monter
>
> Marchera pas. /etc/fstab de l'initramfs ne contient pas de ligne pour
> monter /. L'initramfs utilise le paramètre root= de la ligne de commande
> du noyau.

# mount / /dev/sda1 # ?

>
>> # update-initramfs # Ce qui a un sens si (1) s'est déroulé sans
>> problème catastrophique
>
> Marchera pas. On est dans l'initramfs, pas dans la racine du système.

Marchera si la commande précédente a marché, non ?



--
Qui trop embrasse mal étreint.
-+- François Rabelais (1494?-1553), Gargantua (chap. 46) -+-

[dyrmak]

En 69 lignes dyrmak a écrit
dans news:slrntkvab4...@quelite.terre
le mercredi, 19 octobre 2022 à 09:38:12 :

>
> Qu'en déduire exactement pour essayer de le démarrer ?
>

Tout d'abord merci à tous pour vos interventions, je comprends
qu'effectivement le disque est cassé, mes interventions
à distance me confirment que la partition de sauvegarde est
sur input/output error et que la partition EFI aussi est cassée.

La partition système est en bon état, la sauvegarde des données
qui y traînaient ont pu être sauvegardeés et au final il n'y a pas
de perte bien que la partition de sauvegarde soit KO.

On voudrait installer sur disque externe SSD, est-ce
qu'il est possible de forcer l'installateur de Mint20 (Mate)
d'ignorer complètement le disque dur interne du MAC ?
Comment s'assurer qu'en lançant le Mint20 d'installation
celui-ci ignorera complètement la partition swap du disque cassé?


Merci pour vos remarques et suggestions

dyrmak
--
Se me olvidó tu nombre

[Jo Engo]

Le Mon, 31 Oct 2022 11:17:36 -0000 (UTC), dyrmak a écrit :

> On voudrait installer sur disque externe SSD, est-ce qu'il est
> possible de forcer l'installateur de Mint20 (Mate)
> d'ignorer complètement le disque dur interne du MAC ?

pourquoi ne pas installer le SSD en interne, en remplacement du disque qui
est hors-service ?

Ceci dit, si à l'instal tu demandes à Mint de n'utiliser qu'un disque, il
n'utilisera que ce disque. Il ne devrait pas y avoir de souci. Si
l'installateur se met à t'injurier en serbo-croate, rien ne t'empêche de
revenir ici poser une autre question

--
L'appétit vient en mangeant.
-+- François Rabelais (1494?-1553), Gargantua (chap. 5) -+-

[dyrmak]

En 17 lignes Jo Engo a écrit
dans news:tjolek$i28$9...@shakotay.alphanet.ch
le lundi, 31 octobre 2022 à 15:17:56 :

> Le Mon, 31 Oct 2022 11:17:36 -0000 (UTC), dyrmak a écrit :
>
>> On voudrait installer sur disque externe SSD, est-ce qu'il est
>> possible de forcer l'installateur de Mint20 (Mate)
>> d'ignorer complètement le disque dur interne du MAC ?
>
> pourquoi ne pas installer le SSD en interne, en remplacement du disque qui
> est hors-service ?

C'est une opération à distance et j'ai déjà demandé de remplacer
le disque dur, mais ils préfèrent essayer le SSD externe....

À priori cela devait se faire les doigts dans le nez, mais à distance
ça mettait de plombes à réagir, l'installateur iso sur clé usb
a été vérifié intègre et authentique, mais tout à coup je me pose la
question si le disque dur cassé ne joue pas le frelon dans la voiture,
et ou si il y a utilisation de la partition de swap du disque cassé,
quand je fais cat /etc/fstab ça m'a sorti une histoire d'overlay
et fichier /tmp ... Pas comme les /etc/fstab dans les disques
qui ont un Linux installé où ils disent que le swap se trouvait
auparavant ( au moment de l'installation dans une partition /dev/sda3
par exemple ) Si j'ai vaguement compris, je n'ai aucune idée si
l'installateur utilise le swap qu'il trouve dans les disques
environnants, je sais qu'il n'oublie pas le disque entier mais
comme il est cassé il met des heures à avancer dans l'installation
pour ne donner d'autre option que quitter et recommencer, quel
délire!

>
> Ceci dit, si à l'instal tu demandes à Mint de n'utiliser qu'un disque, il
> n'utilisera que ce disque. Il ne devrait pas y avoir de souci. Si
> l'installateur se met à t'injurier en serbo-croate, rien ne t'empêche de
> revenir ici poser une autre question
>

J'aimerai que la personne qui déclenche le démarrage de l'installation
puisse indiquer que le disque cassé n'existe pas ou à défaut
qu'il inhibe l'utilisation de swap de ce disque cassé si l'installateur
en devait faire usage pour ses propres besoins....

Actuellement quand enfin je prends le contrôle à distance pour
poursuivre l'installation il est déjà trop tard, l'installateur
s'amuse dèjà avec le disque cassé ou peut-être son swap est dèjà
utilisé .....

dyrmak
--
Se hace camino al andar

[Jo Engo]

Le Mon, 31 Oct 2022 15:35:41 -0000 (UTC), dyrmak a écrit :

> ou à défaut
> qu'il inhibe l'utilisation de swap de ce disque cassé

(excuse je ne retrouve pas le bon passage à quoter)

UEFI je sais pas comment c'est foutu (je n'ai que des vieux ordis), mais
dans le menu il doit y avoir moyen de faire considérer un disque comme
inexistant en tout cas dans le BIOS c'était possible (il doit peut-être y
avoir aussi moyen de (tenter) de réparer le disque mais on n'en est plus
là) c'est brutal, mais au moins il ne risquera plus d'y avoir
d'interaction avec ce disque.



--
Un petomane se met la tête dans le cul et se suicide au gaz.
-+- Les nuls -+-

[Pascal Hambourg]

Le 31/10/2022 à 19:20, Jo Engo a écrit :
>
> UEFI je sais pas comment c'est foutu (je n'ai que des vieux ordis), mais

L'UEFI ne change rien de ce point de vue.

> dans le menu il doit y avoir moyen de faire considérer un disque comme
> inexistant en tout cas dans le BIOS c'était possible

La plupart du temps, cette option ne fait qu'ignorer par le BIOS le
périphérique concerné. Cela affecte l'amorçage et GRUB (ou autre
chargeur d'amorçage qui utilise le BIOS pour l'accès aux disques) mais
pas Linux qui utilise ses propres pilotes pour l'accès disque. Une seule
fois j'ai vu un BIOS (Dell Optiplex) qui semblait vraiment désactiver le
port SATA, empêchant Linux de détecter le disque connecté.

Pour faire ignorer le disque SATA interne par Linux, on peut blacklister
le module qui pilote le contrôleur SATA avec, dans le cas d'un
contrôleur AHCI géré par le pilote ahci

blacklist ahci

dans un fichier /etc/modprobe.d/*.conf (fonctionne seulement si le
pilote est compilé en module, et pas forcément facile à faire avec un
installateur ou un système live) ou

modprobe.blacklist=ahci

ajouté aux paramètres de la ligne de commande du noyau dans le chargeur
d'amorçage (généralement GRUB ou ISOLinux)

ou bien désactiver tous les périphériques ATA avec

options libata force=disable

dans un fichier /etc/modprobe.d/*.conf (même restriction que ci-dessus) ou

libata.force=disable

ajouté aux paramètres de la ligne de commande du noyau.
On peut désactiver spécifiquement un disque mais il faut connaître son
identifiant port.disque.

Il se peut que l'installateur enregistre le paramètre de façon
persistante dans la configuration du système installé.

Dans le cas d'une installation lancée à partir d'un système live, il
peut être possible de décharger le module qui pilote le disque interne
ou bien supprimer le périphérique via /sys/block/<disque>/device/delete
avant de lancer l'installation.

[dyrmak]

En 15 lignes Pascal Hambourg a écrit
dans news:tiponh$eep$1...@ns507557.dodin.fr.nf
le mercredi, 19 octobre 2022 à 23:03:45 :

> Secteur(s) défectueux sur un disque ou SSD PATA ou SATA.

Supposons qu'il soit possible de déterminer le contrôleur du disque
défectueux et qu'on puisse démarrer l'installateur avec l'option
ad-hoc ( genre libata off ) comme indiqué dans le fil, est-ce que
par malchance le disque SSD externe utiliserait le même contrôleur ?
Comment déterminer les contrôleurs de chacun des disques ?

J'ai le /sbin/lsmod (executé depuis le linux installateur)
mais je suppose qu'il y a un moyen de bien déterminer ce dont
on a besoin, les opérations à distance manquent d'interactivité,
ce qui permettrait plus de souplesse dans le mode opératoire ....

dyrmak
--
Contó una leyenda

[Pascal Hambourg]

Le 09/11/2022 à 22:11, dyrmak a écrit :
>
>> Secteur(s) défectueux sur un disque ou SSD PATA ou SATA.
>
> Supposons qu'il soit possible de déterminer le contrôleur du disque
> défectueux et qu'on puisse démarrer l'installateur avec l'option
> ad-hoc ( genre libata off ) comme indiqué dans le fil, est-ce que
> par malchance le disque SSD externe utiliserait le même contrôleur ?

Pas besoin que le disque externe soit connecté au même contrôleur, il
suffit qu'il soit sur connecté à un contrôleur SATA géré par le même
pilote (dans le cas d'un module blacklisté) ou par un autre pilote basé
sur libata (dans le cas d'une désactivation globale via libata).

Si le disque externe est connecté en USB, il n'y a aucun risque puisque
les pilotes sont différents et non basés sur libata.

> Comment déterminer les contrôleurs de chacun des disques ?

En regardant les liens dans /dev/disk/by-path.

> J'ai le /sbin/lsmod (executé depuis le linux installateur)
> mais je suppose qu'il y a un moyen de bien déterminer ce dont
> on a besoin

lspci -k affiche les modules/pilotes utilisés pour chaque contrôleur.

[dyrmak]

En 27 lignes Pascal Hambourg a écrit
dans news:tkh72v$noe$1...@ns507557.dodin.fr.nf
le mercredi, 09 novembre 2022 à 22:46:07 :

>
> lspci -k affiche les modules/pilotes utilisés pour chaque contrôleur.
>

Je suis passé à la phase de simulation d'une
machine EFI dont le disque de type SATA/AHCI
contenait un système Linux opérationnel.
J'ai forcé une panne au démarrage de ce système Linux
en cassant son répertoire de boot.
L'incident provoqué n'est pas une erreur d'E/S mais
un arrêt net de la machine sur une invite de grub:

>grub

j'ai continué la simulation en introduisant le conseil
préconisé de faire ignorer le disque cassé et en ajoutant
i'iso d'installation dans la machine EFI, cette fois la
machine démarre sur l'iso, grub affiche:
"Start linux Mint 20 Mate 64-bit"
et en éditant la ligne du menu avec l'option
modprobe.blacklist=ahci, la machine EFI continue le
boot sur l'iso, je reviendrai vers la fin de cette
intro pour signaler ce qui me semble un dysfonctionnement
de démarrage lorsque le péripherique sur lequel on veut
booter n'est pas l'iso mais un disque SSD( bien sûr lui
aussi simulé dans la machine EFI)

À ce stade donc, le disque EFI est ignoré et son swap par
conséquent n'est pas opérationnel, dans la vraie machine
il y a une partition de swap, supposé déstabiliser l'iso
d'installation.

En connectant le nouveau disque USB/SSD on vérifie qu'il
devient /dev/sda ! ( Seul et unique disque dur du sytème )
MERCI POUR LE CONSEIL TRÈS PRÉCIEUX !
La vraie machine a un disque piloté par AHCI, je l'avais constaté
en examinant un lspci que j'avais archivé....

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.

Au démarrage, j'obtiens à nouveau l'invite >grub, mais
je peux quan-même booter sur le disque SSD, après paramétrage
du grub:

set root= (hd1,gpt2)
linux /boot/..... modprobe.blacklist=ahci root=/dev/sda2
initrd /boot/......
boot

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.

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

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

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
5.2.2.r126460 et il y a peut-être mieux depuis .....

Dans tous les cas, avec la touche F12 même
si ce n'est pas automatique, le démarrage se fait
sans problème, il ne me reste plus que convoquer
la session à distance, merci pour l'aide, bien
précieuse, je vous l'assure!

dyrmak
--
Es un lobito el cordero

[Pascal Hambourg]

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.

[dyrmak]

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

[Pascal Hambourg]

Le 09/12/2022 à 23:18, dyrmak a écrit :
>
> 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.....

Si cette saleté de rejeton d'Ubuntu n'affiche pas le menu de GRUB par
défaut, il faut arrêter le démarrage en appuyant sur "Echap" avant la
fin du compte à rebours de GRUB (invisible, très pratique n'est-ce pas
?) pour afficher le menu de GRUB puis appuyer sur "c" pour lancer
l'invite de commande.

[dyrmak]

En 16 lignes Pascal Hambourg a écrit
dans news:tn0gho$kdg$1...@ns507557.dodin.fr.nf
le samedi, 10 décembre 2022 à 00:32:08 :

> Si cette saleté de rejeton d'Ubuntu n'affiche pas le menu de GRUB par
> défaut, il faut arrêter le démarrage en appuyant sur "Echap" avant la
> fin du compte à rebours de GRUB (invisible, très pratique n'est-ce pas
> ?) pour afficher le menu de GRUB puis appuyer sur "c" pour lancer
> l'invite de commande.

J'ai compris en effet, il fallait provoquer l'invite grub pour
pouvoir faire la comparaison, et oui, sans appuyer sur "Echap" on
n'obtient pas le menu de grub; les variables d'environnement
de set sont différentes d'un disque à l'autre, seulement celles
du disque SATA coincïdent avec celles présentes dans le grub
spontané du démarrage initial.

dyrmak
--
En el arena de esas calientes, o en las arenas de esas hirvientes