Duplication d'un disque et modifications des UUIDs

[caillou]

Bonjour,

Je vous expose mon problème.
J'ai une distribution base Debian Jessie constituée de la racine (28 Go) et d'un swap (2 Go).

Ces 2 partitions ont leur propre UUID bien entendu.
Le /dev/fstab fait référence à ces 2 UUIDs.

J'ai fait un tar.bz2 de la racine (~ 7 Go).

A partir de ce "tarball" je veux pouvoir reproduire ce système sur des disques de tailles différentes.
Mais surtout je veux conserver le GRUB2 du disque original modulo le changement des UUIDs (/ et swap).

J'ai donc réalisé un script construisant le bon partitionnement. sur le disque cible.
Par contre je galère pour la restauration du GRUB2 original (disque "source") avec les nouveaux UUIDs (ceux de / et swap).

Je crois que j'approche la solution en suivant ce lien https://wiki.debian-fr.xyz/R%C3%A9installer_Grub2
Il me semble qu'il me faut faire l'opération de "chrootage" indiquée mais dans mon esprit ce n'est pas clair.

Auriez-vous un bon conseil à me prodiguer ?

Pierre ESTREM

[piratebab]

Tout dépend comment tu fais ton install sur le disque cible. Si c'est via un live debian, le chroot puis le grub-update est une solution simple et efficace.

[caillou]

Bonjour,

Le disque original n'est pas un live Debian.

Le système à dupliquer vers n'importe quel autre support est une distro base Debian Jessie nommée AccessDV Linux destinée aux bigleux ( aveugles compris).

Cette "ADVL" a son propre GRUB2 avec des items que je veux conserver sur chaque disque copié.

Outre le pbm du "portage" de GRUB2 je rencontre le pbm des nouvelles uuids sinon... message "grub rescue>" ou écran noir !

Cela peut-il vous aider dans la compréhension de mon pbm ?

Pierre E.

[piratebab]

Ce n'était pas la question. Pour créer les clones du disque ou des partitions, comment fais tu ? Tu utilises forcément un systeme fonctionnel à partir duquel tu crées des clones d'une image disque ou partitions de référence.

[caillou]

Comme je l'ai eu dit j'ai fait un "tar.bz2" de la racine (~ 7 Go).

Sur un disque cible je crée avec fdisk un partitionnement adéquat et je crée mes fs ext4 et swap (avec mkfs.ext4 et mkswap).
"
Je "désarchive" le tar.bz2 vers la partition cible (future racine).

Je fais cela depuis le disque original sur lequel j'ai booté.

Et c'est là que je me demande comment être sûr de "porter" le GRUB2 (donc du système courant) vers le disque cible (à cloner)...

Pierre E.

[piratebab]

ha OK, c'est la création du "master" depuis ta machine principale (sous debian je présume). Le plus simple est effectivement le chroot.

[PascalHambourg]

Bonjour Pierre,
Je suppose que ce sujet fait suite aux messages que tu as postés sur la liste linux-31. Tu aurais pu continuer là-bas.

Le changement des UUID n'est pas un problème pour le chargeur GRUB lui-même. Il ne concerne que le contenu du fichier de configuration /boot/grub/grub.cfg du système cible.

Installer le chargeur GRUB avec grub-install ne nécessite pas de chroot. Il suffit de monter le système de fichier auquel appartient le contenu du répertoire /boot du système cible et d'exécuter grub-install en lui indiquant le chemin vers ce répertoire. Par exemple :

Code : Tout sélectionner

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

Mais il n'est même pas forcément nécessaire d'installer le chargeur GRUB. Si le numéro de la partition qui contient /boot ne change pas, on peut cloner la boot image et la core image de GRUB aux mêmes emplacements que sur le disque d'origine. Par exemple :

Code : Tout sélectionner

dd if=/dev/sda of=/dev/sdb bs=440 count=1 # boot image du MBR
dd if=/dev/sda of=/dev/sdb bs=512 seek=1 skip=1 count=127 # core image sur un disque au format DOS/MBR (pas GPT)

