Clone local, erreur de GRUB ou quoi d'autre?

Support Debian
#1

Bonjour,

Ja vais essayer de dire aussi simplement que possible ce que je ne comprends pas vraiment.

Pour la suite, sachez que je n’utilise le wifi que très rarement, lorsque je voyage. Ma connection est exclusivement filaire.

Circonstances:

1 Sur un pc équipé de 2 disques durs, dont un SSD.
Le SSD (sda) est totalement formaté en ext4 (sda1) et supporte la partion racine.
L’autre disque dur est principalement le support d’un groupe de volumes LVM2, dont un volume logique supporte /home/ et un autre une partition logique clone.

2 Un script «cloner» recopie tout ce qui est sur la racine (donc tout sauf /home, sauvegardé régulièrement sur un disque externe)

Depuis le début (au moins 3ans), je vérifie de temps en temps que je peux démarrer sur le clone, et n’ai jamais observé de problèmes.

Depuis quelques mois (au moins 2), je n’ai pas mis à jour mon clone, et bien m’en a pris.
(dernier il y a 72 jours, -merci find ./ -ctime )

Cet été j’ai du me connecter en wifi, et le menu de l’icone réseau de Mate ne proposait plus de connection wifi.

Ne réussissant pas à corriger le problème, j’ai redémarré sur le clone, qui m’a permis de me connecter sans difficulté.

  1. Étant encore sous jessie, j’envisage de réduire la partition racine du SSD (/dev/hda1) pour en créer -au moins- une autre et y installer soit un autre clone de jessie pour la mettre à niveau, soit d’installer directement Debian 9.

Dans cet optique, j’envisage simplement de démarrer sur le clone afin de réduire est4 du SSD et créer une nouvelle partition où installer le futur système.

  1. Voila le mystère:
    Le menu de grub m’affiche toujours les 4 choix de boot ( 2 sur SSD, 2 sur le clone)
    1ère difficulté, l’utilisation des touches flèches est assez aléatoire, il est parfois difficile de se positionner sur le bon choix (la 3e ligne du menu grub, 1ère pour démarrer sur le clone) mais je fini par y parvenir.

2ème difficulté: ça démarre sans problème, mais lorsque je fait un «df» je constate que c’est le SSD qui porte le système et non le clone.
Le mystère s’épaissit lorsque je constate que le choiw du wifi est présent.

  1. Conclusion, il est possible que mon clone n’ai jamais démarré, car je ne peux être sûr d’avoir férifié ça.

J’ai vérifié les /etc/fstab des 2 partitions de démarrage, elles sont conformes à mon intention (chacun monte la racine sur la partition correpondante).

J’ai bien sur relancé update-grub, comme sans doute des mises à jour l’avaient peut-être fait.

Cela me fait 2 mystères, ce qui, compte tenu de mon ignorance est finalement assez peu :wink:

Certains d’entre vous sauront sans doute m’indiquer la direction à prendre.

Merci de m’avoir lu.

PS
1ère indication:
Démarrage avec le menu clone:
La partition /mnt/clone est monté à la main:

$df -h | egrep ^/dev/
/dev/sda1 235G 20G 203G 9% /
/dev/mapper/VG_1-lv_home 637G 494G 143G 78% /home
/dev/mapper/VG_1-lv_clone 30G 20G 8,5G 70% /mnt/clone
(et le menu wifi est présent)

Démarrage par défaut, menu sda1:
/dev/sda1 235G 20G 203G 9% /
/dev/mapper/VG_1-lv_home 637G 494G 143G 78% /

(et le menu wifi est absent)

Et blkid:
(les 3 dernières lignes me semblent être utiles ici)
sdb2 est le support du LVM, sdb1 la swap.

#blkid (démarrage présumé sur clone)
/dev/sdb2: UUID=“tRi4Hw-3BeZ-3lUv-8d3S-XIvD-Kk3k-LB1MH3” TYPE=“LVM2_member” PARTUUID=“bdb86678-02”
/dev/mapper/VG_1-lv_recup: LABEL=“recup” UUID=“64414312-12a7-4fd8-aee7-3ecc75d6979d” TYPE=“ext4”
/dev/mapper/VG_1-lv_tmp: LABEL=“tmp” UUID=“22440ca2-d99c-4019-9df6-33b381c41309” TYPE=“xfs”
/dev/sdb1: UUID=“ef7000c3-e9ba-464c-a87e-bf27038f804f” TYPE=“swap” PARTUUID=“bdb86678-01”
/dev/sda1: LABEL=“root” UUID=“5c66907a-253d-451b-91cf-dd052b683c8f” TYPE=“ext4” PARTUUID=“b4f542de-01”
/dev/mapper/VG_1-lv_home: LABEL=“home” UUID=“5e6fc3d1-4dab-4d57-a07d-93eff79f5634” TYPE=“xfs”
/dev/mapper/VG_1-lv_clone: UUID=“e7f2e2a2-0a20-4fc8-bd08-3e11dc33fdbc” TYPE=“ext4”

