Cloner le systeme

Support Debian
#1

Bonjour, j’ai un petit problème pour le clonage intégral d’une système sur une autre partition.

Sda1: système initial
Sda2: fichiers de sauvegarde
Sda3: système cloné.

Voici ce que j’ai fait avec une live-usb:

Mount /dev/sda1 /mnt/initial
Mount /dev/sda2 /mnt/save
Mount /dev/sda3 /mnt/clone

Je me place dans /mnt/initial et je fais:

tar cvpjf /mnt/save/backup.tar.bz2 *

Ensuite je restaure sur /mnt/sda3:

tar xvpfj /mnt/save/backup.tar.bz2 -C /mnt/clone

Je relance le système initial et je modifie le fichier /etc/fstab du clone en lui indiquant le uuid de sda3 pour / et je fais update-grub

Le problème que je rencontre est que quand je lance le clone, il charge le système initial.

Dans l’explorateur de fichiers, si je vais dans ‘système’ ce sont les fichiers de sda1 qui sont affichés. La partition sda3 appelée ‘recovery’ s’affiche quant a elle avec les autres disques (sda2 ‘fichiers’ entre autre).

Quelle est l’étape que j’ai manquée ?

#2

Un update-grub ?

#3

Non je l’ai fait juste après la modif du fstab, mais avec le système initial, pas le cloné. Et j’ai bien choisi debian sur /dev/sda3 dans grub pour essayer le clone après ces deux modifications.

#4

Problème connu.
update-grub se base sur le contenu du fichier /boot/grub/grub.cfg des autres systèmes détectés notamment pour importer les paramètres de la ligne de commande du noyau comme root=. Or le fichier grub.cfg du clone contient encore l’UUID de la partition originale.

Solutions pour démarrer au moins une fois sur le clone :

  • au démarrage, éditer l’entrée de menu de GRUB pour le clone et modifier la valeur du paramètre root=
  • modifier la valeur du paramètre root= de la ligne du commande du noyau dans la section 30_otheros du fichier grub.cfg de l’original
  • modifier la valeur du paramètre root= de la ligne de commande du noyau dans la section 10_linux du fichier grub.cfg du clone puis executer update-grub depuis l’original
  • chrooter sur la racine du clone, monter ce qu’il faut (/dev, /proc /sys) et exécuter update-grub pour regénérer le fichier grub.cfg du clone, puis exécuter update-grub sur l’original

Pas besoin de mettre l’UUID, on peut aussi utiliser root=LABEL=recovery ou root=/dev/sda3.

Dans tous les cas, pour tout remettre au proper il faudra exécuter update-grub depuis le clone puis depuis l’original.

#5

Ah j’étais persuadé que l’update-grub scannait les patitions pour fabriquer seul un menu incluant tous les OS possibles.
Et sinon, au lieu d’avoir 2 grub.cfg, devoir retoucher un à chaque clonage et obligé de faire une manip pour passer de l’un à l’autre, il n’y aurait pas moyen de configurer un seul grub.cfg pour qu’il propose les deux boots en alternatives ?
Ou faire qu’ils se chainent l’un l’autre ?

#6

Il fait ça. Mais quand il trouve un fichier grub.cfg dans une partition il se base dessus pour générer les entrées correspondantes de son propre menu. Très utile pour récupérer les éventuels paramètres passés à la ligne de commande du noyau, déterminer quel fichier initrd est utilisé avec ce noyau…

Si le clonage doit être récurrent, je suggère d’exclure grub.cfg.

Je ne vois pas en quoi ça règlerait le problème du clonage de grub.cfg.

#7

Donc peut être qu’en supprimant le grub.cfg du clone, voire même en supprimant le dossier /boot/grub ça pourrait marcher tu crois (en redémarrant après avoir remis a jour grub).
Je ne savais pas que GRUB se basait sur les grub.cfg des autres partitions qu’il détecte…

#8

A tester. Je n’ai jamais essayé. Pas besoin de supprimer, il suffit de renommer.
La commande grub-mkconfig génère une config et l’envoie dans la sortie standard au lieu de l’enregistrer dans grub.cfg, ça permet de tester sans toucher au grub.cfg original.