Problème Installation BUSTER 10.3: mauvais chemin pour root dans 3 sections de /boot/grub/grub.cfg

Tags: #<Tag:0x00007f63f4efffb0> #<Tag:0x00007f63f4effee8>

(j ai tenu compte des remarques de Pascal Hambourg pour corriger la description ci dessous)
Lors d’une installation Debian BUSTER 10.3 avec une clef USB live chargée avec
debian-live-10.3.0-amd64-lxqt.iso
sur un système Single Board Computer Atomx4
en choisissant l installation sur une carte uSD entière,
lors de la sélection au grub, le démarrage n’aboutit pas.
on se retrouve en shell busysbox avec un message erreur contenant “dernier montage /dev/sdb2”
En investiguant je vois que dans le fichier généré automatiquement /boot/grub/grub.cfg
il y a les 3 lignes dans menu et submenu ( section 10) donnant le chemin de root pour le noyau compressé qui pointe vers un chemin par device “/dev/sdb2”
c’est à dire là où était la cible d installation pendant l installation
mais où elle n’est plus ensuite au démarrage du système installé
linux /boot/vmlinuz-4.19.0 root=/dev/sdb2 ro quiet splash vt_handofft

Avec un autre système, à l éditeur et en mode sudo, je corrige le fichier /boot/grub/grub.cfg
et donne dans les 3 lignes en question le chemin “by-uuid” pour root: root=UUID=… ,
ce qui donne:
linux /boot/vmlinuz-4.19.0 root=UUID=8E54… ro quiet splash vt_handofft

et alors ça marche, le système boote correctement
Je pense que la fin d’installation avec la génération du fichier grub.cfg
n’a pas pu suivre la consigne by-uuid pour ces 3 lignes. Pourquoi?

un commentaire en complement de mon post de ce jour:
tout le fichier grub.cfg est écrit avec les chemins décrits en mode UUID
sauf le chemin pour le noyau compressé linux vmlinuz qui utilise le chemin en mode device
/dev/sdb2
ce mode est normalement abandonné depuis longtemps
ce mode est fortement ambigue car dependant de l affectation aleatoire par le BIOS

Le titre est erroné : c’est le chemin du paramètre root qui est incorrect, pas le chemin de vmlinuz.

J’ai déjà constaté cette anomalie après l’installation via l’installateur traditionnel (je n’ai jamais utilisé l’installateur Calamares du système live), mais j’ignore sa cause. La plupart du temps ça passe inaperçu car le nom du disque qui contient la partition racine est identique pendant l’installation et après, ce qui n’est pas ton cas.

Après avoir corrigé manuellement en éditant l’entrée de menu de GRUB pour démarrer, il suffit d’exécuter update-grub en root pour regénérer un fichier grub.cfg correct avec root=UUID=…

Merci Pascal pour ta reponse très pertinente
“mon” problème resulte du fait que support d installation et cible d installation sont tous deux de la famille /dev/sdxn qui est brassée et rebrassee par le bios
mais il y a une petite anomalie de fond:
ne pas avoir utilisé le mode UUID pour le chemin de root sur les 3 lignes “linux …”
Crois tu simple de se plonger dans le source (script) de l installer, on doit vraiment être dans la dernière ligne “droite”

Le BIOS détermine la numérotation des disques (hdX) dans GRUB, mais il n’a pas grand-chose à voir avec le nommage des disques /dev/sdX dans Linux. C’est l’ordre de découverte des disques par le noyau qui détermine le nommage, et cet ordre peut être imprévisible et changer d’un démarrage à l’autre, en tout cas il n’est pas fiable et c’est bien pour cela qu’on utilise les UUID à la place.

Ce n’est pas une anomalie de fond, c’est un problème aléatoire qui a affecté ton installation. Normalement ça n’arrive pas, grub.cfg utilise l’UUID dès l’installation.

Merci pour la precision entre le role du bios pour les disques durs et le noyau pour les sd.
j ai effectué integralement deux fois l installation pour arriver exactement au meme resultat /dev/sdb2
donc ce n est pas forcement aleatoire
Mon systeme est un Single Board Computer avec une mmc résidente, un lecteur sd card,
un port usb3 ( et un port usb2).
Pas de hd
Peut etre que ce bios uefi est particulier?
Comme tu devines je suis au-delà de la limite de mes connaissances mais je progresse
aussi grâce à toi, merci

Cher Pascal-Hambourg
la visite du fichier /etc/default/grub qui fournit les paramètres pour la génération de
/boot/grub/grub.cfg
confirme bien ce que tu expliques:

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

on voit que la ligne n’est pas décommentée, on devrait bien utiliser root=UUID=…

Cher Pascal-Hambourg

je dois aussi reconnaître que la lecture et l analyse du script /etc/grub.d/10_linux
ne sont pas des plus aisées pour moi.
Comme vous savez , c’est le script qui génère la section de grub.cfg qui nous interesse

Vous avez fait une suggestion très intéressante
à laquelle j’étais conduit et que je n’avais pas tenté:
relancer à chaud après correction manuelle la commande de génération de grub.cfg
update-grub

je ne suis pas sur le système en question maintenant, il est rangé.
je le ferai au prochain allumage et confirmerai ce qui se passe alors

cordialement
Sel_de_bain

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

Avec l’amorçage BIOS/legacy, hd0 désigne systématiquement le disque de boot. Avec l’amorçage UEFI, c’est moins clair. De toute façon la numérotation des disques par GRUB (en fait par le BIOS/UEFI) n’est pas plus fiable ou persistante que le nommage des disques par le noyau Linux (et la correspondance entre les deux encore moins), c’est pourquoi GRUB utilise les UUID pour lui-même via toutes les commandes search.

On peut définir une correspondance dans /boot/grub/device.map (généré initialement par grub-mkdevicemap) qui sera utilisée par grub-mkconfig, mais ce n’est qu’indicatif.

Bonjour Pascal,
Merci Pascal pour ce rebond.
Je comprends bien ce que tu écris à propos de hd0 et hd1, qui ressemble à ce qu’on peut dire des sda et sdb, et qui rappelle une fois de plus tout l’intérêt du mode UUID
Sauf si bien sûr on se retrouve via des dd avec des disques qui ont même UUID.
Il faut alors créer des UUID différentes avant d’aller plus loin.
J 'ai également découvert il y a peu l’utilisation possible des PARTUUID, et m’en suis servi, pour voir…

Pascal,
Je confirme que j’utilise effectivement du BOOT-UEFI , d’où les définitions flottantes

Le PARTUUID et le PARTLABEL sont intéressants car il ne sont pas modifiés par le reformatage de la partition, contrairement à l’UUID et au LABEL. Dommage que GRUB ne sache pas les utiliser.