blkid (démarrage par défaut, sur SSD)$sudo blkid
/dev/sda1: LABEL=“root” UUID=“5c66907a-253d-451b-91cf-dd052b683c8f” TYPE=“ext4” PARTUUID=“b4f542de-01”
/dev/sdb1: UUID=“ef7000c3-e9ba-464c-a87e-bf27038f804f” TYPE=“swap” PARTUUID=“bdb86678-01”
/dev/sdb2: UUID=“tRi4Hw-3BeZ-3lUv-8d3S-XIvD-Kk3k-LB1MH3” TYPE=“LVM2_member” PARTUUID=“bdb86678-02”
/dev/mapper/VG_1-lv_home: LABEL=“home” UUID=“5e6fc3d1-4dab-4d57-a07d-93eff79f5634” TYPE=“xfs”
/dev/mapper/VG_1-lv_tmp: LABEL=“tmp” UUID=“22440ca2-d99c-4019-9df6-33b381c41309” TYPE=“xfs”
/dev/mapper/VG_1-lv_clone: UUID=“e7f2e2a2-0a20-4fc8-bd08-3e11dc33fdbc” TYPE=“ext4”
/dev/mapper/VG_1-lv_recup: LABEL=“recup” UUID=“64414312-12a7-4fd8-aee7-3ecc75d6979d” TYPE=“ext4”
/dev/loop0: UUID=“c926c065-88ae-4544-8be0-c8db8d3d9da3” TYPE=“ext4”
/dev/mapper/docker-8:1-2621660-pool: UUID=“c926c065-88ae-4544-8be0-c8db8d3d9da3” TYPE=“ext4”

#2

(Je vais réagir point par point comme si je n’avais pas déjà lu le message entièrement)

S’il a une partition, il n’est pas entièrement formaté.
Au passage, un SSD n’est pas un disque dur.

Une partition logique dans un volume logique, donc un volume logique partitionné ? Je sais qu’une telle abomination est possible, pour en avoir créé une moi-même à fins de test, mais je ne pensais pas que quelqu’un serait assez fou pour s’en servir vraiment.

Je suis rassuré, le volume logique clone ne contient pas une table de partition donc pas de partition logique.

Vraiment ? Alors il doit être un peu trafiqué, car un clone a la fâcheuse tendance de contenir des références au système originel (UUID, étiquettes, noms de volumes… dans /etc/fstab, /boot/grub/grub.cfg, l’initramfs…) alors quand il est sur la même machine que ce dernier, il peut très bien en utiliser des morceaux.

D’autre part il repose sur le chargeur d’amorçage situé dans la partition racine originelle, donc si cette partition devient illisible, plus de démarrage même sur le clone.

Avec les noyaux actuels, ça m’étonnerait qu’on voie encore du /dev/hd* généré par les anciens pilotes IDE (à part mon noyau compilé maison). Plutôt /dev/sda1.

Comment les entrées “clone” ont-elles été générées ? Par la détection automatique d’os-prober lors de l’exécution de update-grub ou par un ajout explicite dans /etc/grub.d/40_custom ou /boot/grub/custom.cfg ?

As-tu comparé le code source des entrées de menu de l’original et du clone, notamment la valeur du paramètre “root” passé à la ligne de commande du noyau ?
La ligne de commande du noyau peut aussi être lue après le démarrage dans le pseudo-fichier /proc/cmdline.

Si l’entrée de menu clone a été générée automatiquement par os-prober, alors il faut savoir que update-grub récupère tous les paramètres de la ligne de commande du noyau dans le fichier /boot/grub/grub.cfg du système étranger s’il existe, et comme c’est un clone ce fichier contient l’UUID de sda1 comme racine.

L’interface wifi est-elle au moins présente en démarrant avec le système originel ?
ip link

Il se peut en effet que seuls le noyau et l’initramfs du clone aient été utilisés, mais que la racine montée soit l’originelle.

#3

Merci Pascal Hambourg,

cela fait beaucoup d’erreurs de ma part! (hda, c’est un lapsus, le reste de bien réels confusions.)

Je vais donc explorer toutes vos remarques une à une, avant d’en donner le retour

Dans l’immédiat, je peux répondre à 2 questions:
1 Grub a bien trouvé tout seul le clone
2 ip link ne montre pas le wifi dans le système par défaut (celui du SSD)

