avant sous Windows, j'utilisais "Ghost" pour créer \
gérer des partitions sur lesquelles chacune avait une
version de Windows installée. Cela permettait de
tester des installations sur l'une ou l'autre version.
Puis cela permettait de reformater la partition avec
l'image Ghost et de repartir de "zéro" (une version de
Windows vierge d'installation) au reboot.
Existe-t-il un équivalent de *Ghost* nux pour créer une
telle machine de tests (ps: je ne veux pas une machine
virtuelle avec des *.iso dedans; pour tester un "bête"
logiciel sur diverses distributions, je trouve qu'une
solution qui permette de choisir au boot une
distribution installée, est plus simple)?
Sinon, tu bootes sur une distribution quelconque et tu clones avec *dd* (ce qui fait d'allieurs clonezilla).
Non, Clonezilla est plus malin : lors de la création d'une image il fait appel à partclone ou partimage qui ne copie que les blocs contenant des données utiles quand le format est supporté.
Le 07/03/2020 à 08:15, Sergio a écrit :
Sinon, tu bootes sur une distribution quelconque et tu clones avec *dd*
(ce qui fait d'allieurs clonezilla).
Non, Clonezilla est plus malin : lors de la création d'une image il fait
appel à partclone ou partimage qui ne copie que les blocs contenant des
données utiles quand le format est supporté.
Sinon, tu bootes sur une distribution quelconque et tu clones avec *dd* (ce qui fait d'allieurs clonezilla).
Non, Clonezilla est plus malin : lors de la création d'une image il fait appel à partclone ou partimage qui ne copie que les blocs contenant des données utiles quand le format est supporté.
Pascal Hambourg
Le 07/03/2020 à 08:28, ptilou a écrit :
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Deux critiques : - Une image de disque ou de partition n'est pas une image de système de fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso. - La copie avec bsQ2 est lente, il vaut mieux utiliser au minimum bs=4k voire bs=1M.
Le 07/03/2020 à 08:28, ptilou a écrit :
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Deux critiques :
- Une image de disque ou de partition n'est pas une image de système de
fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso.
- La copie avec bsQ2 est lente, il vaut mieux utiliser au minimum
bs=4k voire bs=1M.
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Deux critiques : - Une image de disque ou de partition n'est pas une image de système de fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso. - La copie avec bsQ2 est lente, il vaut mieux utiliser au minimum bs=4k voire bs=1M.
ptilou
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
Le samedi 7 mars 2020 08:46:13 UTC+1, Pascal Hambourg a écrit :
Le 07/03/2020 à 08:28, ptilou a écrit : > > dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc ! Deux critiques : - Une image de disque ou de partition n'est pas une image de systè me de fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso. - La copie avec bsQ2 est lente, il vaut mieux utiliser au minimum bs=4k voire bs=1M.
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partitio n DOS ? (c'est le meme cas dans les autre table de partitions ?) Et j'ai un CD de l'éditeur Dalloz, je souhaite faire une copie priv ée, et bien cela échoue, je ne connait pas la protection utilis ée ? (juste pour signaler qu'il y a dans certain cas qui ne sont pas le disque dur, une impossibilité de faire une image, quelqu'un ma suggère un inode qui renverrai à une autre partition caché, genre c'est u n DVD, et les ordi le voit comme un CD Joliet 9660 !)
Le conseil monsieur + : compresser le résultat avec un tar ou autre, a vec la compression tous les cluster vide disparaissent ce qui allège l e fichier ! J'ai mis la commande dd, et tu peux le faire avec d'autre commande, par exe mple cp
-- ptilou
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
Le samedi 7 mars 2020 08:46:13 UTC+1, Pascal Hambourg a écrit :
> Le 07/03/2020 à 08:28, ptilou a écrit :
> >
> > dd if=ton_volume of=ton_fichier.iso bs=512 #pour la taille des bloc !
>
> Deux critiques :
>
> - Une image de disque ou de partition n'est pas une image de systè me de
> fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso.
>
> - La copie avec bs=512 est lente, il vaut mieux utiliser au minimum
> bs=4k voire bs=1M.
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partitio n DOS ?
(c'est le meme cas dans les autre table de partitions ?)
Et j'ai un CD de l'éditeur Dalloz, je souhaite faire une copie priv ée, et bien cela échoue, je ne connait pas la protection utilis ée ?
(juste pour signaler qu'il y a dans certain cas qui ne sont pas le disque dur, une impossibilité de faire une image, quelqu'un ma suggère un inode qui renverrai à une autre partition caché, genre c'est u n DVD, et les ordi le voit comme un CD Joliet 9660 !)
Le conseil monsieur + : compresser le résultat avec un tar ou autre, a vec la compression tous les cluster vide disparaissent ce qui allège l e fichier !
J'ai mis la commande dd, et tu peux le faire avec d'autre commande, par exe mple cp
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
Le samedi 7 mars 2020 08:46:13 UTC+1, Pascal Hambourg a écrit :
Le 07/03/2020 à 08:28, ptilou a écrit : > > dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc ! Deux critiques : - Une image de disque ou de partition n'est pas une image de systè me de fichiers ISO 9660 et n'a donc aucune raison d'avoir un suffixe .iso. - La copie avec bsQ2 est lente, il vaut mieux utiliser au minimum bs=4k voire bs=1M.
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partitio n DOS ? (c'est le meme cas dans les autre table de partitions ?) Et j'ai un CD de l'éditeur Dalloz, je souhaite faire une copie priv ée, et bien cela échoue, je ne connait pas la protection utilis ée ? (juste pour signaler qu'il y a dans certain cas qui ne sont pas le disque dur, une impossibilité de faire une image, quelqu'un ma suggère un inode qui renverrai à une autre partition caché, genre c'est u n DVD, et les ordi le voit comme un CD Joliet 9660 !)
Le conseil monsieur + : compresser le résultat avec un tar ou autre, a vec la compression tous les cluster vide disparaissent ce qui allège l e fichier ! J'ai mis la commande dd, et tu peux le faire avec d'autre commande, par exe mple cp
-- ptilou
Pascal Hambourg
Le 08/03/2020 à 08:26, ptilou a écrit :
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partition DOS ?
Si la source est un disque entier, le MBR est déjà inclus dans l'image. Si la source est une partition, je ne vois pas bien quel est l'intérêt de copier le MBR. Si le but est de sauvegarder le chargeur d'amorçage, dans le cas de GRUB les premiers 440 octets du MBR ne contiennent que la première partie, la seconde partie occupant les secteurs suivants (autour de 60, parfois un peu plus). Si le but est de sauvegarder la table de partition, le MBR ne contient que les 4 entrées de partitions primaires. Les entrées de partitions logiques sont contenues dans des secteurs de partition étendue (EBR) répartis sur toute la partition étendue (qu'on ne peut pas copier). Pour sauvegarder la table de partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
(c'est le meme cas dans les autre table de partitions ?)
Parmi les autres formats de table de partition, je ne connais que GPT. En plus du MBR dit "protecteur", ce format occupe un certains nombre de secteurs au début et à la fin du disque (33*2 pour une table de 128 entrées). Du coup la seconde partie de GRUB doit utiliser une partition dédiée de type "BIOS boot".
Le conseil monsieur + : compresser le résultat avec un tar ou autre, avec la compression tous les cluster vide disparaissent ce qui allège le fichier !
C'est faux. En général les blocs "vides" ne le sont pas vraiment. Excepté sur un disque neuf ou ayant été effacé, les bloc non alloués contiennent généralement d'anciennes données devenues inutiles, mais qui n'en sont pas pour autant plus compressibles que le reste. Pour compresser efficacement les blocs "vides", il faut d'abord les remplir avec un motif répétitif, par exemple en créant un gros fichier plein de zéros qui occupe tout l'espace disponible puis en le supprimant : cp /dev/zero fichier_vide ; rm fichier_vide (Cette astuce ne fonctionne pas avec les systèmes de fichiers qui font du chiffrement ou de la compression transparents) La seule exception est le cas des volumes supportant la fonctionnalité "discard" (correspondant au "TRIM" sur les SSD) ET qui renvoient des zéros (ou autre motif répétitif) lors de la lecture d'un bloc marqué avec discard/TRIM.
Le 08/03/2020 à 08:26, ptilou a écrit :
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partition DOS ?
Si la source est un disque entier, le MBR est déjà inclus dans l'image.
Si la source est une partition, je ne vois pas bien quel est l'intérêt
de copier le MBR. Si le but est de sauvegarder le chargeur d'amorçage,
dans le cas de GRUB les premiers 440 octets du MBR ne contiennent que la
première partie, la seconde partie occupant les secteurs suivants
(autour de 60, parfois un peu plus). Si le but est de sauvegarder la
table de partition, le MBR ne contient que les 4 entrées de partitions
primaires. Les entrées de partitions logiques sont contenues dans des
secteurs de partition étendue (EBR) répartis sur toute la partition
étendue (qu'on ne peut pas copier). Pour sauvegarder la table de
partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
(c'est le meme cas dans les autre table de partitions ?)
Parmi les autres formats de table de partition, je ne connais que GPT.
En plus du MBR dit "protecteur", ce format occupe un certains nombre de
secteurs au début et à la fin du disque (33*2 pour une table de 128
entrées). Du coup la seconde partie de GRUB doit utiliser une partition
dédiée de type "BIOS boot".
Le conseil monsieur + : compresser le résultat avec un tar ou autre, avec la compression tous les cluster vide disparaissent ce qui allège le fichier !
C'est faux. En général les blocs "vides" ne le sont pas vraiment.
Excepté sur un disque neuf ou ayant été effacé, les bloc non alloués
contiennent généralement d'anciennes données devenues inutiles, mais qui
n'en sont pas pour autant plus compressibles que le reste. Pour
compresser efficacement les blocs "vides", il faut d'abord les remplir
avec un motif répétitif, par exemple en créant un gros fichier plein de
zéros qui occupe tout l'espace disponible puis en le supprimant :
cp /dev/zero fichier_vide ; rm fichier_vide
(Cette astuce ne fonctionne pas avec les systèmes de fichiers qui font
du chiffrement ou de la compression transparents)
La seule exception est le cas des volumes supportant la fonctionnalité
"discard" (correspondant au "TRIM" sur les SSD) ET qui renvoient des
zéros (ou autre motif répétitif) lors de la lecture d'un bloc marqué
avec discard/TRIM.
Le samedi 7 mars 2020 13:18:57 UTC+1, ptilou a écrit :
dd if=ton_volume of=ton_fichier.iso bsQ2 #pour la taille des bloc !
Oui , j'ai oublier de dire de copier le MBR, si le disque est en partition DOS ?
Si la source est un disque entier, le MBR est déjà inclus dans l'image. Si la source est une partition, je ne vois pas bien quel est l'intérêt de copier le MBR. Si le but est de sauvegarder le chargeur d'amorçage, dans le cas de GRUB les premiers 440 octets du MBR ne contiennent que la première partie, la seconde partie occupant les secteurs suivants (autour de 60, parfois un peu plus). Si le but est de sauvegarder la table de partition, le MBR ne contient que les 4 entrées de partitions primaires. Les entrées de partitions logiques sont contenues dans des secteurs de partition étendue (EBR) répartis sur toute la partition étendue (qu'on ne peut pas copier). Pour sauvegarder la table de partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
(c'est le meme cas dans les autre table de partitions ?)
Parmi les autres formats de table de partition, je ne connais que GPT. En plus du MBR dit "protecteur", ce format occupe un certains nombre de secteurs au début et à la fin du disque (33*2 pour une table de 128 entrées). Du coup la seconde partie de GRUB doit utiliser une partition dédiée de type "BIOS boot".
Le conseil monsieur + : compresser le résultat avec un tar ou autre, avec la compression tous les cluster vide disparaissent ce qui allège le fichier !
C'est faux. En général les blocs "vides" ne le sont pas vraiment. Excepté sur un disque neuf ou ayant été effacé, les bloc non alloués contiennent généralement d'anciennes données devenues inutiles, mais qui n'en sont pas pour autant plus compressibles que le reste. Pour compresser efficacement les blocs "vides", il faut d'abord les remplir avec un motif répétitif, par exemple en créant un gros fichier plein de zéros qui occupe tout l'espace disponible puis en le supprimant : cp /dev/zero fichier_vide ; rm fichier_vide (Cette astuce ne fonctionne pas avec les systèmes de fichiers qui font du chiffrement ou de la compression transparents) La seule exception est le cas des volumes supportant la fonctionnalité "discard" (correspondant au "TRIM" sur les SSD) ET qui renvoient des zéros (ou autre motif répétitif) lors de la lecture d'un bloc marqué avec discard/TRIM.
Pascal Hambourg
Le 08/03/2020 à 11:02, Pascal Hambourg a écrit :
Pour sauvegarder la table de partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
^^^^^^^ Je voulais dire la table de partition complète.
Le 08/03/2020 à 11:02, Pascal Hambourg a écrit :
Pour sauvegarder la table de
partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
^^^^^^^
Je voulais dire la table de partition complète.
Pour sauvegarder la table de partition étendue il vaut mieux utiliser un outil dédié comme sfdisk.
^^^^^^^ Je voulais dire la table de partition complète.
zeLittle
"Pascal Hambourg" a écrit dans le message de groupe de discussion : 5e629bf3$0$4041$ Le 06/03/2020 à 18:09, Michel a écrit :
Le 06/03/2020 à 17:34, zeLittle a écrit :
Mais comment je fais pour dire de rebooter tout en reformatant avec l'image vierge de telle distribution (c'est là que Ghost faisait gagner du temps)?
Clonezilla. Une image vierge, ça ne veut rien dire. Si c'est vierge, pas besoin d'en faire une image.
Effectivement. Par image vierge, j'entendais l'image d'un OS tout seul, sans installation subséquente par dessus.
Le 06/03/2020 à 18:09, Michel a écrit : Il faut créer au moins une partition par système à installer
Non, pas forcément. Avec LVM, si les distributions le supportent, pas besoin de créer des partitions, seulement des volumes logiques bien plus souples à utiliser à chaud (création, suppression, redimensionnement) et en plus on peut faire des instantanés (snapshots).
Toujours vrai aussi. En fait, que ce soit Clonezilla, Ghost4Linux, d'autres..., ils utilisent fonctionnent tous globalement: - la commande "{sudo} dd..." en interne. - pour mes besoins, le plus simple est d'utiliser un de ces outils pour copiersauvegarder dans une autre partition logique, un OS installé sur une partition primaire (vierge d'autres installations subséquentes). Ces sauvegarde s'appellent une "image Ghost": le jargon du premier logiciel à avoir proposer cette solution de sauvegarde a été conservé dans tous ces logiciels. Au passage, je pense qu'ils ont dû "casser" un certains nombre de machine avant de réussir à sortir une version fonctionnelle sure, à l'époque. Puis, au rebootdémarrage de la machine, il est proposé de charger dans la partition primaire une de ces images Ghost (Debian__xyz, XUbuntu__xyz, VBox__xyz_over_Cinnamon__xyz, ...) stockée dans la partition logique (sauf si un post-it sur l'écran précise "Merci de ne pas écraser l'OS actuellement chargé: des essais sont toujours en cours dessus ^^". Et hop! On repart d'un poste neuf sur lequel on peut tester, et la réinstallation d'une application, et ses fonctionnalités seules sur ledit OS vierge. (nb: en ce qui me concerne, je vois le clichésnapshot plutôt comme l'apanage des "Virtual Box" qui peuvent créer effectivement des clichéssnapshots d'une même machine avec différentes configurationsévolutions fonctionnelles (des évolutions d'un serveur Web sur le même OS, ou différents moyensapplications paramétrées ad'hoc pour faire de la télémaintance vers tels ou tels postes de clients lointains, ...; m'enfin, la frontière entre "images ghost" et "snapshot" est floue; elle donc sujette à pleins d'interprétationsexpérimentations).
"Pascal Hambourg" a écrit dans le message de groupe de discussion :
5e629bf3$0$4041$426a74cc@news.free.fr...
Le 06/03/2020 à 18:09, Michel a écrit :
Le 06/03/2020 à 17:34, zeLittle a écrit :
Mais comment je fais pour dire de rebooter tout en
reformatant avec l'image vierge de telle distribution
(c'est là que Ghost faisait gagner du temps)?
Clonezilla.
Une image vierge, ça ne veut rien dire. Si c'est vierge, pas besoin d'en
faire une image.
Effectivement. Par image vierge, j'entendais l'image d'un OS tout seul, sans
installation subséquente par dessus.
Le 06/03/2020 à 18:09, Michel a écrit :
Il faut créer au moins une partition par système à installer
Non, pas forcément. Avec LVM, si les distributions le supportent, pas
besoin de créer des partitions, seulement des volumes logiques bien plus
souples à utiliser à chaud (création, suppression, redimensionnement) et
en plus on peut faire des instantanés (snapshots).
Toujours vrai aussi. En fait, que ce soit Clonezilla, Ghost4Linux,
d'autres..., ils utilisent fonctionnent tous globalement:
- la commande "{sudo} dd..." en interne.
- pour mes besoins, le plus simple est d'utiliser un de ces outils pour
copiersauvegarder dans une autre partition logique, un OS installé sur une
partition primaire (vierge d'autres installations subséquentes). Ces
sauvegarde s'appellent une "image Ghost": le jargon du premier logiciel à
avoir proposer cette solution de sauvegarde a été conservé dans tous ces
logiciels. Au passage, je pense qu'ils ont dû "casser"
un certains nombre de machine avant de réussir à sortir une version
fonctionnelle sure, à l'époque. Puis, au rebootdémarrage de la machine, il
est proposé de charger dans la partition primaire une de ces images Ghost
(Debian__xyz, XUbuntu__xyz, VBox__xyz_over_Cinnamon__xyz, ...) stockée dans
la partition logique (sauf si un post-it sur l'écran précise "Merci de ne
pas écraser l'OS actuellement chargé: des essais sont toujours en cours
dessus ^^".
Et hop! On repart d'un poste neuf sur lequel on peut tester, et la
réinstallation d'une application, et ses fonctionnalités seules sur ledit OS
vierge.
(nb: en ce qui me concerne, je vois le clichésnapshot plutôt comme
l'apanage des "Virtual Box" qui peuvent créer effectivement des
clichéssnapshots d'une même machine avec différentes
configurationsévolutions fonctionnelles (des évolutions d'un serveur Web
sur le même OS, ou différents moyensapplications paramétrées ad'hoc pour
faire de la télémaintance vers tels ou tels postes de clients lointains,
...; m'enfin, la frontière entre "images ghost" et "snapshot" est floue;
elle donc sujette à pleins d'interprétationsexpérimentations).
"Pascal Hambourg" a écrit dans le message de groupe de discussion : 5e629bf3$0$4041$ Le 06/03/2020 à 18:09, Michel a écrit :
Le 06/03/2020 à 17:34, zeLittle a écrit :
Mais comment je fais pour dire de rebooter tout en reformatant avec l'image vierge de telle distribution (c'est là que Ghost faisait gagner du temps)?
Clonezilla. Une image vierge, ça ne veut rien dire. Si c'est vierge, pas besoin d'en faire une image.
Effectivement. Par image vierge, j'entendais l'image d'un OS tout seul, sans installation subséquente par dessus.
Le 06/03/2020 à 18:09, Michel a écrit : Il faut créer au moins une partition par système à installer
Non, pas forcément. Avec LVM, si les distributions le supportent, pas besoin de créer des partitions, seulement des volumes logiques bien plus souples à utiliser à chaud (création, suppression, redimensionnement) et en plus on peut faire des instantanés (snapshots).
Toujours vrai aussi. En fait, que ce soit Clonezilla, Ghost4Linux, d'autres..., ils utilisent fonctionnent tous globalement: - la commande "{sudo} dd..." en interne. - pour mes besoins, le plus simple est d'utiliser un de ces outils pour copiersauvegarder dans une autre partition logique, un OS installé sur une partition primaire (vierge d'autres installations subséquentes). Ces sauvegarde s'appellent une "image Ghost": le jargon du premier logiciel à avoir proposer cette solution de sauvegarde a été conservé dans tous ces logiciels. Au passage, je pense qu'ils ont dû "casser" un certains nombre de machine avant de réussir à sortir une version fonctionnelle sure, à l'époque. Puis, au rebootdémarrage de la machine, il est proposé de charger dans la partition primaire une de ces images Ghost (Debian__xyz, XUbuntu__xyz, VBox__xyz_over_Cinnamon__xyz, ...) stockée dans la partition logique (sauf si un post-it sur l'écran précise "Merci de ne pas écraser l'OS actuellement chargé: des essais sont toujours en cours dessus ^^". Et hop! On repart d'un poste neuf sur lequel on peut tester, et la réinstallation d'une application, et ses fonctionnalités seules sur ledit OS vierge. (nb: en ce qui me concerne, je vois le clichésnapshot plutôt comme l'apanage des "Virtual Box" qui peuvent créer effectivement des clichéssnapshots d'une même machine avec différentes configurationsévolutions fonctionnelles (des évolutions d'un serveur Web sur le même OS, ou différents moyensapplications paramétrées ad'hoc pour faire de la télémaintance vers tels ou tels postes de clients lointains, ...; m'enfin, la frontière entre "images ghost" et "snapshot" est floue; elle donc sujette à pleins d'interprétationsexpérimentations).