La boot image référence le secteur de début de la core image, et la core image référence le numéro de la partition qui contient le répertoire /boot (c'est pourquoi cette méthode n'est applicable que si le numéro ne change pas. Si le disque est au format GPT la core image est à un emplacement différent, de préférence dans une partition dédiée de type "BIOS boot".

Concernant grub.cfg, il y a deux approches différentes :
- le générer entièrement avec update-grub ou grub-mkconfig (le premier appelle le second), dans un chroot. Je recommande d'ajouter GRUB_DISABLE_OS_PROBER=true dans le fichier /etc/default/grub du système cible si os-prober est installé pour éviter de détecter et ajouter les autre systèmes présents au menu de démarrage généré
- ou modifier le fichier originel en remplaçant les UUID d'origine par les nouveaux UUID.

[caillou]

Bonjour Pascal,

Ravi de te lire , j'ai bien remarqué que tu étais vivant sur ce wiki. :)

Si je fais court , tu m'as ce soir permis enfin! d'aboutir !
Par contre je ne sais pas quelle solution a initié cette réussite.

Pour répondre aux premiers posts , la solution "chroot" m'a amené plusieurs fois à des "grub-rescue>". :(

Ta solution avec l'option "--boot-directory" m'a laissé au niveau encore d'un "grub-rescue>". :(

Ta solution avec les 'dd' m'a enfin permis d'obteni le GRUB2 attendu , mais en texte/fond bleu et pas en mode graphique comme tu te souviens peut-être avoir vu au CULTe.
Mais impossible de démarrer sur la racine , retour au GRUB2 après quelques secondes.

Mais la lumière fut quand j'ai découvert que l'UUID de la partition racine du disque original (disque source) apparaissait encore dans /boot/grub/grub.cfg.
Je croyais que 'update-grub' modifiait ce fichier... ! je l'avais pourtant exécuté , sans doute mal.

J'ai donc changé cette ancienne UUID qui figurait en plusieurs endroits du fichier par la nouvelle UUID et pouf , au redémarrage j'ai le beau GRUB2 que j'attendais et le boot démarre bien la racine. :)))

Là se pose une question :
- est-ce le 'grub-install --boot=...' ou les 2 commandes 'dd' (+ l'interversion de l'UUID citée dessus) qui a résolu le problème ?

Ce qui me gave c'est que le désarchivage de mon "tar.bz2" (~ 7GB) prend ~ 2h !
Faire des essais "propres" prend donc un temps fou.
J'essaierai une sauvegarde de ma racine en tar.gz. Je gagnerai un peu de temps.
Cela me surprend car Clonezilla manipule des gz mais le temps de restauration est notoirement plus court.

pierre

[piratebab]

As tu regardé quel était le goulot d'étranglement (cpu, mémoire, accès disques ..)

[PascalHambourg]

est-ce le 'grub-install --boot=...' ou les 2 commandes 'dd' (+ l'interversion de l'UUID citée dessus) qui a résolu le problème ?

Normalement le résultat est à peu près le même (dans ton cas). grub-install est plus sûr car il s'adapte à la situation alors que la méthode dd ne fonctionne que si l'organisation du système clone est identique à celle du système originel : même découpage racine/boot, même format de table de partition, même numéro de partition, même type de système de fichiers...

As tu regardé quel était le goulot d'étranglement (cpu, mémoire, accès disques ..)

Si la cible est une clé USB, le goulot d'étranglement a de fortes chances d'être la vitesse d'écriture de celle-ci, surtout en USB 2. Quand je dois faire ce genre d'essai, j'utilise plutôt un disque (USB ou interne) comme cible, ça va plus vite et ça n'use pas la clé USB.

[caillou]

Mon avis est que la lenteur vient simplement de la décompression "double" (tar + bz2).
Mes clés sont des Sandisk Ultre Fit : du 3.0 très rapide....

Oui je préfère la solution avec le "grub-install --boot=..." plus propre.

[PascalHambourg]

Dans ce cas tu peux essayer d'utiliser une autre méthode de compression plus légère comme gzip au lieu de bzip2 si la vitesse de décompression compte plus que la taille de l'archive.

Note : il n'y a pas de double décompression. Le format d'archive tar n'est pas compressé.