#4

Effectivement, je n’ai modifié que /etc/fstab, c’est à dire la ligne désignant la racine.

Au moins je vois clair dans mon optimisme naïf à propos du clonage.

Comment faire pour modifier grub.cfg et le code source des entrées de menu (là je ne vois pas de quoi vous parlez), que dois-je ajouter comme information à mon script (en gros: rsync avec un fichier d’exclusion comprenant entre autre /etc/fstab), ou que dois-je modifier sur le système clone?

#5

Il faut remplacer l’UUID de l’option root de la ligne de commande du noyau dans le fichier grub.cfg par l’UUID de la partition contenant le clone.

Soit modification directe de la section 30_os-prober du fichier grub.cfg du système original, mais il faut le refaire après chaque regénération du fichier lors des mises à jour du système.

Soit modification de la section 10_linux du fichier grub.cfg du clone, et il faut le refaire après chaque clonage.

#6

Merci beaucoup,

je m’y met dés que possible et vous tient au courant des résultats.

Soit modification de la section 10_linux du fichier grub.cfg du clone, et il faut le refaire après chaque clonage.

Il me semble que c’est la solution la plus propre?

mais (dans les 3 solutions proposées, je ne vois pas vraiment que modifier, comment et où.

Je trouve ce paragraphe de 10_linux:

if [ "x${GRUB_DEVICE_UUID}" = "x" ] || [ "x${GRUB_DISABLE_LINUX_UUID}" = "xtrue" ] \
    || ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" \
    || uses_abstraction "${GRUB_DEVICE}" lvm; then
  LINUX_ROOT_DEVICE=${GRUB_DEVICE}
else
  LINUX_ROOT_DEVICE=UUID=${GRUB_DEVICE_UUID}
fi

Dois-je affecter la variable GRUB_DEVICE_UUID
par l’ UUID du clone au début de ce script?

Pourquoi la réinitialiser à chaque clonage, j’exclus ce fichier de la mise à jour par rsync ?

#7

Je n’ai pas dit de modifier le fichier /etc/grub.d/10_linux mais la section “10_linux” du fichier /boot/grub/grub.cfg (qui est générée par le script /etc/grub.d/10_linux)

Dans grub.cfg, il faut modifier l’UUID du paramètre root=UUID=… dans les lignes de commande du noyau qui commencent par "linux /boot/vmlinuz…"
C’est ce paramètre qui désigne le système de fichiers à monter comme racine.

Si tu choisis de modifier la section 10_linux du clone, il faudra ensuite regénérer le fichier grub.cfg originel une fois avec update-grub.

Mais alors si un jour le fichier originel est modifié pour ajouter une nouvelle option ou un nouveau noyau, la nouvelle version ne sera pas clonée.

#8

Je pensais qu’il ne fallait pas modifier ce fichier à la main, d’où mon erreur.

Il faut donc que mon script «cloner», après avoir mis à jour par rsync:
Modifie l’ UUID des lignes
root=UUID=…
du script /boot/grub/grub.cfg, section 10_linux

puis lance
update-grub

Et c’est tout?

#9

Est-ce qu’une simple substitution de l’UUID par l’UUID du clone, sur l’ensemble de ce fichier ne serait pas un moyen efficace, sure et sans doute plus simple pour mon script?

#10

C’est bien pour cela que tu devras le retoucher après chaque regénération ou clonage selon le cas.

En gros, oui. Je n’ai pas testé.

Probablement.

#11

Surprise, avant toute intervention de ma part:

il y a 221 occurences de l’ UUID sur l’original:

$egrep -ic 5c66907a /boot/grub/grub.cfg
221

Et sur le clone:

205 occurences de l’UUID de l’original:

/mnt/clone
$egrep -ic 5c66907a boot/grub/grub.cfg
205

et 415 occurences de l’ UUID du clone!

/mnt/clone
$egrep -ic e7f2e2a2 boot/grub/grub.cfg
415

Ma commande rsync utilise le fichier d’exclusion suivant (ces lignes sont décommentées dans le fichier):
##### Les fichiers exclus (dans le fichier $EXCLUDE)
# /run
# /home
# /cdrom
# /media
# /mnt
# /dev
# /lost+found
# /proc
# /sys
# /tmp
# /etc/fstab # le plus important!

Et j’ai probablement fait plusieurs fois update-grub (sans doute, au moins quand des mises à jour du noyau ou de grub me sont apparues avec aptitude upgrade)

(boot/grub/grub.cfg date du 5 juillet 2017, avant le dernier (pseudo)«clonage»)

Je suppose que c’est update grub qui a fait ce meli-melo.

J’ ai donc testé update-grub après remplacement de /boot/grub/grub.cfg du clone, par la copie de l’original actuel, puis
substitution de l’UUID de l’original par l’UUID du clone

Resultat: après copie de grub.cfg, substitution de tous les UUID, puis lancement de update-grub:

Au redémarrage:

  1. l’accès au menu grub avec les touches de direction (ligne et page, haut et bas) reste aléatoire

  2. au démarrage (qui bloque immédiatement), s’affichent des messages, dont les extraits suivants:

    mdadm: no arrays found in config file or automatically

    Gave up waiting for root device common problems:
    Boot args (cat: /proc/cmdline)

Le lancement de cette commande affiche sans pb apparent (pour mes petits yeux )

Plus loin:
ALERT! /dev/disk/by_uuid/e7f2e... does not exist.

J’ais donc vérifié cet UUID

Il correspond à:
/dev/disk/by-uuid/e7f2e2a2-0a20-4fc8-bd08-3e11dc33fdbc -> …/…/dm-2

qui correspond aussi à:
/dev/mapper/VG_1-lv_clone -> …/dm-2

et c’est bien ce que contient le nouveau grub.cfg du clone, avec toutefois une bizarrerie:

Ce nouveau grub.cfg (renommé grub.cfg.BUG):

$wc grub.cfg.BUG 
  2316  12412 189721 grub.cfg.BUG

et sa source actuelle, (l’original avant substitution? remis à jour par update-grub):

$wc /boot/grub/grub.cfg
  2381  12971 198638 /boot/grub/grub.cfg

n’ont pas le même nombre de lignes.

Voila où j’en suis.

(la suite demain, sans doute)

merci pour votre patience et le partage de vos lumières.

#12

Le nombre d’occurrences des UUID dans tes fichiers grub.cfg est démesuré. Je pense que update-grub ne digère pas bien la présence du fichier dans le clone. Tu devrais essayer en supprimant le fichier du clone.

Autre point : j’avais perdu de vue que le clone était un volume logique. Or l’initramfs se sert de la forme du paramètre root=/dev/mapper/vg-lv pour déterminer que la racine à monter est dans un volume logique et qu’il faut activer LVM. En mettant l’UUID du système de fichiers, l’initramfs ne comprend pas qu’il s’agit d’un volume logique qu’il faut d’abord activer. Il faut donc remplacer root=UUID=uuid-de-la-racine par root=/dev/mapper/vg-lv_clone.

#13

C’est bien ce qu’il me semblait.

dois-je aussi supprimer le fichier de l’original, et faire grub-mkconfig ?

Ceci explique le premier message d’erreur.

Voici donc ce que j’ai fait:
1 suppression du grub.cfg du clone
2 grub-mkconfig
Bilan au redémarrage sur le clone: une longue liste de messages avant plantage

(redémarrage sur l’original)
3 copie du grub.cfg vers le clone (il ne comporte plus que ~32 occurences de l’ UUID)
4 remplacement de l ’ UUID par /dev/mapper/VG_1-lv_clone
5 grub-mkconfig

Bilan: un seul message

mdadm: no arrays found in config file or automatically

et rien d’autre.

#14

L’erreur précédente était de n’avoir pas supprimé la chaine « UUID=» dans certaines lignes

Ça marche, malgré la persistance du message d’erreur, sur la première ligne:

mdadm: no arrays found in config file or automatically

suivie de quelques autres, mais finalement c’est du clone que je vous écris.

Reste à installer grub également sur le disque dur avant de redimensionner la partition du SSD, le système original.

Avec un grand merci pour votre aide.

#15

Inutile puisque update-grub va remplacer le gru.cfg original. Par contre grub-mkconfig ne modifie aucun fichier par lui-même, il ne fait que générer une configuration sur sa sortie standard, qui est utilisée par update-grub pour écrire dans dans grub.cfg.

Ce n’est pas une erreur mais une information : il n’y a pas d’ensemble RAID dans cette configuration, ce qui est vrai.
Si tu veux supprimer ce message, puisque tu n’utilises pas de RAID tu peux désinstaller le paquet mdadm.

Tu n’as pas besoin d’installer GRUB sur le disque dur pour redimensionner la partition racine du SSD. L’important est que cette partition ne soit pas montée. Mais si tu veux quand même le faire :

grub-install --boot-directory=/mnt/clone/boot /dev/sdb

L’option --boot-directory est importante pour dire à l’image de GRUB installée dans le MBR de /dev/sdb où installer et trouver le contenu de /boot/grub.

#16

bonne idée de désinstaller mdadm

Encore merci PascalHambourg