Petit rapport d’avancement et de confirmation.
0/ Dans le fichier /boot/grub/grub.cfg généré automatiquement et qui posait problème,
j 'avais introduit à la main les chemins avec UUID dans les lignes “linux”,
et le système démarrait bien
1/ Essai de la ré-génération “à chaud” du fichier /boot/grub/grub.cfg
pour vérifier que quand le système est fonctionnel,
le script de génération génère un grub.cfg avec les bons chemins
Plutôt que de faire un “update-grub” qui remplace tout de suite /boot/grub/grub.cfg
j 'ai plutôt utilisé la commande de base “grub-mkconfig”
qui me permet de définir le fichier cfg construit, et ainsi de comparer les fichiers
sudo grub-mkconfig -o /boot/grub/grub-hot.cfg
Dans le fichier résultat, les lignes “linux” comporte la première commande root avec chemin root=UUID=a8… et non pas root =/dev/sdb2 de la version fabriquée à l installation.
On obtient bien:
linux /boot/vmlinuz-4.19.0-8-amd64 root=UUID=a9fb7936-3566-4716-a8e8-6e9592350a9f ro ...
au lieu de :
linux /boot/vmlinuz-4.19.0-8-amd64 root=/dev/sdb2 ro ...
Ceci confirme l’hypothèse d’un problème seulement transitoire lors de l installation.
Une autre constatation:
dans le nouveau fichier, toutes les anciennes occurrences de “hd1,gpt2”
sont remplacés par “hd0,gpt2”.
Ici, je dois rappeler le contexte particulier de mon “single board computer”(SBC) avec Boot UEFI et de ce que je veux faire:
-une mémoire fixe de type emmc vue comme “mmcblk0” avec partitions “mmcblk0p1” et “mmcblk0p2”. Il contient le système ubuntu Disco 19.04 que je ne change pas
-une mémoire amovible carte micro-SD, sur laquelle j’installe la Debian Buster 10.3
-une interface USB3 servant pour la clef live d’installation
Par le biais du BIOS et des BOOT Options, je boote pour l installation sur la USB,
puis installation faite, je dirige le boot vers la carte uSD et son grub.
Question: Est ce que pendant l’installation hd0 était la mmcblk0 , et donc la uSD était hd1?
Tandis qu’ensuite, installation terminée, et amorçant sur la uSD, elle devienne hd0?
2/ j ai ensuite investigué par l’analyse du script “10_linux” comment est générée la chaine
root=… des lignes “linux” de “conf.cfg”.
Dans le script “10_linux” , la fonction interne “linux_entry()” est définie.
La fonction “linux_entry” est appelée pour la génération de chaque entrée du menu de grub
dans la boucle “while” démarrant ligne 281 , derrière le “is_top_level=true”
C’est la variable chaîne “linux_root_device_thisversion”
qui contient le chemin de la commande initiale comme on peut voir ci dessous:
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
La variable “linux_root_device_thisversion” est affectée avant l’appel de “linux_entry”,
dans la boucle “while” (démarrant ligne 281)
Sa valeur prévue par défaut est en mode "UUID=… " :
(ligne 296)
linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
On peut en effet retracer les affectations antérieures des variables chaines pertinentes:
-dans grub-mkconfig:
“Device containing our userland. Typically used for root= parameter.”
GRUB_DEVICE="${grub_probe} --target=device /
"
GRUB_DEVICE_UUID="${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 2> /dev/null
" || true
-et dans 10_linux: l’affectation conditionnelle
LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
)
Plus loin dans le script 10_linux, toujours dans la boucle while et avant l’appel de linux_entry,
Selon une bonne ou mauvaise détection d’existence de “initrd” (et de “initramfs”),
(lignes 326-328),
“linux_root_device_thisversion” peut garder sa valeur par défaut en mode "UUID=… "
et sinon:
“linux_root_device_thisversion” va prendre une valeur à syntaxe “/dev/…” qui est contenu dans la variable GRUB_DEVICE
(ligne 331)
linux_root_device_thisversion=${GRUB_DEVICE}
Lors de l’installation, c’est donc sans doute dans cette détection, qu’il y a le problème transitoire constaté.
3/ A ce jour, sans doute par manque de connaissance des bons paramètres de “mkisofs” ou de “xorriso”,
je n’ai pas réussi à mener au bout le projet de refabriquer une clef live-iso
avec juste la modification dans “10_linux” de la ligne
linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
remplacée par la ligne avec affectation forcée du mode UUID
linux ${rel_dirname}/${basename} root=${GRUB_DEVICE_UUID} ro ${args}
j’aurais bien aimé vérifier qu’alors,
l’installation débouche directement sur une bonne commande en UUID pour “linux” dans le grub.cfg
avec du coup un démarrage du premier coup de BUSTER10.3 sur la uSD de mon SBC.
Merci à Pascal.Hambourg pour ses conseils avertis qui ont bien orienté ce débroussaillage